InboxRatio
Check your domain

Glossary term

Hard bounce: the permanent no

What a hard bounce is

A hard bounce is a permanent delivery failure: the receiving server refuses the message and signals that retrying will not help. The address does not exist, the domain does not accept mail, or the recipient's system has permanently rejected you. In SMTP terms the receiver answers with a 5xx reply code, defined in RFC 5321 as permanent negative completion — the conversation is over.

A typical rejection looks like this:

550 5.1.1 <user@example.com>: Recipient address rejected: User unknown

The 550 is the SMTP reply; the 5.1.1 is an enhanced status code from RFC 3463 that pins the reason down (here: bad destination mailbox address). When the failure happens after acceptance — say a relay took the message and then found the mailbox is gone — the sender instead receives a bounce message, a Delivery Status Notification in the RFC 3464 format, from the mail system rather than a live SMTP refusal.

Either way, the meaning is the same: this address is a dead end, and your sending system now knows it.

How a hard bounce differs from a soft bounce

The dividing line is permanence, and the protocol encodes it in the first digit. A 5xx reply says the condition is permanent: do not retry. A 4xx reply — a soft bounce — says the condition is transient: mailbox full, server busy, greylisting in progress, try again later.

The operational consequences diverge completely:

| | Hard bounce | Soft bounce | |---|---|---| | SMTP class | 5xx | 4xx | | Meaning | Permanent failure | Temporary failure | | Correct response | Suppress the address | Retry, then suppress if persistent | | List signal | Address is dead | Address may be fine |

The table understates one messy reality: receivers do not always use the classes honestly. Some return 5xx for policy blocks that are actually reputation-dependent and would clear later; others soft-fail addresses that are never coming back. Mature bounce processing reads the enhanced status code and the human-readable text, not just the class digit.

How hard bounces work

The lifecycle runs through your sending infrastructure:

  1. Your server (or ESP) attempts delivery to the domain's MX host.
  2. The receiver rejects with a 5xx during the SMTP transaction, or accepts and later returns an RFC 3464 non-delivery report to the return-path address.
  3. The sending platform parses the response, classifies it as a hard bounce, and records it against the address.
  4. On any competent platform, the address is automatically added to the suppression list so future campaigns skip it without you doing anything.

Step 4 is where platforms differ and where your attention belongs. Automatic suppression after a single hard bounce is the standard behavior; platforms that merely report bounces and keep sending are transferring the reputation cost to you.

Common hard-bounce causes, roughly in order of what a typical list sees: addresses that never existed (form typos, fake signups), addresses abandoned long enough that the provider deleted them, decommissioned domains, and corporate mailboxes removed when employees leave. B2B lists decay faster than consumer lists for exactly that last reason.

Hard bounces and your deliverability

Mailbox providers read your bounce rate as a census of your list-building. Senders who know their recipients generate almost no unknown-user errors; senders mailing harvested, purchased or ancient lists generate them constantly. A high rate of 5.1.1 failures is therefore one of the loudest signals a receiver has that your acquisition or hygiene is broken, and sustained high bounce rates degrade domain reputation and IP reputation at every major provider.

There is a second-order effect that surprises senders: repeatedly mailing an address after it hard-bounced is treated as worse than the original bounce. Providers reactivate some long-dead addresses as recycled spam traps, so continuing to mail bounced addresses eventually means mailing traps. Bounce suppression is not just politeness — it is trap avoidance.

During warm-up the stakes are higher still. A young sending identity has no accumulated goodwill, so a bounce spike that an established sender might absorb reads as disqualifying evidence about a new one. Cleaning the list before a migration or ramp is cheaper than explaining the spike afterward.

Limitations and failure modes

Ignoring the suppression export during ESP migration. A team moves platforms, imports the subscriber list, and leaves years of accumulated bounce suppressions behind. The first campaign from the new platform re-mails every dead address at once — a bounce spike on a fresh sending relationship, which is the worst possible timing.

Retry logic pointed at 5xx. Misconfigured senders that retry permanent failures hammer receivers with mail they have already refused. Receivers notice; RFC 5321 is explicit that permanent failures must not be retried blindly.

Treating every 5xx as a dead address. Some 5xx responses are reputation or policy blocks — 554 with text about the sending IP, for example — not statements about the mailbox. Suppressing the recipient hides the real problem, which is that the receiver is refusing you. Read the enhanced codes: 5.1.x is about the address; 5.7.x is about policy and authentication.

Counting bounces but never lowering them. A bounce report that is filed rather than acted on is decoration. The rate only falls when intake is confirmed (double opt-in exists for this) and dead addresses leave the list.

Blaming the address for a DNS problem. If your own MX or DNS resolution is broken mid-send, failures can masquerade as recipient errors. Rare, but worth ruling out when a bounce spike hits every domain at once — that pattern indicts the sender, not the list.

Related terms

Soft bounce, suppression list, spam trap, list hygiene, double opt-in, SMTP, MX record, domain reputation.

Frequently asked questions

What hard bounce rate is acceptable? Providers do not publish exact cutoffs, and any precise figure you see quoted is folklore. The direction is clear enough: a well-maintained list generates hard bounces in the low single digits per mille on ongoing sends, with rates above the low single digit percent range drawing filtering attention. Trend matters as much as level — a spike is a signal even from a low base.

Should I ever re-mail a hard-bounced address? As a rule, no. If you have specific evidence the rejection was a temporary policy block misclassified as permanent (the bounce text usually says so), one careful retry after investigation is defensible. Systematic re-mailing of 5.1.1 unknown-user bounces is how senders find recycled spam traps.

Why did a real, active address hard-bounce? Usually a policy rejection rather than a missing mailbox: the receiver refused your message for authentication or reputation reasons and used a 5xx to do it. Check the enhanced status code and text — 5.7.x codes point at DMARC/SPF/DKIM or blocklist trouble on your side.

Do hard bounces hurt reputation even if I suppress them immediately? The bounce itself already happened and counted. But immediate suppression caps the damage at one event per address, which is exactly what providers expect from a legitimate sender. The reputational harm concentrates on senders whose bounce rate never falls because nothing gets suppressed.

What causes hard bounces on a double-opt-in list? Decay. People abandon mailboxes, companies delete accounts, domains lapse. Even a perfectly acquired list sheds addresses continuously, which is why bounce processing is a permanent process rather than a one-time cleanup.

When a bounce message is cryptic, paste its headers into the email header analyzer and read the enhanced status code before deciding — the difference between 5.1.1 and 5.7.1 is the difference between a dead address and a deliverability problem.

Sources