Bounce Management: Hard Bounces, Soft Bounces, and How to Handle Both

Bounces Are Feedback, Not Just Errors

When an email can't be delivered, the receiving server sends back a bounce message — a response code and a short explanation of what went wrong. Most senders treat bounces as background noise until they accumulate into a problem. That's backwards. Bounce data is some of the most actionable feedback your sending infrastructure produces, and handling it correctly is one of the clearest signals of a well-run email operation.

Bounce management is the practice of categorising delivery failures, acting on them appropriately, and feeding the results back into your sending process. Get it right and your sender reputation stays clean. Get it wrong and you eventually find yourself on a blocklist, wondering what changed.

Hard Bounces vs Soft Bounces

Hard Bounces

A hard bounce is a permanent delivery failure. The address doesn't exist, the domain has no mail server, or the receiving server has issued a permanent rejection. The most common SMTP codes for hard bounces are 550, 551, and 553.

Real-world examples:

• 550 5.1.1 The email account that you tried to reach does not exist
• 550 5.1.2 Bad destination mailbox address
• 553 5.1.3 Invalid address format

Hard bounced addresses must be removed from your list immediately and permanently. Continuing to send to them signals to inbox providers that you're not maintaining your list, which damages your sender reputation steadily over time. A hard bounce rate above 2% is enough to trigger aggressive filtering at most major providers.

Soft Bounces

A soft bounce is a temporary failure. The address is valid, but delivery failed for a transient reason — the mailbox was full, the receiving server was temporarily unavailable, or the connection timed out. Common codes include 421, 450, and 452.

Examples:

• 452 4.2.2 Mailbox full
• 421 4.3.2 Service temporarily unavailable
• 450 4.1.1 Requested action not taken: mailbox unavailable

Soft bounces typically warrant automatic retry — most SMTP servers retry soft-bounced messages on a schedule for up to 72 hours. But if the same address soft-bounces consistently over multiple sends across several weeks, treat it as permanently unreachable and suppress it.

A Third Category Worth Knowing: Blocks

Some delivery failures look like bounces but are actually blocks — the receiving server rejected your message not because the address is invalid, but because of something about your sending reputation. Codes like 554 5.7.1 often indicate your IP or domain is on a blocklist or that the receiving server has a policy-level rejection in place.

Blocks require a different response than bounces. They're a reputation problem, not a list problem. If you see widespread blocks across campaigns, check your IP and domain against major blocklists before touching your list. The blocklist removal guide covers the remediation steps.

Setting Bounce Rate Thresholds

Industry standards place acceptable hard bounce rates at under 2% per campaign. Gmail and Yahoo track bounce rates at the domain level over rolling windows — not just per campaign — which means one bad send can affect your reputation for weeks afterward.

Practical thresholds to track:

• Under 0.5%: Healthy. Continue routine suppression practices.
• 0.5–1.5%: Elevated. Review list acquisition sources and validation practices.
• 1.5–2%: Warning range. Pause sends to the bouncing segments and investigate aggressively.
• Over 2%: Serious. Stop large-volume sends. Conduct a full list audit before resuming.

Building a Suppression Process

Every sending operation needs a suppression list — a record of addresses that should never receive email again, fed automatically from bounce data. A functional suppression workflow looks like this:

1. Your SMTP relay receives a delivery status notification (DSN) for each failed message.
2. Your system parses the SMTP response code and classifies it as hard bounce, soft bounce, or block.
3. Hard bounces are written to the suppression list immediately, with no retry.
4. Soft bounces are tracked per address. After three consecutive soft bounces on the same address, it moves to suppression.
5. Before each send, all recipient addresses are checked against the suppression list and matches are excluded.

Most email platforms automate steps 1 through 4. If you're running your own infrastructure through an SMTP relay, you'll need to build or configure this pipeline explicitly — it doesn't happen by default.

Email Validation Before the First Send

The most effective bounce management is prevention. Running a list through an email validation service before sending catches the obvious problems: invalid syntax, non-existent domains, known disposable addresses, and known hard-bounced addresses from shared suppression databases.

Validation won't eliminate bounces entirely — mailbox-level existence checks are limited by what servers will reveal without an actual send attempt — but it removes the low-hanging fruit that makes bounce rates spike on first contact. For any list that hasn't been mailed in more than six months, validation before re-engagement is non-negotiable.

Monitoring Bounce Rates by Segment

Aggregate bounce rates hide problems. A single low-quality list segment can inflate your overall bounce rate while masking healthy performance elsewhere. Track bounce rates broken down by:

• List acquisition source (organic opt-in vs imported vs purchased)
• Age of subscription (recent subscribers vs older records)
• Engagement level (active openers vs long-dormant contacts)

A list of highly engaged recent subscribers should show near-zero bounces. If an older segment suddenly spikes, that's a signal addresses have aged out of use — not a problem with your sending infrastructure.

For the broader picture of how delivery performance connects to inbox placement, the post on how subscriber engagement affects deliverability covers the full relationship between list quality and sender reputation. And if you're managing bounces at scale on a dedicated sending IP, the IP-level bounce management considerations are meaningfully different from shared environments.

Bounces are unavoidable. What separates good senders from bad ones is how quickly they act on the data and how rigorously they prevent the same addresses from being mailed again.