- Split bounces into hard and soft, and suppress hard-bounced addresses permanently after the first failure.
- Break the bounce rate down by list batch and by domain before you change anything, because most spikes trace back to a single batch.
- Pause any campaign that crosses 5% hard bounces until you know the cause, and keep 2% as your working ceiling.
A campaign shows a 4.6% email bounce rate on a Friday afternoon, and the instinct in the room is to change something. The sending mailbox gets blamed first, then the subject line, then the time of day. All of those guesses miss the point. A bounce is a message from a mail server saying that an address failed, and the pattern of those failures is data about where your addresses came from. Read the data before you touch the sender.
This guide covers how to read the bounce codes, how to find the batch behind a spike, why a bounce rate threatens more than one campaign, and the order in which to fix a list. It is written for the moment you have a bad number and need to act on it today.
An email bounce rate is a symptom, so read the codes
Email bounce rate is the share of sent messages that a receiving server refused or failed to deliver, usually expressed as a percentage of sends. It is a headline number, and like most headline numbers it hides the cause. Two campaigns with identical 4% bounce rates can need completely different fixes: one has a stale list, and the other has a DNS record that makes half the domains look nonexistent.
The cause is in the SMTP response. Every bounce comes with a status code, and the first digit tells you the category. Codes starting with 5 are permanent failures. Codes starting with 4 are temporary, and the server expects a retry. The enhanced status code that follows, such as 5.1.1, narrows the meaning. Learn the common ones and most bounce reports stop being mysterious.
| Code | Usual meaning | Type | Action |
|---|---|---|---|
| 550 5.1.1 | The mailbox does not exist | Hard | Suppress the address permanently |
| 550 5.1.2 | The domain or mail destination cannot be found | Hard | Check the domain and its MX records |
| 552 5.2.2 or 452 4.2.2 | The mailbox is full | Soft at first | Retry later, suppress after repeated failures |
| 421 4.7.0 | The sender is being rate limited | Soft, a throttle | Slow down the sending rate |
| 550 5.7.1 | Blocked for policy or reputation | Not a list problem | Investigate the sender, not the address |
The table has a trap in it. A 5.7.1 bounce looks like a bounce, and it is counted as one, but it says nothing about the address. The receiving server rejected the message for reasons related to you, such as authentication, content or reputation. Fixing the list will not clear it. That is why the code, not just the count, has to drive the response.
Hard bounces, soft bounces, and the ones in between
Hard bounces are permanent. The address is invalid, the domain doesn’t exist, or the destination doesn’t accept mail. The right response is to remove the address from every list and suppression set you use, immediately and permanently, after the first failure. Retrying a hard bounce wastes a send, adds to your bounce count, and reads to the receiver as someone who doesn’t check their list.
Soft bounces are temporary. The mailbox was full, the server was busy, or a message was too large. These deserve a retry, and most sending tools handle that automatically. The mistake is treating soft bounces as harmless. An address that soft-bounces repeatedly over several weeks is effectively dead, and you should suppress it after a small number of failed attempts.
The gray area is the category that varies by provider. A 5xx response that says “access denied” or “blocked” may mean the recipient’s server rejected you for policy reasons, not that the address is invalid. The right move is to check whether the same code appears across different addresses at the same provider. If it does, the problem is your sending reputation or configuration. If it appears on one or two addresses at one domain, it may be the recipient’s own filter, and the address can be treated with caution.
Find the source: slice by batch, domain and date
Once you know the codes, find where they come from. Three cuts usually do the job.
Slice by list batch. Every list you import should carry a batch identifier, meaning the date it was collected and the source it came from. Group your bounces by that identifier. Most spikes concentrate in one batch, and when they do, you have found the cause. A purchased list from one vendor, or a scraped list from one week, is the usual suspect.
Slice by domain. Group bounces by the recipient’s domain. Look for two patterns. The first is a domain where every address bounces, which usually means the domain is dead, has been sold, or never existed. The second is a domain with a typo, like acmee.com where acme.com was meant. Typos are common when names come from manual entry or from data that was entered quickly.
Slice by date. A spike on a single day points to an event: an import, a sequence change, or a mailbox that changed status. A slow climb over weeks points to a list that was aging. A list collected in February and used in October will carry a lot of addresses that have since been abandoned.
Here is a worked example. A team sends 5,000 messages in one campaign and sees 230 hard bounces, a rate of 4.6%. Grouping by batch shows that 180 of the bounces came from a vendor list purchased on 14 August. That batch makes up 78% of all bounces, and 3.6% of the total send volume on its own. Grouping by domain shows 40 bounces at company domains with obvious typos. The remaining 10 are scattered across unrelated addresses and aren’t worth chasing.
The useful lesson is the grouping, not the arithmetic. A team that reacted to the 4.6% headline would have changed mailboxes, rewritten copy, and still bounced the same vendor batch next week. Once the batch was identified, the fix was one decision: remove the batch.
Group by batch, not by mailbox: when bounces cluster by sending mailbox, the cause is usually the mailbox's reputation. When they cluster by list batch, the cause is the list. Check which one you are looking at before you act on it.
Why bounces damage more than one campaign
A bounce is a small negative signal to the receiving server, and the signals add up. Mailbox providers watch how often a sender targets addresses that don’t exist. A high proportion of invalid recipients looks like harvesting or guessing, and that perception affects how the whole domain is treated, not just the campaign that produced the bounces.
The damage also spreads through infrastructure. A sending domain with a rising bounce rate loses reputation, and its messages are more likely to be filed in spam or rate-limited. That is why the bounce problem shows up later as a placement problem: the campaign after this one lands in spam, and the team has to work out why. The deliverability checklist covers how bounce data sits in the wider stack, and the layer closest to it is list quality.
Repeated attempts to reach dead addresses make things worse. Retrying hard bounces, or sending a second sequence to an address that already failed, produces a stream of failures that receivers can see. The list doesn’t get better by being messaged again, and the sending reputation gets worse.
Count bounces the same way every time
An email bounce rate is only comparable over time if you count it the same way every time, and most sending tools don’t make that obvious. Three choices change the number. The first is the denominator. Some tools divide bounces by attempts and others by unique contacts, and a contact retried five times counts five times in one system and once in another. The second is whether soft bounces are included. A mailbox that is full for a week will generate several soft bounces from the same contact, and folding those into the headline rate makes a temporary condition look like a list problem. The third is the time window. A rate calculated over the whole campaign hides a spike that happened on Thursday.
Pick one definition and write it down. A practical choice is hard bounces only, divided by unique contacts attempted in the period, reported daily for the last seven days and cumulatively for the campaign. Keep soft bounces on a separate line so they can be watched without distorting the headline. When you compare two weeks, check that both were calculated with the same rule, because a change in the calculation looks exactly like a change in list quality.
The fix sequence: stop, suppress, correct, ramp
When the bounce rate is high, do the work in this order. Skipping steps is how a bad day becomes a bad month.
- Stop the batch. Pause any campaign that is sending from the affected list. A campaign that continues while you investigate adds bounces to your record every hour.
- Suppress. Add every hard-bounced address to a suppression list that every sequence checks before sending. Make the suppression immediate, not a weekly job.
- Correct. Fix what can be fixed. Correct typo domains by checking the company’s real domain. Remove dead domains from the list. Re-verify the remaining addresses in the affected batch, and send only the ones that pass.
- Ramp. When you resume, start small. Send to a limited group first, check the bounce rate on that group, and increase volume only when it stays low.
The ramp step is the one teams skip. They fix the list, resume at full volume, and see the bounce rate climb again within a day, because the verification missed a segment that was never clean. A small first send is cheap insurance, and it gives you a real measurement before you commit the rest of the list.
Keep a record of each incident: the date, the batch, the bounce rate, the cause, and the fix. Over a few months, that log shows which sources cause trouble, and it becomes the basis for deciding which lists to stop buying.
Prevention: three checks before every send
Most bounce spikes are preventable with three checks that take minutes.
Check the domains before import. Confirm that each domain has a mail server, using an MX lookup. Domains without MX records, or with obvious typos, can be removed before a single message goes out. This catches the dead domains and most of the typos.
Verify, and isolate the uncertain tier. Run a verification pass on every batch, and keep the uncertain results, such as catch-all addresses, in their own group with their own sending limits. The uncertain tier is where a bad batch hides, and separating it lets you see its bounce rate directly.
Cap the first send from any new list. Send the first 50 or so messages from a new batch, check the bounce rate after they’ve had time to resolve, and only then release the rest. A list that bounces badly on its first fifty will bounce badly on five thousand.
Never keep retrying a hard bounce: resending to an address that has already failed permanently adds failures to your record and looks like list harvesting to the receiver. Suppress it the first time, and don't try again in another sequence.
Set a working ceiling and a stop line. Keep hard bounces around 2% of sends as your working target, which is a practitioner rule of thumb rather than a number a provider publishes. Treat 5% as the point where you stop, investigate, and don’t resume until you know the cause. Teams that agree on those two numbers in advance spend less time arguing about them during a bad week.
What to do when it happens anyway
Some bounces will always happen. Lists age, people change jobs, and companies acquire and retire domains. The goal is not zero bounces. It is a bounce rate you can explain, a fast response when it spikes, and a list that gets cleaner over time instead of more dangerous.
If you are in the middle of a spike right now, do three things today: pause the affected batch, suppress the hard bounces, and run the grouping by batch and domain. Those three steps answer most questions, and they prevent the next send from making the problem worse.
The guide to finding and verifying addresses covers how to build the list in the first place so that fewer addresses fail. OutboundLeadPro’s features include a free Smart check on every lead’s email, which catches many of the same problems before a message is sent, and you can run your next campaign from your browser at OutboundLeadPro. A clean list is not a one-time achievement. It is a habit, and the bounce codes are how you keep it.
Keep reading
Cold Email A/B Testing: Why Most Tests Prove Nothing
Cold email A/B testing is often too small to mean anything. Here is the sample-size math at real reply rates, and how to read the results.
Daniel Khoury
September 19, 20263 min readHow to avoid spam folder placement: 12 causes and fixes
Want to avoid spam folder placement? These 12 causes, from authentication to list quality to complaints, each come with a concrete fix you can check.
Daniel Khoury
September 24, 20263 min readHow to build a lead list that stays clean after the first send
Build a lead list around a real ICP, with stage gates that reject bad rows before they cause bounces and complaints. Includes a worked example.
Daniel Khoury
October 7, 20263 min readSPF, DKIM and DMARC explained for cold email
The three email authentication records decide whether you reach the inbox — and most cold outreach fails because one is missing or wrong. Here's each one in plain English.
The OutboundLeadPro Team
October 11, 20262 min read