Bounce handling: how to tell a soft bounce that should be treated as hard

Bounce handling is usually implemented once, correctly, for the obvious case: a 5xx permanent failure means remove the address. The part that gets left out is what to do about a 4xx temporary failure that has now happened eleven times to the same address.

Those are the addresses quietly damaging your reputation, because you keep trying and the receiving server keeps declining, which is exactly the pattern a filter is built to notice.

Classify on the code, then on the repetition

The SMTP response has an enhanced status code that says more than the 4xx/5xx split does. Read it, store it, and act on it.

• 5.1.1 and its relatives — no such mailbox. Permanent. Suppress immediately and for ever.
• 5.2.2 — mailbox full. Reported as permanent by some servers and temporary by others. Treat as soft, with a short leash.
• 5.7.x — policy rejection. This is not an address problem, it is a you problem: content, authentication or reputation. Do not suppress the address; investigate the send.
• 4.x.x — temporary. Greylisting, rate limiting, transient outage. Retry.

The rule that matters

The practical rule most senders converge on:

1. Soft bounce on three consecutive sends to the same address, over at least two weeks, and it is suppressed as if it were hard.
2. Any 5.1.1, once, and it is suppressed immediately.
3. Mailbox full for a month and it is suppressed. Abandoned mailboxes fill up and then become recycled spam traps, which is the specific thing you are trying to avoid.
4. Reset the counter on a successful delivery, so a genuine outage does not accumulate against an address that is fine.

A retry schedule that does not make things worse

Retrying immediately and often is the instinct and it is wrong. Greylisting in particular expects a delay, and hammering looks like a spam source.

• First retry after 15 minutes, then back off — an hour, four hours, a day.
• Stop after about 48 hours. Mail that has not been accepted in two days is not going to be, and a marketing message is stale anyway.
• Never retry a 5xx. It is permanent by definition, and retrying is how you tell a receiving server you are not reading its answers.
• Respect explicit rate limiting. If a provider is deferring you on volume, slow down rather than parallelising.

Policy rejections are the interesting ones

A 5.7.1 is the server saying the message was refused on policy grounds — and the address is usually fine. Suppressing it, which many systems do because the code starts with 5, removes a perfectly good customer and hides the real problem.

1. Group policy rejections by receiving domain. One provider rejecting means something specific about your relationship with that provider.
2. Check authentication first. A large share of policy rejections are alignment failures after a DNS or provider change.
3. Check the content second — a new link shortener, a new sending IP, an attachment.
4. Do not suppress unless it repeats across providers, which makes it a reputation problem rather than a policy one.

What to keep an eye on

• Bounce rate per send, with 2 % as the line where you stop and verify rather than continue.
• Bounce rate per receiving domain. A spike at one provider is a different problem from a spike everywhere.
• The suppression list's growth rate. Sudden growth means an import, a form problem or a list you should not have sent to.
• Addresses that bounce on their first ever send. These point straight at acquisition — a form without validation, or a source you cannot vouch for.