Email bounces: hard, soft, and what to do with each
A bounce is a delivery failure with a reason attached. Hard versus soft, the SMTP codes underneath, and the handling rules that protect your reputation.
A bounce is a failed delivery attempt reported back to the sender, either immediately during the SMTP conversation or later as a returned message. Every bounce carries a reason, and the reasons matter more than the count: they tell you whether an address is dead, a mailbox is full, a receiver is throttling you, or your own configuration broke. Handling bounces correctly is one of the highest-leverage habits in deliverability, because unknown-user rates are a primary list-quality signal to every mailbox provider.
Hard and soft, and the codes underneath
The classic binary: a hard bounce is permanent (the address does not exist, the domain is dead), a soft bounce is temporary (mailbox full, server busy, message deferred). Underneath sit the SMTP reply codes, 5xx for permanent and 4xx for temporary, refined by enhanced status codes (RFC 3463) whose second digit names the subsystem: 5.1.1 is an unknown address, 5.2.2 a full mailbox, 4.7.x a policy or reputation deferral. The binary is a summary; the codes are the diagnosis, and modern providers use them to communicate reputation problems, not just recipient states.
The bounce classes that matter
| Feature | Typical codes | Correct handling |
|---|---|---|
| Unknown user | 550 5.1.1 | Suppress permanently on first occurrence |
| Mailbox full / disabled | 452, 5.2.2 | Retry now; sunset after repeats across 30+ days |
| Temporary server trouble | 421, 4.2.x | Retry with backoff over 24 to 72 hours |
| Reputation deferral | 421 4.7.x | Slow down to that provider and investigate; do not hammer |
| Policy / authentication rejection | 550 5.7.x | Route to engineering; the fault is configuration, not the recipient |
Why bounce rates matter to reputation
Mailbox providers read your unknown-user rate as a direct measurement of list quality: purchased and scraped lists announce themselves through it, and sustained rates above roughly 2% start damaging reputation on their own. Ignoring bounces compounds the damage: addresses that keep hard-bouncing are the population that becomes recycled spam traps, so a broken bounce handler today is a trap incident next year. Healthy programs keep hard bounces under 2% of delivered volume, ideally under 1% on established lists.
A handling policy that protects you
Bounce processing rules
- 1
Capture the full response
Store SMTP code, enhanced status code, and response text on every bounce event; the text carries the provider's actual explanation.
- 2
Suppress dead addresses immediately
Unknown-user responses suppress the address permanently on the first occurrence, no retries.
- 3
Retry true temporaries with backoff
Full mailboxes and server trouble retry on an exponential schedule before converting to a final failure.
- 4
Treat 4.7.x as a sender problem
Reputation deferrals mean the provider distrusts your traffic right now; automatic slowdown plus a human look, never full-speed retries.
- 5
Sunset chronic soft bouncers
Addresses soft-bouncing across multiple campaigns over 30+ days move to suppression before they decay into traps.
Frequently asked questions
What is an acceptable bounce rate?
Should bounced addresses ever be retried later?
My ESP shows only hard and soft counts. Is that enough?
Do bounces themselves hurt my reputation, or just signal problems?
Key takeaways
- Hard bounces are permanent, soft are temporary, and the SMTP plus enhanced status codes carry the real diagnosis
- Unknown users suppress permanently on first occurrence; their rate is a list-quality signal providers score
- 4.7.x deferrals are reputation messages to slow down, not recipient problems to retry around
- Authentication and policy rejections route to engineering, never to the suppression list
- Keep hard bounces under 2%, and sunset chronic soft bouncers before they become recycled traps