Bounces: hard, soft, and what to do about them

The difference between a hard and a soft bounce, what a healthy bounce rate looks like, and why suppression is not optional.

Hard and soft

A hard bounce is a permanent failure. The mailbox does not exist, the domain does not accept mail, or the address is malformed. Nothing about retrying changes the outcome, and the address must never be sent to again.

A soft bounce is temporary. The mailbox is full, the server is busy, or the recipient’s provider is throttling you. The address is still valid, so a retry is appropriate.

Receiving servers signal which is which through SMTP response codes: 5xx for permanent, 4xx for temporary. In practice the codes are not always used correctly, so classification also relies on the enhanced status code and the text of the response.

That last row matters. A 5xx that says you were blocked is not a statement about the recipient’s address, and suppressing the recipient would be the wrong response. The problem is your reputation or your content.

Why a bounce rate matters so much

Receivers read a high bounce rate as evidence that you do not know who your recipients are, which is what a purchased list looks like. It is one of the fastest ways to lose inbox placement across every provider at once.

Rules of thumb: under 2% total is healthy for transactional mail, which mostly sends to addresses that just interacted with you. Above 5% you should stop and audit your signup flow before sending more.

What to do about them

1. Suppress hard bounces on the first occurrence. No grace, no retries.
2. Retry soft bounces with backoff, and stop after a handful of attempts across a few days.
3. Escalate repeated soft bounces. A mailbox that has been full for two weeks is functionally dead.
4. Fix the source. Most hard bounces on transactional mail come from typos at signup, so validate addresses at the point of collection rather than discovering them later.
5. Never re-import a suppressed address because a customer asked you to try again. If they can receive mail, they can correct the address.

In Mailverick

Read recipient_status on the event. It answers the question the hard and soft split was really asking, which is what the failure means for the address:

• undeliverable means the address is finished. Remove it from your list.
• at_risk means it failed for a reason that may clear. Keep it, and watch whether it recovers.
• unsubscribed and complained mean the person asked you to stop. Mailverick suppresses them either way.
• No recipient_status at all means the failure was about your mail, your sending domain or the route, and says nothing about the address.

Keeping that mapping current is our job, not yours. Receivers change their wording and their codes constantly and we update the rules behind recipient_status as they do, so you never have to match reason codes yourself or revisit that logic when a provider changes its mind.

The event type and reason are there when you want to know exactly what happened:

• rejected means a server refused the message, naming the mailbox (recipient_unknown, recipient_mailbox_full, recipient_inactive) or your mail and sending domain (spam_detected, policy_violation, relay_access_denied). ip_blocked and server_busy appear here when the retries below ran out: the receiving server refused us.
• deferred means a temporary problem and Mailverick is retrying: greylisted, server_busy, ip_blocked, connection_issue, internal_error or policy_violation. No action needed. Once the retries run out, some end as rejected or dropped still carrying that reason, and the rest end as dropped with abandoned.
• dropped covers two different things, and the reason tells you which. We stopped it: the address is suppressed (recipient_blocked_permanently, recipient_blocked_temporarily, recipient_unsubscribed, recipient_complained), was never sendable (domain_no_mx, domain_typo, domain_invalid, domain_disposable), your sending domain is unverified (tenant_domain_spf_not_verified, tenant_domain_dkim_not_verified, tenant_domain_not_found), or the message itself was refused (virus_detected, attachment_too_large). Or there was no point continuing: connection_issue means we never got an answer from the server after repeated attempts, and abandoned means it was not sent after repeated attempts and was discarded as too old. Neither says anything about the address.

Suppression is automatic. An undeliverable address is suppressed permanently, repeated failures put it in a cooldown, and later attempts come back as dropped rather than being sent. Every reason code is listed in the Email Events documentation.

No dropped event counts against your bounce rate with receivers. The ones we stopped never reached a receiver to be counted by, and the ones we gave up on never got an answer from one.

Common mistakes

Retrying hard bounces. Sending again to an address that returned 5.1.1 is the single clearest signal of a badly managed list.

Keeping no suppression list. If suppression lives only in your sending platform and not in your own database, your next import re-adds every dead address.

Treating deferrals as failures. A deferred message has not failed. Alerting on deferrals produces noise and tempts people into re-sending, which makes throttling worse.

Suppressing on a policy block. 550 5.7.1 means you were blocked. Removing the recipient hides the symptom and leaves the cause.

Validating too late. A typo caught at signup costs nothing. The same typo caught at send time costs a bounce.

Sending to a list you have not used in a year. Addresses decay by roughly a fifth per year through job changes and abandonment.

FAQ

What is a good bounce rate?

Under 2% for transactional mail. Under 1% is normal when addresses come from verified signups.

Can a valid address hard bounce?

Yes, occasionally. Aggressive filtering sometimes returns a permanent code for a policy decision, which is why a 5.7.x reason is treated differently from 5.1.1.

Does a bounce cost me anything besides reputation?

It costs a send. More importantly, a bounce is a message a real person never received. If the address was a typo at signup, someone is waiting on a password reset that will never arrive.

Can I remove an address from suppression?

Only when you have positive evidence the mailbox works again, for example the customer signing in and confirming the address. Re-adding an address on request alone reproduces the bounce.

Do bounces affect my IP or my domain?

Both. Reputation is tracked per domain and per IP, and a bounce rate is one of the inputs on each. See why your emails go to spam.

Last updated: June 2026