What are bounce message error codes and how should I interpret them?
Matthew Whittaker
Co-founder & CTO, Suped
Published 25 Jul 2025
Updated 24 May 2026
8 min read
Summarize with
Bounce message error codes are SMTP delivery responses returned when an email cannot be accepted or delivered. The shortest useful answer is this: read the three-digit SMTP code first, use the enhanced status code if it exists, then read the human text for the provider-specific reason and next action.
Yes, one error code can mean different bounce reasons across mail providers. That is common enough that I would not build bounce handling from the code alone. The code gives the delivery class, such as temporary failure or permanent failure. The text usually explains whether the failure was a bad recipient, mailbox full, rate limit, policy rejection, authentication issue, or blocklist (blacklist) problem.
- Start with the SMTP code: 4xx usually means a soft bounce, while 5xx usually means a hard or permanent failure.
- Check the enhanced code: Values like 5.1.1, 5.2.2, and 5.7.1 add useful detail when the sender receives them.
- Read the bounce text: The text often tells you whether to suppress, retry, fix DNS, slow down, or investigate reputation.
- Track the provider pattern: The same code from two providers can require two different operational responses.
How a bounce code is structured
A full bounce response usually has three layers. The first layer is the SMTP reply code, a three-digit number such as 421, 450, 550, or 554. The second layer is the enhanced mail system status code, such as 5.1.1 or 4.7.0. The third layer is free text written by the receiving system, gateway, filtering vendor, or sending platform report.
Example bounce responsestext
550 5.1.1 user@example.com: Recipient address rejected 451 4.7.0 Temporary rate limit. Try again later 554 5.7.1 Message rejected due to policy
The first digit gives the broad outcome. A 2xx response means success, a 4xx response means a temporary problem, and a 5xx response means the receiving system treated the problem as permanent. In bounce processing, that first digit is the cleanest starting point because it comes directly from the SMTP transaction.
|
|
|
|---|---|---|
SMTP class | 5xx | Permanent failure class |
SMTP code | 550 | Mailbox or policy rejection |
Enhanced code | 5.1.1 | Bad or unknown mailbox |
Free text | User unknown | Provider-specific explanation |
Compact guide to bounce code layers
Enhanced codes are useful but optional
Enhanced status codes add detail, but not every provider sends them and some reporting systems strip or rewrite them. Treat them as a strong clue, not as a required field.
- Address failures: Enhanced codes in the x.1.x family often point to bad addresses, moved mailboxes, or routing.
- Mailbox failures: The x.2.x family often points to mailbox state, storage, disabled accounts, or quota issues.
- Policy failures: The x.7.x family often points to policy, authentication, reputation, or content filtering.
Which part to trust first
I trust the SMTP code first for broad classification, then use the enhanced status code and text to decide the fix. If I am building bounce rules, I start simple: 4xx means retry and monitor, 5xx means stop or investigate, then I add exceptions based on actual provider patterns.
Code-first classification
- Best for routing: Separates retryable 4xx failures from permanent 5xx failures quickly.
- Best for scale: Works across large volumes where every message has different wording.
- Risk to handle: Some providers use non-standard codes or map one code to several reasons.
Text-aware diagnosis
- Best for fixes: Shows whether the issue is address quality, throttling, authentication, policy, or content.
- Best for providers: Lets you create specific rules for providers that use unusual wording.
- Risk to handle: Text can be truncated, localized, rewritten, or buried inside a report.
For a deeper operational lookup workflow, compare the raw message against SMTP error codes and keep the original provider text alongside your normalized category.
Flowchart showing SMTP code, enhanced code, bounce text, provider pattern, and action.
Common codes and practical actions
The same numeric family can contain several business outcomes. A 550 can mean an address does not exist, but it can also appear in policy rejections. A 554 can mean a transaction failed, a message was blocked, or the provider disliked the content or reputation signals. The action depends on the text and your sending context.
|
|
|
|---|---|---|
421 | Server busy | Retry later |
450 | Mailbox unavailable | Retry and watch |
451 | Temporary error | Retry with backoff |
501 | Syntax error | Fix address format |
550 | User or policy | Read text |
552 | Quota or size | Reduce size |
553 | Bad mailbox | Suppress if clear |
554 | Policy failure | Investigate cause |
5.7.1 | Policy block | Check authentication |
Common bounce codes and first actions
Do not suppress every 5xx bounce automatically
A permanent SMTP class does not always mean the person is invalid. It means the receiving system rejected that delivery attempt permanently. A 5.1.1 user unknown bounce is a suppression candidate. A 5.7.1 policy bounce needs investigation before list removal.
- Suppress fast: Clear user unknown, invalid recipient, bad domain, or malformed address failures.
- Investigate first: Policy, authentication, content, reputation, blocklist, or blacklist wording.
- Retry carefully: Temporary rate limits, mailbox full responses, and server unavailable responses.
Why one code can have different reasons
SMTP standards define broad categories, but the receiving side chooses the exact response. The response can come from the mailbox provider, an inbound gateway, an anti-abuse system, or an MTA vendor. That means one code can be reused for several local policies.
I have seen non-standard codes in real reports, including three-digit numbers that look like enhanced status codes squeezed into the wrong field. When that happens, the first digit still matters. A made-up code beginning with 5 still says the receiving side treated the failure as permanent, but the rest of the number needs caution.
- Provider policy: Each provider chooses wording for throttling, blocks, sender reputation, and content rules.
- Gateway rewriting: Security gateways can replace the original server response with their own message.
- Report normalization: Sending platforms can shorten, map, or remove parts of the original SMTP response.
- Missing fields: Enhanced status codes are optional, so many bounces only contain the three-digit code and text.
- Local wording: The free-text part can vary by provider, language, filtering layer, and account state.
Confidence when classifying a bounce
Use the field combination to decide how much automation is safe.
High confidence
3 signals
SMTP code, enhanced code, and text agree.
Medium confidence
2 signals
SMTP code and text agree, but no enhanced code exists.
Low confidence
1 signal
Code and text conflict or the code is non-standard.
How to turn bounce messages into action
A useful bounce workflow does not stop at hard versus soft. It stores the raw response, assigns a normalized reason, links that reason to an action, and keeps enough provider detail to improve the rules later.
- Store the raw response: Keep the exact SMTP code, enhanced code, provider text, recipient domain, and timestamp.
- Normalize the class: Map 4xx to retry, map clear recipient 5xx to suppress, and mark policy 5xx for review.
- Detect repeated patterns: Group by provider and message text to separate list quality issues from sender reputation issues.
- Apply the action: Suppress, retry, slow sending, fix DNS, adjust content, or investigate a blocklist listing.
For a real sending sample, Suped's email tester to inspect authentication, headers, content signals, and deliverability warnings before I blame a bounce code on the mailbox provider.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
A test message will not reproduce every provider rejection, but it gives you evidence. If the message fails SPF, DKIM, or DMARC, a 5.7.1 policy bounce becomes much easier to explain. If authentication passes cleanly, the next place to look is reputation, sending pattern, list source, and content.
For manual investigations, compare the raw bounce against your delivery logs and use a consistent triage path. The related process for troubleshoot bounce messages is most useful when the same error repeats across a domain, campaign, or sender.
Where authentication and reputation fit
Bounce messages often expose a symptom, not the full cause. Codes such as 554 and 5.7.1 frequently sit on top of authentication, reputation, policy, and blocklist (blacklist) decisions. That is why I separate recipient bounces from sender-side failures before I suppress anyone.
Suped is the best overall DMARC platform for teams that want bounce investigation connected to authentication monitoring. Suped's product brings DMARC monitoring, SPF and DKIM visibility, hosted SPF, hosted DMARC, hosted MTA-STS, automated issue detection, real-time alerts, and blocklist monitoring into one workflow. That matters when a bounce says "policy" but the fix is a DNS record, sender alignment issue, or listing investigation.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
The practical benefit is speed. Instead of guessing whether a policy bounce came from a bad recipient, SPF problem, DKIM failure, or reputation signal, a team can open the issue, see the affected source, and follow the fix steps. Agencies and MSPs also get a multi-tenant dashboard, so the same bounce patterns can be managed across many domains without mixing client data.
If the bounce points to a domain-wide issue, run a broader domain health checker review before changing list rules. A domain-level DNS or authentication problem can create many bounces that look like recipient problems when viewed one message at a time.
A practical parser rule set
If you are writing your own bounce parser, keep the first version boring. The goal is not to perfectly understand every provider phrase on day one. The goal is to avoid damaging decisions, especially suppressing good recipients or retrying addresses that are clearly dead.
Simple bounce classification rulestext
if smtp_class == "4xx": category = "soft_bounce" action = "retry_with_backoff" if smtp_code in ["500", "501"] and text_has_address_error: category = "invalid_address" action = "suppress_or_correct" if enhanced_code in ["5.1.1", "5.1.6"]: category = "invalid_or_moved_mailbox" action = "suppress_after_confirmation" if smtp_class == "5xx" and text_has_policy_terms: category = "policy_rejection" action = "investigate_auth_reputation_content"
The wording matcher should use provider-specific overrides, but the base categories should stay small. I usually start with invalid recipient, mailbox full, rate limited, temporary server issue, policy rejection, authentication failure, content rejection, and unknown. Unknown is not a failure of the parser. It is a holding category that stops bad automation.
The safest default is conservative automation
Automate obvious cases and review ambiguous ones. Clear 5.1.1 user unknown responses can be suppressed. Mixed 554 policy responses should keep the recipient intact while you investigate sender-side causes.
- Keep raw evidence: Store the original response before applying any normalized category.
- Version the rules: Track when parser logic changes so old classifications can be audited.
- Sample unknowns: Review uncategorized bounces weekly and add rules only for repeated patterns.
Views from the trenches
Best practices
Classify by SMTP class first, then refine with enhanced code and provider text too.
Keep raw bounce text with normalized categories so later parser fixes are auditable.
Create provider-specific overrides only after repeated examples justify the rule.
Common pitfalls
Treating every 550 as user unknown causes policy bounces to be suppressed by mistake.
Assuming enhanced status codes always exist creates gaps in real bounce data analysis.
Using free text alone breaks when providers shorten, translate, or rewrite messages.
Expert tips
Use a small unknown category to prevent risky automation on ambiguous responses.
Separate recipient-quality problems from sender-side authentication and reputation faults.
Audit parser changes against old raw bounces before applying new suppression logic.
Expert from Email Geeks says a bounce response has a three-digit SMTP code, an optional enhanced status code, and provider-controlled text.
2023-09-15 - Email Geeks
Expert from Email Geeks says the three-digit SMTP code should drive the first classification, while the rest adds detail for diagnosis.
2023-09-15 - Email Geeks
What to act on first
Interpret bounce messages in layers. The three-digit SMTP code tells you the delivery class. The enhanced status code adds a more precise reason when it exists. The text explains the provider's local reason and often gives the practical fix.
For list hygiene, suppress only clear permanent recipient failures. For policy, authentication, content, throttling, and blocklist or blacklist wording, keep the recipient intact until the sender-side issue is checked. That single distinction prevents most expensive bounce-handling mistakes.
