Every deliverability incident eventually surfaces in the bounce log. A campaign that looked healthy at send time starts returning a wave of rejections an hour later, and the operator has minutes to decide whether the problem is a bad list, a reputation hit, a content trigger, or an authentication regression. Reading SMTP reply codes accurately is the difference between a five-minute fix and a week-long warm-up to recover a domain.
The mental model: permanent vs temporary, mailbox vs policy
Every SMTP reply is two things at once: a class (permanent or temporary) and a reason (mailbox-level or policy-level). The class is encoded in the first digit — 4 for temporary, 5 for permanent — and the reason sits inside the enhanced status code (the dotted triplet like 5.7.1). Treat the two dimensions independently. A 4xx mailbox-full bounce and a 4xx reputation throttle look similar at a glance but require opposite responses: the first is a per-recipient retry, the second is a campaign-level pause.
The enhanced status codes are defined in RFC 3463. The first digit of the triplet mirrors the SMTP class. The second digit narrows the category: 1 is addressing, 2 is mailbox, 3 is mail-system, 4 is network, 5 is protocol, 6 is content, 7 is policy and security. The third digit is the specific reason. A code of 5.7.1 therefore reads as "permanent, policy, generic rejection" — almost always a sender-side problem rather than a recipient-side one.
Reading the signals: a lookup table for common codes
The table below covers the codes that account for the large majority of bounces seen at Gmail, Outlook, Yahoo, and most enterprise mail servers. Wording varies by provider, but the action column generalises.
| Code | Meaning | Action |
|---|---|---|
| 421 4.7.0 | Temporary reputation or rate-limit throttle (Gmail, Yahoo) | Retry with backoff; if persistent, pause and audit reputation |
| 421 4.4.5 | System-side congestion at the receiver | Retry; no sender action required |
| 451 4.7.1 | Greylisted or temporary policy deferral | Retry after 5 to 15 minutes; typical for cold senders |
| 452 4.2.2 | Mailbox over quota | Retry for several days; suppress only after persistent failure |
| 550 5.1.1 | Recipient address does not exist (unknown user) | Suppress immediately; counts toward unknown-user rate |
| 550 5.1.10 | Recipient address rejected (Outlook variant) | Suppress; verify list source |
| 550 5.2.1 | Mailbox disabled or inactive | Suppress; classic abandoned-account signal |
| 550 5.7.1 | Policy rejection (authentication, IP block, content) | Investigate sender-side; do not suppress recipient |
| 550 5.7.26 | Gmail: failed SPF or DKIM alignment with From domain | Fix authentication alignment; do not suppress |
| 553 5.1.8 | Sender address rejected (often invalid Return-Path) | Fix Return-Path or bounce domain |
| 554 5.7.1 | Transaction failed, generic policy block | Check blocklist status and content; investigate IP and domain |
| 554 5.7.9 | Message refused: authentication required | Authenticate properly; check DMARC alignment |
Two provider quirks are worth memorising. Gmail returns 421-4.7.0 with a URL to its postmaster docs when it is throttling on reputation; the URL fragment in the response often hints at whether the cause is bulk compliance, spam content, or unauthenticated mail. Outlook returns 550-5.7.1 with a token like S3140 or S3150 — the token is the actual diagnostic, not the prose. Build your bounce parser to extract those provider-specific tokens, not just the triplet.
Invalid addresses: the slow reputation killer
A 5.1.1 unknown-user response on a single message is harmless. A 5.1.1 rate above 2 percent on a campaign is a domain-reputation event. Gmail and Outlook both maintain a rolling view of how often a sender hits non-existent addresses; the rate is treated as a proxy for list quality and acquisition hygiene. Sustained unknown-user rates predict spam-trap hits, and trap hits cause direct reputation drops that take weeks to recover from. The list hygiene lesson covers the acquisition and validation patterns that prevent this; the operational rule is simpler: suppress hard bounces on first occurrence, and never re-attempt a suppressed address without a verification step.
Action playbook
When hard bounces spike on a single campaign
- Confirm the spike is real by checking the bounce timestamp distribution. A flat curve across the campaign is a list-quality problem; a sharp post-send cliff is often a downstream filter.
- Group bounces by enhanced status code. If 5.1.1 dominates, the segment is stale or poorly acquired. If 5.7.x dominates, it is a policy issue and the recipients are real.
- Pull the segment definition and check the last engagement date for the bouncing cohort. Segments that include addresses inactive for more than 12 months are the usual culprit.
When soft bounces dominate
- Separate 4.2.2 mailbox-full from 4.7.x policy deferrals. The first group is recipient state and resolves itself; the second is a reputation conversation.
- For 4.7.0 from Gmail at scale, pause the IP or domain immediately, check the Postmaster Tools domain reputation graph, and resume only after the rate-limit response clears for several hours of low-volume sending.
- For greylisting (451 4.7.1) from a small receiver, simply retry — it is normal behaviour for cold or low-volume senders and not a reputation signal.
When 5.7.26 or 5.7.9 appears
Both codes mean authentication is the problem, not the recipient. Audit SPF (see SPF explained) and DKIM (see DKIM explained) alignment with the visible From domain. Run the From domain through the DMARC checker and confirm the published policy matches the alignment your ESP can produce. Almost every 5.7.26 incident traces back to a sending stream that authenticates as a different domain than the one in the From header.
Bounce parsing as an engineering discipline
The biggest operational mistake is treating bounces as a binary suppress/retry flag. A modern bounce pipeline stores the full SMTP response, the enhanced status code, the receiving MX, the provider-specific diagnostic token, and the campaign and segment IDs. That structure lets you answer the questions that matter during an incident — is this a list problem or a reputation problem, is it concentrated at one provider, and is the trend improving or worsening — within minutes instead of hours.
Bounces are the cheapest deliverability telemetry you have. Treat them as primary signal, not exhaust.
Looking for the short definition? See email bounce in the glossary.