Hard Bounce vs Soft Bounce: Reading What the Server Actually Told You

A bounce is not a failure notice. It is a reply from another mail server, written in a format designed to be read by software, telling you precisely what it did and why. Most people delete it. Inside is the single most useful diagnostic in email — and the difference between a list problem, a reputation problem and a problem that will fix itself in ten minutes.

The two categories, properly defined#

A hard bounce is permanent. The address does not exist, the domain does not exist, or the server has decided it will never accept mail from you. Retrying achieves nothing except another hard bounce.

A soft bounce is temporary. The mailbox is full, the server is overloaded, the message was too large, or you are being throttled. The same message sent in an hour may well be delivered.

The distinction matters because they are counted differently by the systems judging you. Hard bounces are read as you do not know who you are writing to — a signal that you are working from a bought, stale or guessed list. Soft bounces are mostly noise. A campaign at 6% soft bounces is fine. The same campaign at 6% hard bounces is a domain-reputation event.

Reading the code#

Every bounce carries a three-digit SMTP code. The first digit is the whole story:

Code starts with	Meaning	Category
2xx	Accepted	Not a bounce
4xx	Temporary failure, try again later	Soft
5xx	Permanent failure, do not try again	Hard

Then there is usually an enhanced status code — three numbers separated by dots, like 5.1.1 — and a human-readable string. That string is where the real information is, because it is written by the receiving administrator.

The ones you will actually see:

Code	Typical text	What it really means	What to do
550 5.1.1	User unknown / No such user	The mailbox does not exist	Suppress permanently
550 5.1.2	Host unknown	The domain has no mail server	Suppress; check for a typo in the domain
550 5.7.1	Access denied / Not permitted	You were blocked — policy, not addressing	Stop the campaign and investigate
550 5.7.26	Unauthenticated / SPF or DKIM failure	Your authentication is missing or broken	Fix DNS before sending anything else
551 / 550 relay	Relay denied	The server does not handle mail for that domain	Suppress
552 5.2.2	Mailbox full	Genuinely full inbox	Retry a few days later, then suppress
450 / 451 4.7.x	Try again later / Greylisted	Deliberate delay for unknown senders	Retry automatically; usually delivers
421 4.7.0	Too many connections, rate limited	You are sending too fast for this receiver	Slow down; this is a warning shot

Two of these deserve particular attention.

Greylisting (450) is not a problem. Many servers reject the first attempt from an unfamiliar sender on purpose, because spam software historically did not retry. A properly configured sending platform retries and gets through. If your tool reports greylisting as a failure and never retries, you are losing genuinely deliverable mail.

5.7.1 is not an addressing problem. The address exists. You were refused. Repeated 5.7.1 responses from one provider mean your domain or IP is on a blocklist, or your authentication is broken. Sending more is actively harmful — it deepens the pattern the receiver is measuring.

The numbers that matter#

There is no single published threshold, because every provider does its own maths. The working bands, based on what actually happens to sending domains:

Hard bounce rate	What happens
Under 2%	Normal. Even a well-verified list has some decay
2–5%	Providers start applying scrutiny; inbox placement slips
5–10%	Meaningful reputation damage; recovery takes weeks
Over 10%	Treated as a list you did not build or check; some platforms suspend the account

Soft bounces do not have equivalent bands because they mostly are not held against you. The exception is the throttling family (421, 4.7.x) — those are a receiving server telling you your volume or pattern is unwelcome, and ignoring that repeatedly turns into a permanent block.

A crucial point about timing: reputation is judged per campaign as well as cumulatively. Sending four hundred messages to an unverified list in one morning produces a concentrated spike, which is read very differently from the same number of bounces spread over a month. This is one of the reasons volume ramps exist at all — see the deliverability guide for how to structure that.

Why bounces happen on a list you thought was clean#

Five causes, in rough order of frequency.

People leave. Business email decays at roughly 20–30% a year in ordinary conditions — job changes, closures, rebrands. A list that was perfect in January is measurably wrong by autumn. This is the single biggest source of bounces on lists that were verified once and then reused.

The address was guessed and never checked. Pattern-based candidates sent blind. Six guesses per person means at least five bounces per person. Nothing else on this list damages a domain as fast.

The domain was retired. The business rebranded, moved, or closed. The website may still resolve while the mail server does not — which is why a live site is not evidence of a live address.

The address was scraped from a page that never had one. Sloppy collection produces image@2x.png and name.domain.com as addresses. Every one is a guaranteed hard bounce, and they cluster, which makes the spike worse.

Catch-all domains that lie. A catch-all accepts mail for every address at the domain, existing or not. It cannot bounce at the SMTP level — so verification cannot prove anything either way. What you get instead is silent discarding, or a bounce arriving hours later as a separate message. That is why a good verifier reports catch-all addresses as risky rather than valid, and what verification can and cannot tell you explains the mechanism.

The rules to actually operate by#

Suppress every hard bounce immediately, permanently, and globally. Not just in that campaign — across every list you own. Sending twice to a known-dead address is the clearest possible signal that nobody is maintaining the list.

Retry soft bounces on a decaying schedule and give up after three or four attempts over 48–72 hours. Most sending platforms do this automatically; the ones that do not will quietly discard mail that would have delivered.

Stop the campaign if hard bounces pass 5% in the first hundred sends. This is the single most valuable operational rule in this article. Send a hundred, wait, look at the responses, and only then release the rest. A bad list caught at a hundred sends costs you nothing. The same list at two thousand costs you the domain.

Treat 5.7.x as an incident, not a bounce. Something about your sending — authentication, reputation, content pattern — is being refused. Fix it before the next send.

Re-verify anything older than about three months. Address decay is continuous, and reusing a six-month-old list without re-checking is the most common way a previously healthy sender suddenly develops a bounce problem.

The bounces that never show up as bounces#

Worth knowing, because they distort every metric you have.

Silent discard. Some providers accept the message with a 250 and then delete it. It counts as delivered in your reporting. Nothing came back because nothing was meant to come back.

Spam folder placement. Delivered, never seen. Indistinguishable from being ignored, which is exactly why people rewrite copy when the actual problem is DNS.

Delayed catch-all rejection. Accepted at the door, rejected internally, and a bounce message arrives hours later — often after the campaign has finished and stopped being watched.

The implication is that "delivered" is a weaker word than it looks, and open and reply rates are more trustworthy indicators of real delivery than the delivery number your platform shows you.

A quick diagnostic#

Bounce rate spiked. In order:

1. Are they 4xx or 5xx? 4xx — wait, it may resolve itself. 5xx — continue.
2. All at one provider, or spread? Concentrated at one means a policy or blocklist issue with that provider. Spread means a list problem.
3. 5.1.1 or 5.7.x? 5.1.1 is bad addresses: the list is stale or guessed. 5.7.x is you: authentication or reputation.
4. When was the list verified? More than three months, that is your answer.
5. Where did the addresses come from? If any part of the list was pattern-generated without verification, that part is the cause, and it should be removed rather than retried.

FAQ#

What is the difference between a hard bounce and a soft bounce?#

A hard bounce is a permanent rejection — the address or domain does not exist, or you are blocked — and should never be retried. A soft bounce is temporary, such as a full mailbox or a throttled connection, and usually delivers on a retry.

What bounce rate is acceptable for cold email?#

Under 2% hard bounces is normal for a verified list. Between 2 and 5% invites scrutiny from providers, and above 5% causes reputation damage that takes weeks to recover from. Soft bounces are largely harmless except for the throttling codes.

Does a bounce hurt my sender reputation?#

Hard bounces do, because they indicate you do not know whether your recipients exist. Soft bounces largely do not, with the exception of repeated rate-limit responses, which are a receiving server asking you to slow down.

Can email verification prevent all bounces?#

No. It removes invalid syntax, dead domains and non-existent mailboxes, which is the large majority. It cannot resolve catch-all domains, and it cannot know that someone leaves the company tomorrow. Verification takes a typical list from a double-digit bounce rate to low single digits, which is the difference that matters.

Should I retry a hard bounce later?#

No. Suppress it permanently and across every list you hold. If the business genuinely comes back later, it will be with a new address that arrives through a fresh collection, not through retrying a dead one.