Hard bounce vs. soft bounce: what email bounces mean and how to handle them

An email bounce is a delivery failure: the receiving mail server rejected the message and returned it instead of placing it in the inbox. Bounces come in two kinds. A hard bounce is permanent, caused by something that will not change on its own such as an address that does not exist. A soft bounce is temporary, caused by something that usually clears such as a full mailbox or a server that is briefly down.

What is an email bounce?

An email bounce is a message that was rejected by the receiving server and returned to the sender instead of being delivered. A bounce means the email did not reach the inbox, and the server sent back a notice explaining why. That notice is the bounce-back, formally a non-delivery report, and it arrives from a sender like "Mail Delivery Subsystem" or "Mailer-Daemon".

Every bounce carries a status code that classifies the failure, and the first digit is the part that matters most. A code starting with 5 is a permanent failure (a hard bounce), and a code starting with 4 is a temporary one (a soft bounce). That single digit is what separates a problem to fix now from one that often resolves on its own.

Hard bounce vs. soft bounce

The two differ in one thing: whether the failure is permanent. A hard bounce is a permanent rejection, so the same message sent again will fail the same way. The address does not exist, the domain is invalid, or the recipient server has permanently refused the mail. Retrying achieves nothing and sends a bad signal to the receiving server.

A soft bounce is a temporary rejection, so the same message may go through on a later attempt. The mailbox is full, the server is briefly down, or the message was deferred under load. A well-behaved sender retries a soft bounce for a while before treating it as a real failure.

Common causes of each

Most bounces trace back to a short list of causes, and the bounce itself names which one applies. Sorting the cause into hard or soft tells you whether to act now or wait. The split below covers the failures that show up in almost every real bounce.

Hard bounces come from a permanent problem with the address or domain:

• The address does not exist. A typo, or a mailbox that was closed. The recipient server has nowhere to deliver the message and rejects it for good.
• The domain is invalid. The part after the @ has no mail server, often a misspelled domain or one that has lapsed.
• The recipient server blocked the sender permanently. The sending domain or IP is on a blocklist, or the receiver refuses it by policy.

Soft bounces come from a temporary condition that usually clears:

• The mailbox is full. The recipient is over quota and cannot accept new mail until space is freed.
• The server is down or unreachable. The receiving server is offline or overloaded and is deferring mail for now.
• The message is too large. The email and its attachments exceed the recipient server's per-message limit. The attachment size limits by provider are lower than they look.

Why bounces matter: your sender reputation

Bounces are not just failed deliveries; they are a signal mailbox providers use to judge whether a sender is trustworthy. Every send to a dead address tells the receiving server that the sender does not maintain a clean list, and a sender that does not clean its list is the profile of a spammer. The damage is to reputation, and reputation determines whether future mail reaches the inbox at all.

There is a concrete line to stay under. A hard bounce rate above roughly 2% points to a list-quality problem and gets a sender throttled or blocked by the major providers. Complaints are watched even more closely: Gmail's published spam-complaint threshold is 0.3%, and the goal is to stay an order of magnitude below it, at 0.1% or lower.

The harm compounds. Repeatedly hitting bad addresses pushes the bounce rate higher, lowers the sender's reputation score, and makes the next batch of legitimate mail more likely to land in spam, which produces more failures and more complaints. A list that is not kept clean degrades faster the longer it runs. The email deliverability checklist covers the full set of metrics to watch alongside bounce rate.

How to handle bounces

Handling bounces well comes down to treating the two types differently and watching the rate. The rule is simple: drop hard bounces at once, give soft bounces a few tries, and keep the list clean as you go.

• Remove hard bounces immediately. A permanent failure means the address is dead, so resending is pure risk with no upside. Suppress it on the first hard bounce and never send to it again.
• Let soft bounces retry. A temporary failure often clears, so retry over the following hours rather than removing the address. If the soft bounces keep coming over several sends, treat the address as dead and suppress it.
• Monitor your bounce rate. Watch the hard bounce rate against the 2% line and the complaint rate against 0.1%. A rising rate is an early warning that catches a list-quality problem before it turns into a block.
• Keep lists clean. Collect addresses through confirmed opt-in, validate them at signup, and remove addresses that have gone quiet. A clean list is what keeps the bounce rate low in the first place.

How to handle bounces automatically (the better way)

Doing all of that by hand does not scale past a small list, which is what a suppression list is for. A suppression list is a record of addresses that should never be sent to again, and a good platform maintains it automatically so a dead address is filtered out of every future send without anyone tracking it manually.

• Hard bounces are suppressed on the first failure. The address is added to the suppression list the moment it bounces permanently, so the next campaign skips it and the bounce rate never accumulates from re-hitting dead addresses.
• Soft bounces are retried before suppression. A temporary failure is retried over a window, and only an address that keeps failing is moved to the suppression list, so a full mailbox does not cost a real recipient.
• A webhook fires on every bounce. Each event is pushed to the application in real time with the address and reason attached, so the application's own database stays in sync with the suppression list instead of drifting out of date.

FAQ

Bottom line

A bounce is the receiving server returning a message instead of delivering it, and the type tells you what to do. Remove hard bounces immediately, retry soft bounces before giving up, and keep the hard bounce rate under roughly 2% to protect sender reputation. The status code on the bounce says which type it is.

At any real volume this is suppression-list work, and it should be automatic. Lettr suppresses hard bounces on the first failure, retries soft bounces before suppressing them, and reports every bounce through a webhook, so reputation stays protected without manual list cleaning. Create a free account, or read the suppressions docs to see how bounce handling works.