Hard bounces are permanent, soft bounces are temporary — and the distinction decides what you should do about each. Here is how to tell them apart and handle them.
When you send an email that can't be delivered, the receiving mail server returns it to the sender. That returned message is called a bounce. But not all bounces mean the same thing, and treating them the same way will quietly damage your ability to reach the inbox. Some bounces are permanent: the address will never accept mail. Others are temporary: the address is real, but something blocked delivery this one time.
Understanding the difference between a hard bounce and a soft bounce is the foundation of good list hygiene. This guide explains what each one means, what causes them, how email service providers (ESPs) handle them, and how to keep your bounce rate low enough to protect your sending reputation.
A hard bounce is a permanent delivery failure. The address does not exist, the domain is invalid, or the server has flatly refused your mail. Sending to it again will fail every time, so you should remove it from your list immediately.
A soft bounce is a temporary delivery failure. The address is usually valid, but a transient condition — a full mailbox, an oversized message, a server hiccup — stopped delivery for now. ESPs typically retry these for a period before giving up.
| Hard bounce | Soft bounce | |
|---|---|---|
| Cause | Address or domain does not exist, or mail is permanently rejected | Temporary condition: full mailbox, message too large, server down, greylisting |
| Permanence | Permanent — fails every time | Temporary — may succeed on a later attempt |
| SMTP response | 5xx (permanent failure) | 4xx (temporary failure) |
| ESP behavior | No retry; recipient is usually suppressed | Retried over hours or days before being abandoned |
| What to do | Remove the address right away | Keep it, monitor, and remove if it keeps failing |
The technical signal behind this split is the SMTP response code the receiving server returns. A code in the 5xx range means a permanent failure (a hard bounce). A code in the 4xx range means a temporary one (a soft bounce). ESPs read these codes to decide whether to retry and whether to suppress the address.
Hard bounces almost always trace back to an address that was wrong from the start, or one that has since been shut down. The most common causes:
@) was mistyped, fabricated, or deleted. The server replies with "user unknown" or "mailbox does not exist."In every case, the correct response is the same: remove the address and do not mail it again.
Soft bounces involve a real, reachable address that is temporarily unavailable. Typical causes:
Because a soft bounce is temporary, your ESP does not give up after the first failure. It queues the message and retries on a schedule that typically backs off over time — for example after a few minutes, then an hour, then several hours — across a window that often lasts somewhere between a day and several days. If the condition clears within that window (the mailbox is emptied, the server comes back, greylisting passes), the message is delivered and you may never know a soft bounce occurred.
A single soft bounce is not a problem. A persistent one is. If the same address keeps soft bouncing across multiple separate campaigns, the "temporary" problem is no longer temporary — a mailbox that is permanently full or a server that is permanently down behaves, in practice, like a dead address.
Most ESPs apply a threshold: once an address soft bounces a certain number of times in a row (commonly somewhere in the three-to-five range, depending on the provider), they convert it to a hard bounce and suppress it. You should mirror this in your own list management. Set a rule, watch repeat offenders, and retire addresses that never come back. Continuing to hammer an address that always fails wastes sends and signals to mailbox providers that you aren't maintaining your list.
Mailbox providers like Gmail, Outlook, and Yahoo judge senders in part by how cleanly they send. A high hard-bounce rate is one of the clearest signals that you are mailing a list you haven't verified — exactly the pattern they associate with spammers and purchased lists. The result is damage to your sender reputation, which in turn lowers your deliverability: even your messages to valid, engaged recipients start landing in spam or getting blocked.
As a general industry rule of thumb, you want to keep your hard-bounce rate under about 2% of messages sent. Once you climb past that, ESPs may throttle your sending or suspend your account, and receiving servers grow more suspicious of your mail. Because hard bounces come from addresses that were never valid, the rate is almost entirely within your control before you press send.
The most reliable way to keep hard bounces low is to never add a bad address to your list in the first place. That is what email verification does: it checks each address before you send, catching the failures a hard bounce would otherwise expose after the fact.
BounceShift runs each address through an ordered pipeline. It checks syntax and suggests corrections for obvious typos (for example, gmial.com to gmail.com), looks the address up against its reputation network, screens for disposable and role-based addresses, confirms the domain has valid MX records, then probes the mailbox over SMTP using a RCPT TO handshake — without ever sending an actual message. The result is one of several statuses (valid, invalid, catch_all, unknown, and others), each with a sub-status and a 0–100 confidence score. An address that comes back invalid is one that would have hard bounced; removing it now costs you nothing and protects your reputation.
Honesty matters here. When a probe is inconclusive — a catch-all domain, greylisting, or a blocked port — BounceShift reports unknown or catch_all with low confidence rather than guessing valid. A false "valid" is treated as worse than an honest abstention, because a false positive is exactly what turns into a hard bounce later.
You can verify a single address in real time through the API, or upload a CSV of up to 100,000 addresses for batch cleaning. Either way, the goal is the same: turn bounces from a problem you discover after sending into one you prevent before it ever happens. To go further, see how to reduce your bounce rate.
Get 100 free validations to test our service. No credit card required.
Start Free Trial