How the classification is determined
The receiving server's SMTP response carries the classification. Codes in the 4xx range are temporary failures, and codes in the 5xx range are permanent, per RFC 5321.
Enhanced status codes give the specific reason, defined in RFC 3463. A 5.1.1 indicates the mailbox does not exist, while a 4.2.2 indicates the mailbox is over quota, and those demand opposite responses despite both being failures.
Not every server classifies honestly. Some return a temporary code for what is really a permanent rejection, and a few return 5xx for reputation blocks that would succeed from a different sender, so classification by code alone has edge cases.
Soft bounce
A soft bounce means the message reached the recipient's server and was refused for a condition that may clear. A full mailbox, a server temporarily unavailable, a message exceeding a size limit, or the sender being throttled.
The correct response is a retry schedule with backoff, typically over 24 to 72 hours. A sending system should handle this automatically rather than surfacing each occurrence.
Persistent soft bounces need a threshold. An address that soft bounces on every send for a week is functionally dead regardless of what the code says, and most sending systems suppress after a configured number of consecutive failures.
Reputation blocks frequently arrive as soft bounces, and they are the ones worth reading rather than retrying blindly. A 4xx accompanied by text referencing a rate limit or a blocklist is telling you about your sending rather than about the recipient.
Hard bounce
A hard bounce means permanent failure. The address does not exist, the domain does not resolve, or the receiving server has refused delivery outright.
Suppress the address on receipt and never send to it again. This should be automatic in the sending system rather than a manual list-cleaning task, because a manual process fails exactly when volume is highest.
Retrying hard bounces is actively harmful. Receivers treat repeated delivery attempts to known-invalid addresses as evidence the sender does not maintain its list, which is the behaviour profile of a purchased list.
One category needs separating out. A block bounce returns 5xx because of the sender's reputation rather than the recipient's address, so suppressing those addresses removes valid subscribers to fix a problem that is not theirs. Reading the accompanying text is what distinguishes them.
What each type signals
Soft bounces are mostly noise at low rates and are worth watching as a trend. A rising soft bounce rate across many domains usually indicates throttling, meaning the sender is the common factor.
Hard bounces are a list-quality signal. A hard bounce rate above roughly 2% indicates addresses that were never verified, and address decay of 20 to 30% a year means any list left unmaintained will reach that level eventually.
Both feed the reputation that decides placement. The bounce rate matters less for the messages that bounced than for what it tells receivers about every other message you send.
Both categories feed our monitoring the same way. We track failures, bounces, complaints and auto-pauses, and roll them into a domain reputation score where 1.0 is a healthy domain. A monitored metric still needs an actuator, so sends auto-pause on high bounce, unsubscribe and complaint rates instead of waiting for someone to read a chart.
Where the line is actually drawn in a real system
The textbook split is permanent against temporary, and the useful question is what a system does on the second, third and fourth failure, because that is where the classification stops being obvious.
Our threshold is three. A contact channel is suppressed after three soft bounces, tracked as a running count against the channel rather than judged per send. The exact number matters less than the principle: a soft bounce is temporary, a repeated soft bounce is not, and something has to convert one into the other.
Hard bounces suppress immediately and permanently, and hard suppression outranks everything else. A transactional flag that bypasses marketing unsubscribes still does not bypass a hard suppression from a bounce, a complaint or a manual entry. That ordering is deliberate: the reasons for hard suppression are facts about the address, and no message priority changes them.
Retryable failures are a third category that gets miscounted as bouncing. Transport-level conditions like timeouts, conflicts, rate limiting and server errors are transient by definition; our adapters treat 408, 409, 425, 429 and any 5xx as retryable rather than as delivery failures. Counting those as bounces inflates the rate and hides the real signal.
Account-level conditions are the subtlest case. A tenant returning a sending-paused or account-suspended condition is not telling you anything about the recipient, so treating it as a per-recipient bounce suppresses valid addresses for a problem on the sending side.
The proportions from a real send make the categories concrete: of 8,730 addresses needing suppression in one campaign, 3,708 were hard bounces and 3,904 soft, alongside 1,105 unsubscribes and 13 complaints. A near-even hard-soft split like that points at list age rather than a delivery fault.