Operating Since 2015
4xx = Temporary (retry) · 5xx = Permanent (suppress immediately)
The codes below cover the responses that produce 95%+ of operational decisions in a typical sending environment. The complete list at each provider runs to dozens of variants, but the recurring patterns reduce to a handful of cases. What separates production-ready bounce processing from a basic implementation is not coverage of obscure codes — it is consistent handling of the common ones.
Two operational notes before the tables. The 4xx vs 5xx distinction is binary in the SMTP spec but fuzzier in practice: a 4xx that recurs across all retries should be treated as a hard fail and suppressed, not kept in the retry queue indefinitely. Conversely, some 5xx codes (Microsoft 5.7.606 in particular) are recoverable through manual remediation rather than permanent. The "Action" column captures the right operational response, which is sometimes different from what the code class would suggest.
Gmail Codes
Gmail's bounce text is well-documented in Postmaster Tools v2 (launched September 2025, replacing the Domain Reputation gauge). The 4.7.0 RP-prefixed codes are reputation-driven; the 5.7.x codes are policy or authentication-driven. Reading the text after the code matters: "RP" indicates reputation, "PS" indicates policy/spam, "AUTH" indicates authentication problems.
| Code | Text | Meaning | Action |
|---|---|---|---|
| 421 4.7.0 (RP) | Reputation deferral | IP reputation too low for volume | Reduce max-smtp-out 50%; check Postmaster Tools |
| 550 5.7.1 | Policy rejection | IP or domain policy block | Check spam rate; reduce volume |
| 550 5.7.26 | DMARC failure | DMARC alignment fail | Verify DKIM; check SPF alignment |
| 550 5.7.28 | SPF failure | Sending IP not in SPF | Update SPF record |
| 550 5.1.1 | User unknown | Invalid address | Hard bounce — suppress |
Microsoft/Outlook Codes
Microsoft's bounce taxonomy uses RP-NNN, S-NNN, and SC-NNN prefixes where the prefix indicates the cause family. RP is reputation, S codes are sender-related (authentication, content), SC codes are spam content. Microsoft tolerates lower complaint rates than Gmail before triggering filtering — the practical ceiling is around 0.05-0.08% complaint rate, lower than Gmail's published 0.10% threshold.
The Microsoft sendersupport.olc.protection.outlook.com escalation path is real and worth using when a 5.7.606 block appears. Manual review takes 24-72 hours but unblocks IPs that other providers' algorithmic remediation never would. Keep records of authentication completeness and recent volume patterns to support the request.
| Code | Text | Meaning | Action |
|---|---|---|---|
| 421 RP-001 | Connection rate exceeded | Too many connections | Reduce max-smtp-out; retry-after 30m |
| 550 5.7.606 | IP permanently blocked | Microsoft internal block | Contact sendersupport.olc.protection.outlook.com |
| 550 SC-001 | Spam content | Content-based block | Review content; check URL reputation |
Yahoo Codes
Yahoo's TSS-prefixed codes (TSS04 in particular) are throttling rather than rejection — the message is being deferred to slow your rate, not refused outright. Healthy senders see steady-state TSS04 rates around 5-15% during normal sending; spikes above 30% indicate either volume growing past your warmed capacity or reputation degradation. Yahoo Sender Hub gives near-real-time visibility into both.
CS-prefixed codes (CS04 above) are complaint-driven and harder to recover from than reputation-driven throttles. Yahoo's complaint threshold is documented at 0.10% per the Feb 2024 bulk-sender requirements (aligned with RFC 8058 one-click unsubscribe). Sustained CS04 deferrals require list segmentation work, not just sending pace adjustments.
| Code | Text | Meaning | Action |
|---|---|---|---|
| 421 4.7.1 TSS04 | Throttle | Volume throttle (normal at scale) | Normal retry; monitor deferral rate |
| 421 4.7.1 CS04 | Complaint block | High FBL complaint rate | Check FBL data; improve list quality |
| 550 5.7.1 BL23 | IP blacklisted | Yahoo internal block | Reduce volume; check Yahoo Postmaster |
Generic SMTP
The codes in this section follow RFC 3463 (Enhanced Mail System Status Codes) and apply broadly across providers including corporate mail servers, smaller ISPs, and Microsoft 365 tenants. The 5.1.x family always indicates mailbox or addressing problems (suppress immediately); 4.2.x indicates capacity (retry with backoff); 5.7.x indicates policy or authorisation (investigate before retrying).
| Code | Meaning | Classification |
|---|---|---|
| 550 5.1.1 | User unknown / mailbox not found | Hard bounce — suppress |
| 550 5.2.1 | Mailbox disabled | Hard bounce — suppress |
| 452 4.2.2 | Mailbox full | Soft bounce — retry 3x then suppress |
| 501 5.1.3 | Bad address syntax | Hard bounce — suppress |
Bounce Processing Operational Rules
Three rules cover the operational decisions most senders need to make. First, suppress 5xx codes immediately on first occurrence — do not retry, do not give the address a "second chance" on the next campaign. Re-sending to known-invalid addresses is the fastest route to Spamhaus listing and produces no upside. Second, treat repeated 4xx codes as 5xx after 72 hours of retry attempts. PowerMTA's retry-after directives handle this if configured; without explicit configuration, the default behaviour can leave deferred messages in queue for 5+ days, which damages reputation. Third, log the bounce code and text verbatim. The text after the code carries diagnostic information (provider-specific identifiers, transient vs sustained signals) that aggregate counts hide.