What Is a Bounced Email? Hard Bounce vs. Soft Bounce
A bounced email is one that couldn't be delivered — a hard bounce means never (the mailbox doesn't exist), a soft bounce means not right now (the mailbox is full, or the server is temporarily down).
- Category
- Delivery failure
- Deliverability risk
- Hard: Critical · Soft: Low–Medium
- Recommended action
- Hard: remove immediately · Soft: retry, then remove
- How a verifier classifies it
- hard_bounce / soft_bounce
On this page
Bounces are the most expensive way to learn something you could have checked for free. The message has already been sent, the mailbox provider has already recorded the failure against your sending domain, and the reputation damage lands whether or not you act on it afterwards. This page covers what a bounce actually is, how hard and soft bounces differ, what the common SMTP codes mean, and how to get your bounce rate down and keep it there.
What this page covers
- What happens technically when an email bounces
- Hard bounce vs soft bounce, and why they need opposite handling
- What SMTP codes like 550, 421 and 452 are telling you
- Why bounce rate is a sender-reputation metric, not just a delivery stat
- A six-step process for reducing your bounce rate
What is a bounced email?
A bounce is a delivery failure reported back to you. Your sending server hands the message to the recipient's mail server, that server refuses it, and a non-delivery report is returned explaining why. Depending on where the failure happens, the refusal can come during the initial SMTP conversation or afterwards, once the server has accepted the message and then found it has nowhere to put it.
Every bounce carries an SMTP status code, and that code is what classifies it. Codes beginning with 5 are permanent failures — hard bounces. Codes beginning with 4 are temporary — soft bounces. The distinction is not cosmetic: the two require opposite responses, and treating them the same is one of the most common causes of avoidable reputation damage.
Hard bounce vs soft bounce
| Hard bounce | Soft bounce | |
|---|---|---|
| SMTP code range | 5xx — permanent failure | 4xx — temporary failure |
| Typical cause | Mailbox does not exist, domain has no mail servers, sender blocked | Mailbox full, message too large, server down, greylisting |
| Will retrying help? | No, and it compounds the damage | Often yes, within 24–72 hours |
| Correct response | Suppress the address permanently, immediately | Retry a limited number of times, then suppress |
| Reputation impact | High — signals you are mailing addresses you never verified | Low in isolation, meaningful if persistent |
| Preventable before sending? | Yes, through verification | No — depends on conditions at delivery |
Common SMTP bounce codes and what they mean
Bounce messages are not written for humans, but the code at the start is consistent enough to act on without reading the rest.
| Code | Meaning | Type | What to do |
|---|---|---|---|
| 550 | Mailbox unavailable, or message rejected on policy grounds | Hard | Suppress immediately |
| 551 / 553 | User not local, or mailbox name not allowed | Hard | Suppress immediately |
| 552 | Mailbox has exceeded its storage allocation | Soft | Retry, then suppress if persistent |
| 554 | Transaction failed — often a blocklist or content rejection | Hard | Investigate reputation, do not retry |
| 421 | Service not available, closing transmission channel | Soft | Retry later |
| 450 | Mailbox unavailable, temporarily — often greylisting | Soft | Retry later |
| 451 | Local error in processing on the receiving server | Soft | Retry later |
| 452 | Insufficient system storage on the receiving server | Soft | Retry later |
Why bounce rate is a sender-reputation metric
Mailbox providers cannot see your list. What they can see is how accurate it is, and bounce rate is the clearest available proxy. A sender whose mail consistently reaches real mailboxes is behaving like someone with permission; a sender producing a stream of hard bounces is behaving like someone who bought a list.
2%
Bounce rate ceiling
The widely used industry guideline. Crossing it consistently is what triggers throttling and filtering.
5xx
Codes that must never be retried
Permanent failures. Each repeat attempt to a hard-bounced address compounds reputation damage.
100%
Of the send is judged
Reputation attaches to your domain and IP, so bounces from a bad segment affect every other recipient too.
- Delivery throttling — the provider accepts your mail more slowly, or defers it entirely.
- Inbox placement drops, so mail that used to arrive starts landing in spam.
- Outright blocking from a provider, which affects every recipient on that domain.
- Sending platforms may suspend an account whose bounce rate stays elevated.
What actually causes bounces
The mailbox does not exist
Typos, abandoned accounts, and people who have left the company. The single largest source of hard bounces, and entirely preventable before sending.
The mailbox is full
A classic soft bounce. Often a dormant personal account that nobody clears — if it recurs across several sends, treat it as dead.
The receiving server had a problem
Temporary outages, maintenance windows, or greylisting, where a server deliberately defers a first-time sender to see whether they retry properly.
You were blocked
A reputation or blocklist rejection, often returned as 554 or 550 with policy wording. This is a deliverability problem, not a list problem.
The message was too large
Heavy attachments or bloated HTML exceeding the recipient server limit. Fixable on your side by trimming the message.
The domain no longer exists
A company folded and let the domain lapse, so there are no MX records to deliver to. Common in ageing B2B lists.
How to reduce your bounce rate
- 1
Verify the list before you send
A DNS/MX lookup plus an SMTP mailbox check removes the addresses that would otherwise become hard bounces. This is the single highest-impact step.
- 2
Validate at the point of capture
Checking the address on your signup form stops typos and disposable domains entering the list at all, rather than cleaning them out later.
- 3
Honour your suppression list without exception
Once an address hard bounces it must never be mailed again — including after a list re-import, which is how suppressed addresses usually creep back in.
- 4
Set a soft-bounce retry limit
Retry over 24 to 72 hours, then treat a persistently soft-bouncing address as undeliverable and suppress it.
- 5
Re-verify ageing segments
Lists decay continuously. Re-verify anything you have not mailed in several months before including it in a campaign.
- 6
Fix authentication before blaming the list
If bounces are policy rejections rather than unknown mailboxes, the problem is reputation or authentication — check SPF, DKIM and DMARC first.
Do this
- Verify before every major send, not once when the list was built
- Suppress hard bounces permanently and immediately
- Cap soft-bounce retries and then suppress
- Investigate 5xx policy rejections as a deliverability issue
Not this
- Retry a hard bounce, ever
- Re-import an old spreadsheet over your suppression list
- Treat every 4xx code as permanent and delete the contact on first failure
- Assume a clean list stays clean for a year
Catch hard bounces before they happen
Pingovo verifies single addresses or a full list in bulk — the same DNS and SMTP mailbox checks that produce a hard bounce, run before the send instead of after it.
Verify your list freeBounced, invalid, or catch-all?
These three describe closely related situations at different points in time, and mixing them up leads to the wrong remedy.
| Term | When you find out | What it tells you |
|---|---|---|
| Invalid | Before sending, through verification | The address is confirmed undeliverable — remove it now, at no cost |
| Bounced | After sending | The same failure, discovered the expensive way, with reputation impact attached |
| Catch-all | Before sending, inconclusively | The domain accepts everything, so deliverability is unknown until you actually send |
In Pingovo
Every bounce is a signal you paid for after the fact. Pre-send verification runs the same DNS/MX lookup and SMTP mailbox check that would eventually cause a hard bounce, just earlier — before the address ever leaves the send queue.
Frequently asked questions
A hard bounce is permanent — the address or domain does not exist, or the receiving server has blocked you outright. A soft bounce is temporary — a full mailbox, an oversized message, or a server that was briefly unreachable. Hard bounces must be suppressed immediately; soft bounces can reasonably be retried a few times.
It means the receiving mail server refused to deliver your message and returned a non-delivery report to your sending server. The bounce message normally carries an SMTP status code explaining why, which is what determines whether it counts as hard or soft.
There is no single published threshold, but staying under roughly 2% is the benchmark most deliverability practitioners work to. Sustained rates above that increase the odds of throttling, spam-folder placement or an outright block from major providers.
A 550 is a permanent rejection. Most commonly it means the mailbox does not exist, but it is also used when a server blocks a message on policy or reputation grounds — some providers return 550 with wording about spam probability. Either way it is a hard bounce and the address should not be retried.
It prevents hard bounces specifically, because the checks that cause a hard bounce at send time — does the domain have mail servers, does the mailbox exist — can be run beforehand. It cannot prevent soft bounces, which depend on conditions at delivery time such as a mailbox being full.
Yes, but with a limit. Most senders retry over 24 to 72 hours and then treat repeated soft bounces to the same address as a hard bounce. An address that soft bounces on every send is functionally undeliverable regardless of what the code says.
No, reputation recovers — but slowly, and only if the underlying cause is fixed. A one-off spike from a bad import is recoverable within weeks of clean sending; repeated high-bounce campaigns establish a pattern that takes considerably longer to undo.
Email lists decay continuously. People change jobs, close personal accounts, and companies let domains lapse. An address verified twelve months ago carries no guarantee today, which is why re-verification before major sends matters.
It is the list of addresses your sending platform will refuse to mail again after a hard bounce. Keeping it and never overriding it is one of the simplest protections against repeatedly mailing dead addresses and compounding reputation damage.