Hard Bounce vs Soft Bounce: What Every Sender Must Know

Every sender knows that bounces hurt deliverability. Far fewer know exactly what counts as a hard bounce versus a soft bounce, when each becomes a problem, and what their MTA should actually do with each type. Here is a working postmaster's perspective.

Definitions, properly

A bounce is an SMTP failure: the receiving server told your sending server that it could not or would not accept the message. The SMTP protocol distinguishes two broad categories using the response code:

• 5xx (permanent failure) — a "hard bounce." The address is bad, the domain doesn't exist, the recipient blocked you, or the message violates a hard policy. Re-trying the same message will always fail.
• 4xx (temporary failure) — a "soft bounce." Mailbox full, server busy, greylisted, throttled. Re-trying later is the correct action.

Most MTAs translate this further: a 4xx response causes the message to stay in the queue and be retried with a backoff (typically every 15 minutes for the first hour, then exponentially), with a final timeout after 3 to 7 days. Only after exhausting retries does a 4xx become an actual non-delivery from the sender's perspective.

Common hard-bounce reasons

• 550 5.1.1 User unknown / mailbox not found — the address simply doesn't exist on the destination server.
• 550 5.1.2 Domain not found — the domain has no MX or A record.
• 550 5.7.1 Relay denied — you are not authorised to relay through this server (rarely seen except for outbound).
• 550 5.7.x Blocked / IP blacklisted — the receiver has blocked your IP or domain.
• 550 5.7.26 Authentication failure — your DMARC policy is being enforced and the message failed alignment.
• 550 5.2.1 Mailbox disabled — account exists but is suspended.

Common soft-bounce reasons

• 421 4.7.0 Try again later — rate limiting. Back off and retry.
• 451 4.7.1 Greylisted — the receiver wants you to retry after a few minutes to prove you're a real MTA.
• 452 4.2.2 Mailbox full — recipient is over quota. Often becomes 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 issue. Treat as a warning.

The grey area: soft bounces that should be treated as hard

This is where a lot of senders go wrong. A 452 mailbox-full that has been returning the same code for fourteen days is functionally a dead address. A 421 IP-blocked from the same receiver every single send is a reputation problem you should treat as catastrophic. Good MTA behaviour:

• If the same address returns 4xx repeatedly for more than 5 days, suppress it.
• If a soft-bounce reason indicates a reputation issue (4.7.x against many recipients), throttle that whole pool and investigate.
• Never blindly retry — a server returning 421 to every connection is not going to magically accept you on the eighth attempt.

Why bounce rates matter for reputation

Mailbox providers use bounce rate as a strong negative signal because high bounce rates correlate strongly with two bad behaviours: spammers spraying random addresses, and senders mailing to dirty (purchased or stale) lists. A few benchmarks from production traffic:

• Under 2% hard bounce rate — healthy. Normal list churn alone produces 1–2% over time.
• 2–5% — warning zone. Probably mailing to a list that hasn't been cleaned in a year or two.
• 5–10% — bad. Major mailbox providers will throttle you. ESPs may suspend the account.
• Over 10% — you will be blocked, often within a single send.

Soft-bounce rate matters less in isolation but a sudden spike (say, jumping from 1% to 8% across one campaign) is a strong sign that you have a reputation problem with one or more receivers.

How a well-behaved system handles bounces

The flow we recommend (and the one BounceZero implements internally):

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

Cleaning a list before you send

If you bought a list, inherited an old export, or just haven't sent to 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, etc.). The service does 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 categorised as unknown, throttle your initial sends — these are the ones 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 useful pieces in practice 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 debugging deliverability.

The bottom line

Hard bounces are a fact of life — addresses go stale, employees leave companies, free-mail accounts get abandoned. The goal is not zero bounces; it's keeping the rate low enough that mailbox providers see you as a good 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 global numbers.