Hard Bounce vs Soft Bounce: A Sender's Field Guide

Every sender has heard that bounces hurt deliverability. Far fewer can tell you exactly when a 4xx response should be treated as a 5xx, what their MTA should do on the eighth retry, or which bounce categories actually cost reputation versus which are operational noise. This is what we have learned running the inbound side of those bounces for several years.

Defining the terms properly

A bounce is just an SMTP failure: the receiving server told your sending server that it could not, or would not, accept the message. SMTP itself splits failures into two broad classes by the first digit of the response code:

• 5xx (permanent failure) — a hard bounce. The address is wrong, the domain is gone, the recipient has blocked you, or the message hits a hard policy. Retrying the same payload will always fail.
• 4xx (temporary failure) — a soft bounce. Mailbox full, server overloaded, greylisting, throttling. Retrying after a delay is the right move.

Most MTAs go further: a 4xx response keeps the message in the queue and triggers a retry curve (commonly every 15 minutes for the first hour, then exponentially) up to a final timeout of three to seven days. Only after the retries are exhausted does a 4xx become a real non-delivery from the sender's point of view.

Common hard-bounce reasons

• 550 5.1.1 User unknown / mailbox not found — the address simply does not exist on the receiving server.
• 550 5.1.2 Domain not found — no MX or A record at all.
• 550 5.7.1 Relay denied — you are not permitted to relay through this server.
• 550 5.7.x Blocked / IP listed — the receiver has blocked your IP or domain.
• 550 5.7.26 Authentication failure — an enforced DMARC policy rejected unaligned mail.
• 550 5.2.1 Mailbox disabled — the account exists but is suspended.

Common soft-bounce reasons

• 421 4.7.0 Try again later — rate limiting. Back off.
• 451 4.7.1 Greylisted — the receiver wants you to retry to prove you are a real MTA.
• 452 4.2.2 Mailbox full — recipient over quota. Often graduates to a hard bounce after several days.
• 421 4.4.5 Server too busy — the receiver is overloaded.
• 421 4.7.0 IP temporarily blocked — usually a reputation warning. Treat it as a leading indicator, not a temporary inconvenience.

The grey area: soft bounces that are really hard

This is where many senders get into trouble. A 452 mailbox-full that has returned the same code for two weeks is a dead address in everything but name. A 421 IP-blocked from the same receiver on every send is a reputation problem you should treat as catastrophic. A well-behaved MTA does the following:

• If a single recipient returns 4xx repeatedly for more than five days, suppress the address.
• If a 4.7.x reason recurs against many recipients on the same receiver, throttle the entire pool toward that receiver and investigate.
• Never retry blindly — a server returning 421 to every connection will not magically accept you on the eighth attempt.

Why bounce rate is a reputation signal

Mailbox providers weight bounce rate heavily because it correlates strongly with the two behaviours they hate most: spammers spraying random addresses and senders mailing dirty (purchased or stale) lists. Production benchmarks we observe across customer traffic:

• Below 2% hard bounce rate — healthy. Natural list churn alone produces 1 to 2% over a year.
• 2 to 5% — warning. Probably mailing a list that has not been cleaned in a year or more.
• 5 to 10% — bad. Major mailbox providers will throttle you, and ESPs may suspend the account.
• Over 10% — expect outright blocks, sometimes from a single send.

Soft-bounce rate is less meaningful in isolation, but a sudden spike (say, jumping from 1% to 8% on a single campaign) is a strong indicator of a reputation issue with one or more receivers.

What a well-behaved system actually does

The flow we recommend, and the one BounceZero implements internally:

1. The MTA records the SMTP response code and full reason string verbatim for every send.
2. Hard bounces (5xx) go straight to a global suppression list and the address is never sent to from any campaign without explicit re-confirmation.
3. Soft bounces (4xx) trigger normal retry logic; if the address has bounced soft on every attempt for more than five days, it is promoted to suppression.
4. Bounces are categorised: bad mailbox, bad domain, blocked, full, throttled. Each category drives its own suppression and reporting policy.
5. Per-domain bounce rate is computed continuously. A spike triggers an automatic throttle and an alert to the on-call engineer.
6. Recipient feedback loops (Microsoft JMRP, Yahoo CFL, AOL) are ingested and complaints are treated like hard bounces.

Cleaning a list before you send

If you bought a list, inherited an old export, or simply have not mailed your subscribers in a year, do not blast it — you will burn your reputation in a single campaign. The safe path:

1. Run the list through an email validation service (BounceZero, Kickbox, NeverBounce). The service performs SMTP probes and DNS checks to flag dead addresses without actually sending.
2. Remove anything categorised as invalid, disposable, spamtrap or complainer.
3. For addresses tagged unknown, throttle initial sends — these are the most likely to bounce.
4. Send a low-volume re-engagement campaign first. Mail the engaged subset (recent opens and clicks) before the long-tail unengaged.

SMTP response code reference

Every SMTP response is a three-digit code, optionally followed by an enhanced status code (RFC 3463) of the form X.Y.Z:

• X = 2 — success (e.g. 250 2.0.0 OK).
• X = 4 — temporary failure.
• X = 5 — permanent failure.
• Y = 0 — other / undefined.
• Y = 1 — addressing status (bad address).
• Y = 2 — mailbox status (over quota, disabled).
• Y = 3 — mail system status (server error).
• Y = 4 — network and routing.
• Y = 5 — mail delivery protocol.
• Y = 7 — security or policy (auth failure, blocklist).

The most operationally useful codes are 5.1.1 (no such user), 5.7.x (security/policy), 4.2.2 (over quota) and 4.7.x (rate or reputation). Logging the full code-and-reason for every bounce is the single most useful thing you can do for deliverability debugging.

Bottom line

Hard bounces are an unavoidable fact of life — addresses go stale, employees leave companies, free-mail accounts get abandoned. The goal is not zero bounces but a rate low enough that mailbox providers see you as a competent operator. That means validating before you send, suppressing on first hard bounce, treating persistent soft bounces as hard, and watching per-domain trends rather than aggregate numbers.