Hard Bounce vs Soft Bounce: What to Do With Each
Hard bounce vs soft bounce: suppress hard bounces immediately, retry soft bounces on a bounded rule. 4xx vs 5xx SMTP codes, benchmarks, and pre-send checks.
Hard bounce vs soft bounce: what to do with each (and why the order matters)
I learned the difference the hard way, by watching the wrong one get retried. A bounce is a bounce in most dashboards — until the permanent ones pile up and a platform's bounce tripwire fires, and then the list you spent months building is one you can't mail at all. The two kinds of bounce want opposite handling, and mixing them up is one of the fastest ways to burn a sending reputation.
The short version: hard bounces get suppressed, never retried. Soft bounces get retried, then suppressed if they keep failing.
Hard bounce: permanent failure — suppress on the first one
A hard bounce means the address will not accept mail, now or later. Per the vendor guides (mailercloud ~8d ago,
smtp2go ~31d, litmus ~372d): the mailbox doesn't exist, the domain is dead or a typo, or the receiving server has
permanently refused the address — the enhanced SMTP code starts with 5 (e.g. 550 5.1.1, "user unknown").
That matches RFC 3463's definition of the 5.x.x class: a permanent failure, not likely to be resolved by resending
the message in its current form.
Action: remove the address from all active sequences immediately, and never mail it again.
The mistake I see most: people "pause" a hard bouncer and re-add it when the list gets thin. Providers read repeat sends to dead addresses as a list-quality signal — a pile of them is exactly what gets your sending restricted. Suppression means suppressed: export it to your suppression list, not back to the active list.
A practical threshold from the deliverability references (GitHub skill-doc ~60d): a hard bounce rate above 3% on a fresh list means the data source is bad — fix it upstream, not at send time.
Soft bounce: temporary failure — retry with a rule, then stop
A soft bounce means the address is real but the mail couldn't land this time: full mailbox, server temporarily
down, message too large, throttling or greylisting (SMTP code starts with 4, e.g. 421, 451 — RFC 3463's
4.x.x class: a persistent transient failure, where sending in the future may be successful). The consensus across
the guides (litmus, smtp2go, loops ~30d): retry — but on a bounded rule.
A rule that works: retry 2–3 times over 24–72 hours, spaced hours apart; if an address soft bounces 3+ times with no engagement, treat it like a hard bounce and suppress it. (litmus: "remove the email from your list after three bounces"; a ~60d-old deliverability reference: "after 3 soft bounces on same address: treat as hard bounce and suppress".)
The pattern to watch: consistent soft bounces from one domain are often a block in progress — they'll escalate to hard bounces soon. That's the kind of signal a pre-send screen catches before you pay for it in reputation.
Keep the numbers under the ceilings
Total bounces under 2%, hard bounces under 1% — the per-guide rule of thumb (mailercloud ~8d; a deliverability reference ~60d puts the "healthy" bounce-rate band under 1% and "critical" above 2%). These are third-party benchmarks, not platform rules — your platform's real tripwire is in its own docs, and suppression/retry policies differ across ESPs, so check the one you're actually sending on.
The pre-send version of this whole page
Everything above is reactive: you wait for the bounces, then triage. The cheaper move is running the screen before the send — the audit flags addresses by category so the hard bounces never leave your machine:
- Deliverable — valid, send it.
- Risky — probably real, low-engagement patterns; watch it.
- Catch-all — domain accepts everything; mail it but never use it in a calibration sample.
- Disposable — throwaway address; suppress.
- Invalid — dead address or dead domain; suppress before the send, not after the bounce.
Your sender setup (SPF/DKIM/DMARC) is checked against public DNS records. Mailbox-level SMTP probing is not part of a standard pre-send screen — we don't sell stages we haven't built.
The pre-send screen, done for you
For lists where guessing wrong costs more than an audit (a platform warning, a tripwire already tripped, a campaign you can't afford to soft-bounce into): a fixed-price, 7-day ListProof pre-send screen with a stated hard-bounce prediction figure for your list in writing, before you send a single message.
If the prediction is wrong, we re-run the analysis free — within 30 days of receiving the findings. Manual invoice; current pricing on request.
No guaranteed bounce rate; this is a forecast, not a crystal ball.
Keep Exploring
Use the Workflow Library to browse more guides, comparisons, and integration examples to continue your evaluation.
See the solutions, comparisons, and integration guides collected in one place.
Review grounded audit, compare, fix-plan, and report excerpts before you wire the API into anything.
Jump from the workflow page into the quickstart, endpoint guides, and full OpenAPI reference.
Check Your Sender Setup Free
Bounce handling protects your list. Your sender authentication (SPF/DKIM/DMARC) protects your reputation - check it free before your next send.