Home / Glossary / Hard vs Soft Bounce
DeliverabilityHard bounce vs soft bounce: what actually failed?
Updated August 2026 // by Mark Glazer // read the rejection string before blaming the list
A hard bounce is a permanent failure: the receiving server rejected the message with a 5xx code because the address does not exist, the domain is dead, or policy forbids it. Remove the address and never retry. A soft bounce is a temporary failure: a 4xx code for a full mailbox, a busy server or greylisting. It may be retried, carefully.
In cold email the distinction is not academic. Our working ceiling is a 2% bounce rate; sustained rates above 5% invite throttling and blocks regardless of how good the rest of the campaign is.
What a bounce actually is
Email delivery is a live conversation between two servers over SMTP. Your server announces the sender and the recipient; the receiving server answers each step with a numeric code. A bounce is the receiving server saying no - either permanently (codes starting with 5) or temporarily (codes starting with 4) - and the text after the code usually says why. That text, the rejection string, is the single most under-read piece of data in outbound. Almost every bounce mystery dissolves once someone actually reads it.
The two families, side by side
| Hard bounce | Soft bounce | |
|---|---|---|
| SMTP class | 5xx - permanent (550, 553, 554 are common) | 4xx - temporary (421, 450, 451, 452) |
| Typical causes | Address does not exist (550 5.1.1), domain has no mail service, sender blocked by policy | Mailbox full, server temporarily unavailable, greylisting, rate limiting |
| Correct response | Suppress the address everywhere, permanently | Allow the sequencer's retry window; suppress if it keeps failing |
| What it says about your list | Data quality problem - or a policy problem wearing a data costume (below) | Usually nothing; persistent soft bounces on one domain hint at reputation trouble |
Greylisting deserves a sentence of its own because it worries people unnecessarily: some receiving servers temporarily refuse the first delivery attempt from an unfamiliar sender on purpose, expecting a legitimate server to retry. Your sequencer's retry handles it; a one-off 450 is not a signal of anything.
The third category: policy blocks dressed as hard bounces
A meaningful share of what gets counted as hard bounces in cold email is not bad data at all. Corporate security gateways such as Mimecast and Proofpoint return a hard 5xx rejection to senders they do not recognise, and in most sequencer reporting that lands in the same bucket as an invalid address. The address is real; the recipient's infrastructure refused you on policy. This is exactly why verified lists still bounce: verification confirms the mailbox exists, and existence was never the question.
The distinction changes what you fix. A genuine invalid-address bounce means your list process needs work. A gateway rejection means your sending posture - domain age, authentication, volume, provider mix - needs work, and no amount of list cleaning will move it. You can see which environment answers for any recipient domain with our mail provider lookup.
Why bounce rate is the metric that compounds
Bounces are not just lost sends; they are evidence about you, logged by the receiving side. Providers read a sender that keeps hitting invalid addresses as a sender that bought a list, and they adjust placement for everything that sender does next. That is why we hold a working ceiling of 2% and treat sustained rates above 5% as an emergency, and why bounce rate should be watched on the sends made since your last change, not on cumulative averages that bury recent behaviour under old data. Where bounce rate sits among the numbers that actually predict revenue is covered in cold email metrics.
What to do about each kind
- Hard bounce, invalid address. Suppress it everywhere, feed the failure back into your list source, and check whether that source's failure rate justifies keeping it.
- Hard bounce, policy string. Do not delete the lead - the address works. Fix the sending side: full authentication, warmed mailboxes, conservative per-mailbox volume, and segment gateway-protected recipients so their behaviour does not distort the rest of the campaign's numbers.
- Soft bounce. Let the retry window run. If the same recipient soft-bounces across the whole window, treat it as hard. If many recipients on one receiving domain soft-bounce at once, the domain is throttling you - reduce volume to it rather than pushing.
- Any bounce spike after a change. Whatever you changed is the prime suspect: a new list segment, a new domain, a volume increase. Diagnose before sending more; capacity spent while bouncing is reputation spent for nothing.
Prevention beats triage
Three habits keep bounce rate under the ceiling before triage is ever needed: verify the list live immediately before sending rather than when it was purchased; treat catch-all domains as their own risk class, because verification cannot confirm those mailboxes; and check your own technical setup with the deliverability checker, because a broken SPF record turns even a clean list into a bounce problem.
Common questions
What is an acceptable bounce rate for cold email?
We operate to a 2% working ceiling and investigate anything above it. Sustained rates above 5% invite throttling and blocking from receiving providers regardless of volume.
Do soft bounces hurt deliverability?
An occasional soft bounce does not. A pattern of them against one receiving domain means you are being throttled there, and continuing to push does start to hurt. Watch the pattern, not the individual event.
Should you ever retry a hard bounce?
No. A 5xx rejection is the receiving server telling you the answer is final. Retrying hard bounces is one of the behaviours that separates bulk spammers from legitimate senders in providers' models - be on the right side of it.
What SMTP code is a hard bounce?
Codes beginning with 5 - most commonly 550 with an enhanced code such as 5.1.1 for an unknown user. Codes beginning with 4 are temporary. The text after the code identifies the specific reason and, in gateway cases, often names the security product that refused you.
Bounces under 2% is an operating discipline, not luck
Live verification before every send, warmed infrastructure and per-segment monitoring - built and run for our clients, paid mostly from the revenue they close.
How we run deliverability Check a domain now