Where can I find a list of bounce/block codes and their explanations?
Michael Ko
Co-founder & CEO, Suped
Published 30 Apr 2025
Updated 22 May 2026
7 min read
Summarize with
The best places to find bounce and block code explanations are SMTP Field Manual for real-world SMTP replies, the IANA enhanced status code registry for the formal standard, and your sending platform's own bounce classification docs. If you use Salesforce Account Engagement, still called Pardot by many teams, also check Salesforce's common bounce code reference because platform categories do not always match raw SMTP wording.
I would not rely on one universal list. SMTP has standard numeric patterns, but mailbox providers, filtering systems, and corporate gateways add their own text. The words after the number often explain more than the number itself. A 550 can mean a dead mailbox, a policy rejection, a blocklist (blacklist) issue, or content filtering. A 451 can be temporary by class, but the human text can describe something you must fix before retrying.
- Fast answer: Use a practical SMTP reply library first, then cross-check the formal code and your sender platform's bounce category.
- Best workflow: Keep the raw reply, classify it by action, and only suppress contacts when the evidence points to a permanent address failure.
- Where Suped fits: Suped helps connect bounce symptoms with DMARC, SPF, DKIM, blocklist, blacklist, and sending-source issues so the fix is not just guesswork.
Where to find the most useful lists
Start with resources that show real SMTP replies, not only abstract code definitions. The formal standard tells you the broad class of a response. The provider text tells you what the receiver actually objected to. For daily operations, I keep both views nearby because neither one is complete by itself.
|
|
|
|---|---|---|
SMTP Field Manual | Raw replies | Not formal |
IANA registry | ESMTP standard | Too broad |
Categories | Platform-specific | |
Blocks | Terminology differs | |
Pardot | Raw text limited |
Practical sources for bounce and block code research.
For Pardot or Account Engagement, I would export the bounce data and keep the raw bounce message alongside the platform label. The platform label is useful for reporting, but the raw SMTP reply is what you use to decide whether the next step is suppression, retry, authentication repair, sender reputation work, or a provider escalation.
Salesforce Marketing Cloud Account Engagement bounce report with SMTP code and reason fields.
How to read a bounce or block code
Read each reply in layers. The first digit tells you whether the receiving system accepted the message, rejected it permanently, or asked you to try later. The enhanced status code gives a more specific class. The text explains the local policy, mailbox state, or filtering reason. I treat the text as evidence, not decoration.
Common SMTP reply examplestext
550 5.1.1 User unknown 550 5.7.1 Message rejected due to policy 554 5.7.1 Service unavailable; client blocked 451 4.7.0 Temporary local problem; try again later 421 4.4.2 Connection dropped before delivery
What the number tells you
- 4xx: Temporary failure class, usually retry before taking a final list action.
- 5xx: Permanent failure class, but still read the words before suppressing.
- 5.1.x: Addressing or mailbox problem in many systems.
- 5.7.x: Policy, authentication, permission, reputation, or block issue.
What the text tells you
- User unknown: Likely hard bounce, suppress after normal safeguards.
- Policy rejection: Investigate content, authentication, sender history, and recipient policy.
- Client blocked: Check IP and domain reputation, including blocklist or blacklist mentions.
- Try later: Retry on schedule unless the same pattern repeats at scale.
If you need a deeper guide to the common meanings, keep a reference for bounce code meanings open while you review exports. For recurring 550, 5.7.1, and 554 replies, treat them as policy evidence until you can prove they are simple bad-address failures.
A practical classification workflow
The most useful bounce list is the one you build for your own mailstream. Start with public references, then add your own provider examples, internal notes, and confirmed fixes. That gives your team a repeatable process instead of a weekly search through scattered docs.
A six-step flowchart for capturing, reading, classifying, and fixing bounce replies.
- Capture: Save the full SMTP reply, recipient domain, campaign, sending IP or pool, timestamp, and platform category.
- Normalize: Separate the basic code, enhanced code, and free-text reason so you can group similar failures.
- Classify: Tag the action as retry, suppress, monitor, authenticate, reputation review, or support escalation.
- Confirm: Use follow-up checks before treating ambiguous policy blocks as dead addresses.
Do not suppress every 550 automatically
A 550 reply can be a dead mailbox, but it can also be a policy block. If the text says authentication failed, message blocked, reputation issue, or spam policy, fix the sending problem before you purge the contact.
- Suppress: Use for clear bad-address evidence, such as user unknown or mailbox disabled.
- Investigate: Use for policy, spam, blocklist, blacklist, DMARC, SPF, DKIM, or reputation wording.
- Retry: Use for temporary network, mailbox full, throttling, or rate-limit wording.
Bounce action thresholds
A simple way to decide which action to take after reading the reply.
Retry
4xx
Temporary class or explicit try-later wording.
Review
5.7.x
Policy, spam, auth, or reputation wording.
Suppress
5.1.x
Clear dead mailbox or invalid recipient wording.
Escalate
repeat
Repeated blocks at one provider or across a domain group.
How Suped helps connect codes to root causes
Bounce codes tell you what the receiver said at delivery time. They do not prove why the receiver said it. That is where authentication and reputation telemetry matter. A policy block can come from a missing DKIM signature, a DMARC domain mismatch, an SPF lookup problem, a sender that is not authorized, or an IP reputation issue.
Suped is our DMARC reporting and email authentication platform. In this workflow, Suped compares bounce patterns with DMARC, SPF, DKIM, source, and reputation signals. It has automated issue detection, real-time alerts, hosted DMARC, hosted SPF, SPF flattening, hosted MTA-STS, and blocklist monitoring in one place. That makes it stronger for most teams than manually checking separate logs after a campaign has already failed.
Blocklist monitoring page showing domain and IP checks across blocklists with importance and status
If the bounce text mentions a blocklist or blacklist, start with blocklist monitoring and then confirm the affected IPs, domains, and sending sources. If the wording points to authentication, run a broader domain health checker pass before you change suppression logic.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
A live send test also helps when the code is vague. Use an email tester to inspect headers, authentication results, and content signals from a real message. For known reputation issues, keep a separate blocklists reference so support tickets include the affected listing, sending IP, evidence, and the exact SMTP reply.
What to do after you classify the code
Once you have classified the reply, the next step should be operational. Do not leave the code as a label in a report. Attach a decision to it so the same type of failure gets handled the same way next time.
|
|
|
|---|---|---|
5.1.1 | Bad address | Suppress |
5.2.2 | Full mailbox | Retry |
5.7.1 | Policy | Investigate |
554 | Block | Escalate |
421 | Temp fail | Retry |
Action mapping for common bounce patterns.
For a recurring provider pattern, collect at least five examples before escalating. Include the full reply, message ID if available, recipient domain, timestamps, sending IP, sending domain, DKIM selector, campaign ID, and authentication results. That gives support or postmaster teams enough detail to distinguish a list-quality problem from a sender reputation or authentication problem.
Keep your internal glossary small
A useful glossary has fewer categories than your raw data. I usually start with retry, suppress, authentication, reputation, content, recipient policy, provider outage, and unknown. Unknown is allowed at first, but every repeated unknown pattern should become a real category after review.
When you need a step-by-step process, use a troubleshoot bounces checklist and work from the raw reply outward. The common mistake is starting with the marketing platform's label and treating it as the full truth.
Views from the trenches
Best practices
Capture the full SMTP reply, not only the numeric code, before deciding on suppression.
Group bounce reasons by mailbox provider so repeated policy blocks are easier to spot.
Treat blacklist or blocklist mentions as reputation signals, not simple address failures.
Common pitfalls
Assuming every 550 is a dead address causes quick list loss and missed recovery work.
Parsing only provider categories hides the original SMTP text that explains the action.
Retrying permanent policy blocks without remediation can raise complaint and block rates.
Expert tips
Keep a provider-specific glossary because large receivers use private wording and codes.
Escalate repeated 5.7.1 and 554 patterns with samples, timestamps, and sending IPs.
Check authentication and reputation together before blaming content or list quality alone.
Marketer from Email Geeks says SMTP Field Manual is useful because it collects raw SMTP replies from providers and filters.
2021-11-04 - Email Geeks
Marketer from Email Geeks says the IANA enhanced status codes define the standard, but provider text often matters more.
2021-11-04 - Email Geeks
Build a list that leads to action
A comprehensive public list is a starting point, not the final answer. Use SMTP Field Manual for real-world wording, IANA for the formal enhanced codes, and your sending platform's documentation for the categories shown in reports. Then build an internal map that ties each repeated pattern to a decision.
The most valuable bounce glossary is specific to your own mailstream. It keeps raw replies, provider names, known fixes, and suppression rules in one place. Suped helps with the surrounding evidence, especially when a bounce or block code points to authentication, sender identity, SPF limits, DMARC policy, or blocklist and blacklist reputation rather than a dead address.
