A soft bounce is a delivery failure the receiving server reports as temporary. A hard bounce is one it reports as permanent. Both are the receiving server's answer to an attempted delivery, and both arrive as an SMTP reply code before your ESP ever labels them.
I care about this distinction because bounce data is one of the fastest signals available when placement is falling, and it is routinely read as a list quality problem when it is reporting something else entirely.
The receiving server decides, and it tells you through the reply code. RFC 5321 defines codes beginning with 4 as transient negative completion, meaning the sender should retry later. Codes beginning with 5 are permanent negative completion, meaning the sender should stop retrying this message. Soft maps to the first group, hard to the second.
| Soft bounce | Hard bounce | |
|---|---|---|
| SMTP class | 4yz, transient negative completion | 5yz, permanent negative completion |
| Expected sender behaviour | Retry over a period, then give up | Do not retry this message |
| Typical causes | Mailbox full, server unavailable, rate limiting | Address does not exist, domain does not accept mail, policy rejection |
| Reputation weight | Low in isolation | High when the rate is elevated |
RFC 3463 adds a second, finer code alongside the reply, in the form class.subject.detail. A 5.1.1 is a bad destination mailbox address, which is the classic dead address. A 4.2.2 is a full mailbox. Reading that enhanced code is worth the extra step, because the first digit alone flattens several very different situations into one word.
No, and this is the misreading that costs the most time. A permanent code means the receiving server will not accept this message. It does not mean the mailbox is missing. Policy rejections tied to sender reputation or blocklisting also return permanent codes, and in a bounce report they sit in the same column as genuinely dead addresses.
So a hard bounce rate that climbs suddenly, on a list that has not changed, is usually not a list quality event. It is a reputation event wearing list quality's clothes. The tell is in the response text next to the code, which for a policy rejection names the reason and often carries a URL to the receiver's postmaster page.
A condition at the receiving end that is expected to clear. A full mailbox, a server that is down or overloaded, a message that exceeds a size limit, or rate limiting applied because you sent more than the receiver currently wants to accept from you. Your sending server retries on a schedule until it succeeds or gives up.
Rate limiting is the one worth watching, because it is a soft bounce that is really a reputation signal. A receiver throttling you is making a judgement about your sending, and if throttling grows across sends it usually precedes a harder placement problem. It looks benign in a dashboard that counts soft bounces as noise.
Your ESP is not reporting the SMTP code to you. It is reporting a classification it applied to that code, and the rules behind it vary by platform. Repeated soft bounces to the same address get promoted to hard after a threshold, and that threshold is a product decision rather than anything in a specification.
The practical consequence is that a bounce rate is not comparable across platforms, and a migration can change your reported bounce rate without a single thing changing about your list. When I compare bounce data before and after an ESP move, I compare raw codes where the platform exposes them, not the platform's own soft and hard counts.
Mailbox providers do not publish a bounce rate threshold the way Google publishes a 0.3% spam rate limit, so any single number you see quoted is someone's heuristic rather than a documented line. What matters more than the absolute rate is whether it is stable, and what shape the failures have.
A baseline number would have to come from one measurement taken the same way everywhere, and that measurement does not exist. My own monitoring data is Gmail-side. It records what Gmail rejected at its own edge, which is a different event from what your ESP counted as a bounce against your list. A single headline figure built from both would answer nothing.
A steady low rate on a maintained list is unremarkable. A rate that doubles between two sends is worth diagnosing immediately, whatever the absolute number is, because the change is the signal.
Not on the first occurrence, since the failure is temporary by definition and removing the address discards a valid recipient. Repeated soft bounces across several sends are different. An address that is full or unreachable for weeks is usually abandoned, and abandoned addresses produce no engagement while still counting as sends.
That last part is why they matter beyond the bounce report. Sustained sending to addresses nobody reads is exactly the engagement signal that suppresses placement, which is the third of the three systems I check when mail starts landing in spam. The full order is in the diagnostic method I use.
Hard bounces to nonexistent addresses do, because a high rate signals a list that was not verified or maintained. Isolated soft bounces carry little weight. What providers react to is the pattern, since a sender repeatedly attempting delivery to addresses that never existed looks like a purchased or scraped list.
Most retry across a period of hours to a few days with widening intervals, then convert the address to a permanent failure. The exact window is a platform setting rather than a standard. Worth knowing yours, because it determines how many of your reported hard bounces started life as soft ones.
If it was suppressed after soft bounces and the underlying condition has cleared, yes, and most platforms let you remove an address from suppression manually. For a genuine 5.1.1 there is nothing to recover, since the mailbox does not exist. Re-adding those addresses recreates the problem that suppressed them.
No. Spam rate in Google Postmaster Tools is user-reported spam measured against mail that reached the inbox, and a bounced message never reached anyone. They are separate signals that often move together, because the same list hygiene problem produces both.