Whenever a message cannot be delivered, the receiving server says so. Sometimes it does so immediately, rejecting the message during the SMTP conversation; other times it accepts it and later returns a non-delivery notice. Either way we call it a bounce. Handling bounces properly is one of the most tedious and most important jobs for anyone sending mail at volume: a high share of non-existent addresses is one of the clearest signals to providers that a list is old or poorly collected.
Two families of bounces
Hard bounce: permanent failure
A hard bounce means the problem will not go away by retrying. Typical cases are:
- the mailbox does not exist, for example because of a typo or because the account was closed;
- the recipient's domain does not exist or has no mail servers;
- the server rejects the message permanently because of a policy rule.
After a hard bounce caused by a non-existent address, that address must be suppressed immediately. Insisting achieves nothing and harms your reputation.
Soft bounce: temporary failure
A soft bounce signals a transient problem: a full mailbox, a server that is briefly unavailable, a rate limit exceeded, a message deferred for extra checks. The sending server usually retries for a while before giving up. The address is still valid, but if it keeps bouncing for weeks it should be treated as lost.
Reading the codes
SMTP replies carry a three-digit code: those starting with 4 are temporary, those starting with 5 are permanent. Next to it there is almost always an enhanced status code in the form class.subject.detail, defined by the standards, which is more precise.
| Code | Typical meaning | Action |
|---|---|---|
550 5.1.1 |
mailbox does not exist | suppress |
550 5.1.10 or 5.1.2 |
recipient or domain cannot be resolved | suppress |
452 4.2.2 |
mailbox full | retry, then review |
421 4.7.0 or 451 4.7.x |
throttling or temporary policy rejection | slow down, retry |
550 5.7.1 |
policy rejection, often reputation or authentication | investigate, don't suppress blindly |
554 5.7.x |
message blocked as spam or for content | investigate |
The last column holds the most overlooked point. Not every 5xx code means «dead address». A 5.7.1 whose text mentions authentication or reputation tells you the recipient exists but does not want your message. Suppressing that address hides the problem instead of solving it, and if the same error comes from thousands of mailboxes at a single provider, the problem is yours, not the list's.
The text matters as much as the number
Providers add a descriptive sentence to the code, often with a link to their own help page. That sentence should be read and, when volumes justify it, analysed in aggregate. Grouping bounces by provider and by message text quickly shows whether there is an abnormal spike: a sudden wave of temporary rejections from one provider usually points to a reputation problem or excessive volume, not to bad addresses.
Synchronous and asynchronous bounces
When the rejection happens during the SMTP session, the sender sees it at once and the platform records it precisely. Some servers, however, accept everything and only later generate a non-delivery notice, sending it to the Return-Path address. That is why the Return-Path must point to a mailbox or system that processes these messages automatically. Sending platforms use a unique return address per recipient, so that every notice is tied to the right contact even when its text is ambiguous.
A clear suppression policy
Modern platforms handle most of this work, but the rules should be understood and, where possible, chosen. A reasonable policy looks like this:
- hard bounce for a non-existent address or domain: immediate, permanent suppression;
- isolated soft bounces: no action, automatic retries are enough;
- repeated soft bounces on the same address across different sends, say three or four in a row: suppression;
- policy rejections: no automatic suppression, but an alert if they exceed a threshold;
- suppressed addresses: never re-imported from external files without fresh confirmation.
The last point prevents a common mistake: exporting a list, cleaning it elsewhere and re-importing it, bringing back exactly the addresses the platform had excluded.
How much is too much
There is no official threshold that applies to everyone, but as a rule of thumb a hard bounce rate consistently above 2% on a send to an established list is a warning sign. A list collected with double opt-in and maintained regularly generally stays well below that figure. If a single send is far above average, the most likely cause is an old segment or a recent import.
In short
- Hard bounces are permanent and call for immediate suppression of the non-existent address.
- Soft bounces are temporary: retry, and suppress only after repeated bounces.
5.7.xcodes often indicate a reputation or authentication problem, not an address problem.- The Return-Path must lead to a system that processes non-delivery notices automatically.
- Suppressed addresses must never be re-imported without fresh confirmation.
