Hard Bounce vs Soft Bounce: What to Do with Each

A bounce notice is more useful once you know whether the failure is permanent or temporary. That distinction, usually discussed as hard bounce vs soft bounce, decides whether you remove an address immediately or retry it with caution. This explainer stays on that decision and on the suppression steps that follow, so the same bad row does not return in the next upload.

To cut the number of notices you receive in the first place, follow our guide on lowering bounce rate through verification. After you decide which rows to drop, use the article on removing invalid addresses and the hygiene checklist for email lists.

The difference that matters

A hard bounce is a permanent delivery failure. The receiving system is telling you that trying the same address again, without a change, should not succeed. Typical reasons include an inbox that does not exist, a domain that cannot accept mail, or an account that has been disabled.

A soft bounce is a temporary delivery failure. The receiving system is asking you to wait, slow down, or fix something that might clear: a full inbox, a busy server, a rate limit, or a message that expired in a queue.

Hunter’s bounce-rate guide uses the same split. It treats a hard bounce as a permanent failure (the address or domain does not exist, or the server rejected the message) and says to remove those rows immediately because they will fail every time. It treats a soft bounce as a temporary failure (stuffed inbox, a brief server problem, or rate limiting) that may clear, while warning that a cluster of soft failures can also point to reputation trouble.

Mailbox providers describe the same idea with enhanced status codes. In its guide to nondelivery reports in Exchange Online, Microsoft explains that the diagnostic section includes an enhanced status code defined in RFC 3463, written as values such as 5.x.x or 4.x.x. Microsoft says a 5.x.x code indicates a permanent error and a 4.x.x code indicates a temporary error. That first digit is a strong hint, not a complete answer: some 5-class codes describe conditions that can later change, such as storage that has run out and then been freed. Read the text that arrives with the code.

How to read the notice

Do not stop at the phrase “undeliverable” in your ESP dashboard. Open the bounce or NDR and look for three pieces:

1. The recipient address the server rejected.
2. The numeric SMTP reply (for example 550) and the enhanced status (for example 5.1.1).
3. The human-readable sentence that explains the rejection.

Microsoft’s NDR article describes how Exchange Online notices are built. Newer notices include a short cause, a “how to fix it” section aimed at the sender, and a more technical section for administrators. Older notices split user information from diagnostic information. Either way, the useful facts for suppression are the recipient plus the status code and sentence.

Google documents the replies it appends when mail cannot be delivered to Gmail accounts in its Gmail SMTP errors and codes reference (last updated 26 October 2026). Those entries pair an SMTP reply such as 550 with a status such as 5.1.1 and a recommended next step.

Hard bounces: suppress and do not retry

Once you classify a failure as permanent, take the address out of the live audience and out of any future upload of the same file. Sending again trains mailbox providers that you ignore their answers.

Common hard-bounce signals

From Google’s SMTP reference:

• 550 5.1.1. “The email account that you tried to reach does not exist.” Google tells the sender to double-check the address for typos or unnecessary spaces and points to its article on fixing bounced or rejected emails.
• 553 5.1.2. “We weren’t able to find the recipient domain.” Google asks you to look for spelling mistakes and to make sure you did not add spaces, periods, or other punctuation after the address.
• 550 5.2.1. “The email account that you tried to reach is inactive.” This is still a reason to stop mailing that address until you have a new, confirmed contact.
• 552 5.2.2. “The recipient’s inbox is out of storage space and inactive.” The extra word “inactive” is why this storage error belongs with permanent handling unless you later receive a new, working address.

From Microsoft’s NDR table:

• 5.1.1, “Bad destination mailbox address.” Microsoft lists several causes: the sender typed the address incorrectly, the address does not exist at the destination, the mailbox moved and an Outlook cache was stale, or an invalid legacy domain name is stored for the recipient. The first repair it names is to check the address. If the person is no longer at that mailbox, suppression is the lasting fix.
• 5.1.10, “Recipient not found.” Microsoft links this to an SMTP lookup that could not find the recipient, and it points administrators to a dedicated repair article.
• 5.7.504. Microsoft’s table includes a recipient-rejected, access-denied case that tells you to verify the address and try again only if you have a corrected one.

Other permanent codes describe policy or reputation blocks (for example several 5.7.x values in both references) rather than a missing mailbox. Those still mean “do not keep hammering this path.” Fix authentication or content if the code says so, and keep the individual address suppressed if the text says the recipient itself is invalid.

What to do

• Add the address to your suppression list the same day.
• Delete or archive it from the campaign audience so a reusable segment cannot pick it up again.
• If the code points to a typo you can correct from another reliable source, mail the corrected address only after you check that the new string is valid.
• Do not wait for a second permanent failure to take action. One clear 5.1.1 or 5.1.10 is enough.

Verification helps most on this side of the ledger. An email verifier can flag many nonexistent mailboxes and broken domains before they ever generate a 550 notice.

Soft bounces: retry with a limit

Temporary failures deserve a second chance, not an unlimited one.

Common soft-bounce signals

From Google’s SMTP reference:

• 452 4.2.2. “The recipient’s inbox is out of storage space.” Google treats this as a storage problem and suggests pointing the recipient to Google Drive storage help. You cannot fix the inbox from your side, so a later retry may work if the person frees space.
• 450 4.2.1. Google’s text says the user you want to reach is getting mail faster than it can be accepted, or at a pace that blocks further delivery. Google says to resend later and links to sending and receiving limits.
• 421 4.4.5. “Server busy, try again later.”
• 421 4.7.28. Gmail detected an unusual rate of email and temporarily limited sending. Google’s sender guidelines say this is the typical reply when you exceed quota, and they tell you to pause for at least 10 minutes, identify whether a DKIM, SPF, or IP quota was hit, then resume slowly from a single connection.

From Microsoft’s NDR table:

• 4.4.7, “Message expired.” The message sat in a queue until its expiration time passed, or a protocol timeout occurred. Microsoft says this usually points to an issue on the receiving server and that sending again places the message back in queue.
• 432 4.3.2. The recipient mailbox is accepting mail too quickly and has been throttled so that one mailbox does not crowd others on the same database. Retry later, and slow the rate to that person.
• 5.2.121 and 5.2.122 describe per-hour receive limits for a specific sender or for all senders. Microsoft tells automated mailers to wait and to reduce how many messages they send each hour to that recipient. Even though these codes begin with 5, the recommended action is a delayed retry at a lower rate, which is why you should read the sentence rather than the first digit alone.

What to do

• Retry on a schedule, such as the next day and once more a few days later, unless your ESP already retries automatically.
• If the same address returns temporary failures several times, suppress it. Repeated “try later” answers stop being temporary in practice.
• If many addresses return rate-limit or “server busy” codes during one campaign, slow the whole send. Google’s recovery steps ask you to pause outbound mail until the bounce replies cool down, then increase slowly.
• Watch reputation separately. A wave of soft bounces after a list was cleaned can mean you are sending too fast or that providers already distrust the domain.

Where verification fits

Verification and bounce handling are sequential, not duplicates of each other.

Before the send, a verifier removes many rows that would have become hard bounces: malformed strings, domains that cannot receive mail, and mailboxes that reject the address during a check. On kukudze, every plan on the pricing page runs the same four checks: format, mail routing for the domain (MX), the mailbox answer, and whether the domain accepts all mail. The Free plan gives 100 checks a month. A Valid row on an accept-all domain gets a note, which helps you isolate the domains that are more likely to produce surprise failures later. kukudze does not flag disposable, trap, or role addresses, so screen those by your own rules.

After the send, bounce notices catch what verification cannot: a mailbox that filled up that afternoon, a provider rate limit, or an account closed between the check and the campaign. Feed those permanent failures back into suppression so they never re-enter a bulk file.

Catch-all domains sit in the gap between the two steps. A verifier may return an accept-all or unknown status rather than a clear invalid mark. If you mail those rows and later receive a 5.1.1-style permanent failure, suppress them as hard bounces and tighten the rule you use for catch-all results on the next upload.

A simple decision path

1. Open the notice and copy the status code plus the sentence.
2. If the text says the mailbox or domain does not exist, or that the account is inactive, treat it as a hard bounce and suppress it.
3. If the text says the inbox is full, the server is busy, a quota was hit, or the message expired in queue, treat it as a soft bounce and retry a limited number of times.
4. If the same address keeps returning temporary failures, suppress it.
5. If codes across many recipients point to rate limits or low reputation, slow the campaign and inspect sending practices, not only individual rows.
6. Record the decision in your suppression file so the next list export cannot undo it.

FAQ

How fast should I suppress a hard bounce?

As soon as you have a clear permanent failure for that address. Waiting for another campaign only adds more notices and can lower how providers view your domain. Google’s sender guidelines also tell list owners to drop people from the list after repeated bounce notices, which is a minimum bar rather than a reason to delay the first hard bounce.

Can a code that starts with 5 ever be worth retrying?

Sometimes the accompanying sentence describes a limit or a policy you can change, such as Microsoft’s per-hour receive caps (5.2.121 and 5.2.122) or a message-size rejection. In those cases a later send, after you change rate or content, can succeed. When the sentence says the mailbox does not exist, do not retry.

What if an address was valid yesterday and hard-bounced today?

That can happen. Mailboxes close, companies retire domains, and storage can fill. Hunter’s Email Verifier page notes that a passing mark describes the inbox when it was tested. Suppress the hard bounce, and treat the event as a reminder to verify shortly before large sends rather than relying on an old export.

Should one soft bounce take someone off my list?

Usually not. Give the temporary condition a chance to clear, especially for a full inbox or a brief outage. Set a small retry limit so a quietly abandoned mailbox does not bounce forever under a “temporary” label.

Do I still need verification if my ESP already tags hard and soft bounces?

Yes, if you want fewer of those tags in the first place. ESPs classify the notices they receive. A verifier works earlier, on the list, so many permanent failures never generate a notice. Use both: verify before you send, then let bounce classification tidy whatever remains.

Wrapping up

Hard bounces ask you to remove an address. Soft bounces ask you to wait, then decide whether the problem has become permanent. Read the code and the sentence, suppress what will never deliver, retry temporary failures only a few times, and keep feeding the results back into your list. To prevent the next round of permanent failures, check the audience in the kukudze verifier ahead of the send.