Bounce Classification: Hard, Soft, and What Your Handling Logic Gets Wrong

Hard versus soft is not enough. How SMTP codes, enhanced status codes, and provider quirks should drive your retry, suppression, and reputation logic.

Every bounce handler starts with the same two buckets: hard bounces get suppressed, soft bounces get retried. That model was adequate when 5xx meant permanent and 4xx meant temporary. Modern mailbox providers use bounce codes to communicate reputation problems, policy failures, and rate expectations, and a handler that only knows hard and soft will misread all of them.

Three layers of information in every bounce

A rejection carries three layers. The basic SMTP reply code (450, 550) gives the outcome class. The enhanced status code (5.1.1, 4.7.28) gives a machine-readable reason, with the second digit identifying the subsystem: 1 for addressing, 2 for mailbox, 7 for policy and security. The free text after the codes carries the provider's actual explanation, often with a support URL.

550 5.1.1 The email account that you tried to reach does not exist.
550 5.7.1 Message rejected due to local policy. See https://...
550 5.7.26 This mail is unauthenticated. Verify SPF/DKIM alignment.

All three are 550s. The first is a dead address and belongs on the suppression list forever. The second is a policy block that may clear when your reputation recovers. The third is an authentication failure that no amount of suppression will fix, because the problem is your DNS, not their mailbox. A handler keying only on the 550 treats them identically and gets two of the three wrong.

The classes that matter operationally

Unknown user

5.1.1 and its provider variants are the cleanest signal in email. The address does not exist. Suppress on the first occurrence, without retry, and keep the suppression permanent. High unknown-user rates are also the primary input mailbox providers use to detect purchased lists, and sustained rates above roughly 1 to 2 percent start damaging reputation on their own.

Mailbox full and disabled

5.2.2 (over quota) and disabled-account responses occupy a middle ground. A full mailbox is temporary in protocol terms but behavioural in practice: an account over quota for three consecutive campaigns is abandoned. Abandoned mailboxes are exactly the population that becomes recycled spam traps. Give this class its own rule, for example suppression after full-mailbox bounces on three sends spanning at least 30 days.

Reputation and policy deferrals

4.7.x codes are where the hard/soft model fails hardest. A 421 4.7.28 from Gmail or a "deferred due to user complaints" from Yahoo is not a recipient problem to retry around; it is the provider telling you your traffic is suspicious right now. The correct response is to slow or pause the stream to that provider and investigate, because continuing to hammer a deferring MX confirms their suspicion.

Content and authentication rejections

5.7.1 policy rejections and authentication-specific codes like Gmail's 5.7.26 point at your configuration or your content, not your list. Route them to engineering review instead of the suppression pipeline. Suppressing a valid subscriber because your DKIM key rotation broke alignment converts a one-day infrastructure bug into permanent list loss.

Provider quirks that break naive parsers

Real-world bounce handling is pattern matching against inconsistency. Some business filtering stacks return 550 for greylisting-style checks that would clear on retry. Yahoo historically deferred with 421 messages referencing complaints for reputation issues. Microsoft's responses lean on descriptive text with error codes that need their own lookup table. Office 365 tenant-level policies produce 550 5.4.1 recipient-validation rejections that read like unknown users but reflect tenant configuration.

The lesson is not to memorize every string. It is to keep classification rules as data, not code, so patterns can be updated without redeploying the MTA, and to log the full response text so misclassifications can be audited later.

A saner default policy

Audit your handler against the classes above, not against the hard/soft split it advertises. The senders with durable deliverability are rarely the ones with the cleverest campaigns; they are the ones whose infrastructure listens when a mailbox provider says something in a bounce code.