What do web.de bounce codes like c=hd and c=hi mean?
Michael Ko
Co-founder & CEO, Suped
Published 13 Jul 2025
Updated 19 Aug 2025
6 min read
Dealing with email bounce codes can be a frustrating experience, especially when you encounter cryptic messages from specific internet service providers (ISPs). Web.de, a prominent German email provider, is known for its proprietary bounce codes that offer only partial insight into why your emails are being rejected.
Unlike standard SMTP (Simple Mail Transfer Protocol) codes, which are globally recognized, Web.de often appends its own internal identifiers like c=hd and c=hi to the bounce messages. These codes are not always publicly documented, making troubleshooting a challenge.
Understanding these specific error codes is crucial for maintaining good email deliverability to Web.de recipients. While the primary SMTP error might be a generic 554 - Transaction failed or Reject due to policy restrictions, these additional codes offer more granular clues that can help pinpoint the exact problem.
Understanding Web.de's internal codes
The common Web.de bounce message often looks something like this:
Example Web.de Bounce Message
554 -Transaction failed
554-Reject due to policy restrictions.
554 For explanation visit https://web.de/email/senderguidelines?ip=XXX&c=hi
In this message, the c=hi parameter in the URL is the key indicator. Through community insights and diligent investigation, it has been discovered that c=hd specifically refers to an issue with the Date: header in your email. Web.de might have very strict or unique requirements for how this header is formatted, causing rejections even if other providers accept it.
As for c=hi, the exact meaning remains somewhat elusive. However, the presence of 'h' strongly suggests it is also related to an email header issue, similar to c=hd. The 'i' could potentially stand for 'invalid', 'incorrect', or 'integrity', indicating a problem with another header's format or content integrity according to Web.de's policies.
The riddle of c=hi and other specific codes
Beyond c=hd and c=hi, other undocumented codes exist. For instance, c=sp is often associated with your domain or IP address appearing on a third-party blacklist (or blocklist), such as Spamhaus. Similarly, c=irlrm typically indicates that you are sending emails too quickly, triggering Web.de's internal rate limits.
These hidden codes highlight a common challenge in email deliverability: while public-facing SMTP error codes provide a general category, many ISPs use proprietary sub-codes or URL parameters to offer more specific diagnostics. This approach can be both helpful and frustrating.
Generic SMTP errors
Broad classification: Messages like 550 (permanent failure) or 450 (temporary failure) indicate a general issue without pinpointing specifics.
Less actionable: A 554 policy rejection doesn't tell you if it's due to content, reputation, or technical configuration. This can make troubleshooting common email bounce messages difficult.
Web.de specific codes
Proprietary details: Codes like c=hd or c=hi point to very specific internal policies, often related to header formatting or rate limits.
More specific clues: While not always documented, these codes provide a specific starting point for investigation, such as examining your email headers or sending patterns.
The existence of these specific parameters, even if undocumented, indicates that Web.de's systems use detailed categorizations for bounce reasons. The challenge lies in translating these internal codes into actionable insights for senders. This is why it is important to be familiar with bounce classification codes from various sources, to help you decipher them.
Why ISPs use proprietary bounce codes
ISPs (internet service providers) implement their own specific bounce (or blocklist) codes for several reasons. Firstly, it allows them to fine-tune their spam filtering and policy enforcement based on their unique infrastructure and threat intelligence. This granular control helps them protect their users more effectively.
Secondly, these codes can be tied to internal reputation systems or content analysis engines. A generic SMTP 554 might simply mean rejected, but a specific Web.de code might indicate a policy restriction related to an obscure header, content keyword, or even the volume of emails sent within a specific timeframe.
Lastly, proprietary codes help ISPs manage their support burden. By providing a unique identifier, they can more quickly categorize and respond to sender inquiries, even if the public-facing explanation is minimal. While this can feel unhelpful to senders, it is part of their broader security and operational strategy.
Strategies for diagnosing and resolving bounces
When encountering these specific Web.de bounce codes, a systematic approach to diagnosis is essential. Start by thoroughly examining your email headers for any non-standard formatting, especially the Date: header if you see c=hd. Ensure all headers comply with RFC standards and common best practices.
Next, review your sending patterns. If you've recently increased your sending volume to Web.de addresses, the c=irlrm code might indicate that you are hitting their rate limits. Gradually warm up your sending volume to new ISPs. You should also regularly check your IP and domain reputation on major blocklists (or blacklists) using a blocklist checker.
Consult web.de postmaster guidelines
Although the specific parameters are not always listed, Web.de's postmaster page can provide general categories of issues that lead to rejections. It is worth reviewing this resource and testing different aspects of your emails based on their broad explanations.
If self-diagnosis doesn't yield results, consider reaching out to Web.de's postmaster team directly. While their support responses can sometimes be generic, providing them with the full bounce message, including the URL parameters, can help them escalate or provide more targeted assistance. Don't be afraid to clearly state the specific code you are trying to understand.
Views from the trenches
Best practices
Maintain proper email authentication (SPF, DKIM, DMARC) for all sending domains.
Segment your email lists to ensure engaged recipients and reduce bounce rates.
Regularly clean your email lists to remove invalid or inactive addresses.
Monitor your domain and IP reputation using a blocklist monitoring service.
Common pitfalls
Ignoring specific bounce codes from ISPs, treating them all as generic errors.
Failing to check header formatting against strict ISP requirements.
Sending high volumes of email to a new or cold list, triggering rate limits.
Not maintaining a consistent sending IP and domain, impacting reputation.
Expert tips
Use email deliverability testing tools to preemptively identify potential issues with headers and content.
Implement a feedback loop with major ISPs to quickly identify and address spam complaints.
Keep an eye on industry forums and communities for discussions on specific ISP quirks and undocumented bounce codes.
If encountering persistent issues, try sending test emails with minimal headers and content to isolate the problem.
Expert view
Expert from Email Geeks says that knowing when in the SMTP transaction the bounce occurs can significantly narrow down the potential cause of the issue.
2021-05-25 - Email Geeks
Marketer view
Marketer from Email Geeks says that while Web.de's postmaster page provides some guidance, it can be vague and doesn't always offer explicit solutions for highly specific bounce codes.
2021-05-26 - Email Geeks
Navigating proprietary bounce codes
While Web.de's specific bounce codes like c=hd and c=hi can pose unique troubleshooting challenges, they are ultimately clues. By combining careful inspection of your email headers and sending practices with information gathered from community experience and official ISP guidelines, you can often decipher these cryptic messages.
The key is persistence and a methodical approach. Each bounce is an opportunity to learn more about the specific requirements of major email providers and refine your email program for better deliverability. Focusing on the details, even the seemingly small ones like a header format, can make a significant difference in reaching the inbox.
Proprietary details: Codes like c=hd or c=hi point to very specific internal policies, often related to header formatting or rate limits.
