Hard bounce vs soft bounce: what the difference actually changes

A bounce is any message a receiving server refuses to accept, and the only question that matters

is whether the refusal is permanent or temporary. That is encoded directly in the SMTP reply code:

a reply starting with 5 is a hard bounce (permanent failure), a reply starting with 4 is a

soft bounce (temporary failure, will be retried). Nothing about "severity" or "how bad the

problem looks" changes that — only the leading digit does.

Hard bounce: 5xx

RCPT TO:<notreal@example.com>
550 5.1.1 The email account that you tried to reach does not exist

The server has made a final decision: this message will never be delivered as addressed, and

retrying will not change the outcome. Common causes: the mailbox does not exist, the domain does

not exist, the recipient's policy rejects the sender outright, or the mailbox is permanently

closed.

What to do: remove the address from active sending immediately. Never retry a hard bounce.

Most ESPs and mailbox providers track your hard-bounce rate as a reputation signal, and repeated

sends to dead addresses after a 550 is itself read as poor list hygiene.

Soft bounce: 4xx

RCPT TO:<real@example.com>
452 4.2.2 The email account that you tried to reach is over quota

The server is saying "not right now" — the mailbox is full, the server is overloaded, a rate limit

is in effect, or a greylisting policy wants to see a retry before it trusts the connection. A

properly configured sending system queues the message and retries automatically over a window that

usually runs several days before giving up.

What to do: nothing manual, if your sending platform handles retries correctly. Watch the

pattern: one soft bounce is normal mail-server noise, the same address soft-bouncing on every send

for weeks is not being delivered and should be suppressed even though it was never a hard bounce.

Side by side

How to read your own bounce logs

Most bounce handling goes wrong because the tool or script reading the non-delivery report (NDR)

extracts the wrong line. The leading three-digit code is in the first line of the embedded

Diagnostic-Code or Status header inside the bounce message, not in the subject line, which

providers often write in vague human language regardless of the real code underneath.

1. Open the raw bounce message source, not the rendered summary your mail client shows.
2. Find the line starting `Status:` or `Diagnostic-Code: smtp;` — that carries the real

4.x.x or 5.x.x enhanced code, independent of whatever the subject line says.

1. Check the first digit of the three-digit SMTP code on the same line, not just the enhanced

status code — a 450 paired with 5.1.1 text in a forwarded or translated NDR is rare but

happens, and the three-digit code is the more reliable of the two when they disagree.

1. Log the full code, not a parsed category, so you can re-diagnose later if your

classification logic turns out to be wrong for an edge case.

Why the distinction is worth getting right

Sending platforms and mailbox providers watch your hard-bounce rate as one of the clearest

signals of list quality. A high rate says you are sending to addresses you have not verified

recently, which correlates strongly with spam-like behaviour even when every message is

legitimate. A soft bounce that is retried and eventually delivered costs you nothing; one that is

wrongly treated as a hard bounce and suppressed loses you a real recipient for no reason.

The asymmetry matters in a second, less obvious way: suppressing too aggressively on soft bounces

silently shrinks a list over time with no visible error, while under-suppressing hard bounces

raises your bounce rate in a way providers actively monitor and act on. The failure mode of being

too cautious is invisible; the failure mode of not being cautious enough is measured against you.

What not to do

• Do not suppress an address after a single soft bounce — that is what the retry window is for,

and a greylisting 4xx on the first attempt to a new recipient is completely normal, not a sign of

a dead address.

• Do not keep sending to an address that has hard-bounced, "just in case" the data was wrong. It

almost never is, and the repeated attempts themselves count against your sending reputation

independently of the original bounce.

• Do not rely on a bounce *message's* wording instead of the reply code. Some providers put scary

language in a 4xx deferral ("rejected", "blocked") and mild language in a 550 ("unable to

deliver"); the leading digit is the only reliable signal, and wording-based parsing will

misclassify a meaningful fraction of bounces.

• Do not batch-import a list without verifying it first. The fastest way to accumulate hard

bounces is adding unverified addresses in bulk, and the resulting spike looks identical to a

reputation problem from the receiving side's point of view.

MailPilot tracks delivery outcomes per mailbox as part of its daily reputation scoring, so a rising

hard-bounce rate shows up as a reputation signal before it becomes a deliverability problem, rather

than being buried in a bounce log nobody reads.