A hard bounce is a permanent delivery failure: the receiving server has definitively rejected your message and will reject it again if you resend, so the address must be suppressed at once. A soft bounce is a temporary failure that often clears on its own, so it is safe to retry for a limited window. The first digit of the SMTP response tells you which one you are looking at: a 5xx code is a hard bounce, and a 4xx code is a soft bounce.
Reads public DNS only. Nothing is stored unless you save the domain to an account.
Getting this distinction right is not cosmetic. Mailbox providers watch how often your mail bounces as a direct signal of list quality, and repeatedly hitting dead addresses is one of the fastest ways to damage your standing. This guide defines each bounce type, shows the codes you will actually see in logs, explains what causes them, and sets out the thresholds that keep you out of trouble.
What is a bounce?
When a receiving mail server cannot accept a message, it returns a non-delivery response during or after the SMTP conversation. That response carries two numbers: a legacy three-digit reply code (such as 550 or 421) and, in most modern systems, an enhanced status code defined by RFC 3463 (such as 5.1.1 or 4.2.2). The enhanced code is the precise one to key your logic on.
The enhanced status code has three parts, class.subject.detail:
- Class (the first digit):
2success,4transient failure,5permanent failure. - Subject (the second digit):
1addressing,2mailbox,3mail system,4network or routing,5mail delivery protocol,6message content,7security or policy. - Detail (the third digit): the exact reason within that subject.
So 5.1.1 reads as permanent (5), addressing problem (1), mailbox address does not exist (1). Once you can decompose a code this way, classifying a bounce becomes mechanical. For a fuller reference on individual replies, see our guide to SMTP error codes.
Hard bounce: permanent failure
A hard bounce means the destination will never accept this message. Retrying wastes sending resources and, worse, tells the provider you are not cleaning your list. The correct response is to add the address to a suppression list immediately and never mail it again unless the recipient re-subscribes.
Common hard-bounce codes:
| Code | Reply | Meaning |
|---|---|---|
5.1.1 | 550 5.1.1 User unknown | The mailbox does not exist on the receiving server. |
5.1.10 | 550 5.1.10 Recipient address rejected | Address does not resolve or the domain has no valid recipient. |
5.1.2 | 550 5.1.2 Bad destination system | The recipient domain itself is invalid or has no mail service. |
5.2.1 | 550 5.2.1 Mailbox disabled | The account exists but has been deactivated. |
5.7.1 | 550 5.7.1 Message rejected by policy | The recipient server refused the mail on policy grounds. |
Typical causes of hard bounces:
- The address was mistyped at signup (
jsmithh@instead ofjsmith@). - The mailbox or the whole domain was deleted.
- The address was never real, for example a fake entry or a role account that was removed.
- A policy or authentication rejection, such as a
5.7.xblock. These are not addressing problems, so before suppressing, confirm the failure is not caused by your own broken SPF, DKIM, or DMARC. A550 5.7.26unauthenticated-sender rejection means every recipient bounces, not just one, and the fix is your authentication rather than your list.
Because a genuine 5.1.x invalid recipient will never recover, suppression must be automatic and permanent. Providers treat a rising hard-bounce rate as evidence that you are mailing purchased or stale data, which is exactly the behavior spam filters are built to punish.
Soft bounce: temporary failure
A soft bounce means the server could not accept the message right now but might later. The message stays in your queue and your mail transfer agent retries on a back-off schedule, usually for 24 to 72 hours, before giving up and generating a final failure.
Common soft-bounce codes:
| Code | Reply | Meaning |
|---|---|---|
4.2.2 | 452 4.2.2 Mailbox full | The recipient is over quota; may clear when they delete mail. |
4.2.1 | 450 4.2.1 Mailbox temporarily disabled | Mailbox is briefly unavailable. |
4.3.2 | 421 4.3.2 System not accepting messages | The server is overloaded or in a maintenance window. |
4.4.1 | 421 4.4.1 Connection timed out | The receiving host did not respond in time. |
4.7.1 | 451 4.7.1 Greylisted, try again later | Deliberate temporary defer to test legitimate senders. |
The greylisting case (4.7.1) is worth calling out because it is by design, not a fault. A correctly configured sender that retries will be accepted on the second attempt. If your infrastructure does not retry cleanly, greylisting turns into lost mail. See what greylisting is for how to configure around it.
Handle soft bounces with patience but not indefinitely. If the same address soft-bounces on every send for several consecutive campaigns, treat it as effectively dead and suppress it. Note the split at the subject level: 4.2.2 (mailbox full, transient) and 5.2.2 (mailbox full, permanent) describe the same condition but demand opposite handling, which is why keying on the enhanced code beats guessing from the reply text.
Why hard bounces must be suppressed immediately
Mailbox providers score two things when they see bounces: the percentage of your mail that fails, and the raw volume of bad attempts you push into their systems. A high hard-bounce percentage signals a dirty list. High volume signals that you are pumping that dirty list at scale. Both feed reputation systems that decide whether your future mail lands in the inbox, the spam folder, or nowhere.
Continuing to send to an address that returned 5.1.1 produces no upside and real downside:
- It inflates your bounce rate, a metric providers read directly.
- It risks hitting recycled spam traps, because abandoned addresses are exactly what providers convert into traps.
- It can trigger domain-wide throttling, where new mail from your domain is filtered regardless of content or recipient engagement.
Suppression is the mechanism that stops all three. An address that hard-bounces should be flagged so no future campaign, transactional message, or automation can send to it again. This is not optional list maintenance; it is the primary control that protects your sender reputation.
Bounce-rate thresholds to hold
The widely accepted benchmark for a healthy program is a total bounce rate under 2 percent. Cross that line and providers start reading your list as low quality. Gmail is explicit that persistently high bounce volumes lead to rate limiting and eventual filtering.
| Total bounce rate | Interpretation |
|---|---|
| Under 2% | Healthy. Normal for a well-maintained list. |
| 2% to 5% | Warning. List quality or acquisition source needs attention. |
| Over 5% | Critical. Deliverability damage is likely and may already be underway. |
Within that budget, hard bounces deserve the tighter limit. Aim to keep the hard-bounce rate under about 1 percent, and for cold or B2B outreach many senders target under 0.5 percent. A hard-bounce spike is more damaging than an equivalent soft-bounce spike because it points at addresses that were never valid.
Bounce rate is calculated as bounced messages divided by messages sent, times 100. Track hard and soft rates separately so a temporary provider outage inflating soft bounces does not mask a genuine list-quality problem hiding in the hard-bounce number.
List hygiene and its reputation impact
Bounces are a symptom; list hygiene is the cure. Every one of the following practices lowers your bounce rate and, with it, the reputation risk that sits underneath deliverability:
- Validate at the point of entry. Use double opt-in so a real person confirms the address before it ever receives a campaign. This alone eliminates most typo and fake-address hard bounces.
- Suppress hard bounces automatically. Wire your
5.x.xinvalid-recipient results straight into a suppression list with no manual step. - Age out chronic soft bounces. After a set number of consecutive soft failures, retire the address.
- Re-engage or remove inactive contacts. Long-dormant addresses are the seedbed for recycled spam traps.
- Confirm the failure is the recipient, not you. A wave of policy bounces usually means broken authentication. Run a deliverability check and verify you are not on a blocklist before you blame the list.
Clean lists compound. Lower bounce rates lead to better inbox placement, which lifts engagement, which further improves reputation. Dirty lists compound the other way. If your bounce rate is climbing and mail is landing in spam, work through the email deliverability best practices checklist to find the source before it costs you domain reputation you cannot quickly rebuild.
Frequently asked questions
What is the difference between a hard bounce and a soft bounce?
A hard bounce is a permanent delivery failure returned with a 5xx SMTP code, such as 550 5.1.1 User unknown, and the address should be suppressed immediately. A soft bounce is a temporary failure returned with a 4xx code, such as 452 4.2.2 Mailbox full, and it is safe to retry for a day or two before giving up.
What bounce rate is considered acceptable?
Keep your total bounce rate under 2 percent. Between 2 and 5 percent is a warning sign of list-quality problems, and above 5 percent puts your deliverability and sender reputation at real risk. Hold hard bounces to under roughly 1 percent, and under 0.5 percent for cold outreach.
Do soft bounces hurt my sender reputation?
A modest, transient soft-bounce rate is normal and does not meaningfully harm reputation, because it usually reflects full mailboxes or brief server outages rather than bad data. It becomes a problem when the same addresses soft-bounce campaign after campaign, at which point they should be suppressed like hard bounces.
Can broken email authentication cause bounces?
Yes. Policy rejections such as 550 5.7.1 or 550 5.7.26 are bounces caused by failed SPF, DKIM, or DMARC rather than by the recipient. These affect every recipient at once, so fix the authentication instead of suppressing addresses.
Bounce handling and email authentication are two halves of the same reputation problem: a broken SPF, DKIM, or DMARC setup can generate policy bounces that look like a dirty list. Run a free scan with SPFWise to confirm your authentication is aligned so that the only bounces you have to chase are the ones that genuinely belong on a suppression list.