SMTP Bounce Codes: Complete Reference Guide

When an email delivery attempt fails, receiving mail transfer agents (MTAs) emit standardized SMTP bounce codes that diagnose the exact technical failure condition.

Rather than treating all bounces as generic delivery errors, engineering and operations teams must decode the underlying status codes to automate list hygiene, triage configuration failures, and protect domain reputation. While legacy systems rely on basic three-digit RFC 821 response codes, modern internet mail systems standardize on RFC 3463 and RFC 5321 Enhanced Mail System Status Codes. Decoding this granular telemetry is essential to distinguishing between transient network hiccups and catastrophic hard bounces that demand immediate suppression.

Code Structure

Modern enhanced status codes follow an explicit X.Y.Z hierarchical syntax that decouples failure severity, operational subsystem, and root cause detail:

• Class Identifier (X): The first digit defines the overall disposition of the transaction. A 2.X.X indicates a successful transaction; a 4.X.X denotes a persistent transient failure (the email is deferred, kept in queue, and retried automatically); while a 5.X.X represents a permanent failure (the message is fatally rejected and must never be retried).
• Subject Subsystem (Y): The second digit pinpoints the operational domain responsible for the issue: .1 Addressing and mailbox identification, .2 Mailbox capacity, .3 Mail transfer system state, .4 Network and routing resolution, .5 Protocol syntax, .6 Media and content formatting, or .7 Security policy and anti-abuse enforcement.
• Detail Specification (Z): The final integer identifies the precise granular condition within that subsystem.

Common Codes

In production delivery environments, five primary status codes account for the overwhelming majority of bounce logs:

• 550 5.1.1 (Bad Destination Mailbox Address / User Unknown): A fatal hard bounce. The destination mailbox does not exist on the remote mail server. Continued dispatches to 5.1.1 addresses signal directory harvesting attacks and trigger immediate Spamhaus blacklisting.
• 552 5.2.2 (Mailbox Storage Exceeded / Full Inbox): A soft bounce indicating the recipient's storage quota is exhausted. While transient, mailboxes that remain full for more than 7 consecutive days typically indicate abandoned accounts that ISPs will soon shut down or convert into recycled spam traps.
• 421 4.7.0 (Connection Rate Limited / Throttle Triggered): A transient deferral indicating the receiving server is throttling incoming connections due to sudden sending volume bursts or negative IP reputation.
• 550 5.7.1 / 5.7.26 (Policy Rejection / Authentication Failure): The receiving server rejected the message due to anti-spam heuristics, blocklist inclusion, or failed SPF/DKIM alignment under a strict DMARC p=reject mandate.
• 451 4.4.0 (DNS Resolution Failure / Greylisting): A temporary server-side deferral instructing your MTA to pause and re-attempt delivery later.

How to Handle

Automate bounce processing through disciplined webhook ingestion and MTA queue rules:

• Zero-Tolerance Hard Bounce Suppression: Configure sending systems to process 5.1.1 and 5.1.2 bounce postbacks immediately. Suppress or delete these contacts in real time; never attempt to re-send to an address that threw a permanent hard bounce.
• Intelligent Exponential Backoff for 4xx Deferrals: Queue 4.X.X messages and re-attempt transmission using spaced intervals (e.g., retrying after 15 minutes, 1 hour, 4 hours, and 12 hours). Expire deferred messages and notify senders if delivery remains unfulfilled after 48 to 72 hours.
• Pre-Send Verification Guardrails: Prevent hard bounces from ever hitting remote servers by validating recipient lists with the MailVeri Email Checker prior to dispatch. Pre-verifying contact databases ensures bounce rates stay strictly below the critical 1.5% threshold.