- An aggregate bounce rate averages several distinct failure modes; break bounces down by type before deciding on a fix.
- Hard bounces point at list quality, blocks point at sender reputation - re-verifying a list will not fix a domain problem, and it is the most common wasted spend in outbound.
- Segment the rate by source, import batch, and list age: a concentrated rate is a contained problem with a much cheaper fix than a uniform one.
Your bounce rate is already too high, and you need to know what it is telling you.
That is a different problem from preventing bounces on a campaign you have not sent yet. The list is out. The sends have happened. What you have now is a number and a pile of bounce messages, and both are diagnostic information if you read them properly.
Most teams skip the reading step. They see a bad percentage, assume “the list was dirty”, and re-verify everything. Sometimes that is right. Often it is expensive and misses the actual cause - because a bounce rate is an average over several distinct failure modes, and they do not have the same fix.
What this guide covers
How to diagnose an outbound bounce rate you have already measured: what the bounce types mean, what a rising trend indicates, how CRM import habits feed the number, and which fix matches which pattern.
What it does not cover: the pre-send procedure for a campaign that has not launched. If you are working through a list before hitting send, the pre-launch bounce preflight is the guide you want - this one is for after the numbers come back.
Read the bounce type before anything else
An aggregate bounce rate hides the only detail that matters. Break the bounces down by type first, because each points somewhere different.
| Bounce type | What it means | Most likely cause | First action |
|---|---|---|---|
| Hard - unknown recipient | Mailbox does not exist | Stale data, job changes | Age-check the source, suppress and re-verify |
| Hard - domain not found | Domain does not resolve | Dead companies, typo’d domains | Domain-level validation pass |
| Soft - mailbox full | Real person, unavailable | Usually nothing wrong | Retry later, do not suppress |
| Soft - temporary failure | Receiving server deferred | Often your sending volume | Slow the ramp, check domain health |
| Block - reputation | Provider refusing your domain | Sender reputation damage | Stop sending, investigate before more volume |
| Block - content or spam | Message rejected, not the address | Copy, links, or authentication | Sending setup, not list quality |
The distinction that changes your next move most: hard bounces indicate a list problem, blocks indicate a sender problem. Two campaigns can report the same headline rate and need opposite responses. If that rate is almost all hard bounces to unknown recipients, the list needs data work. If it is made up of blocks and soft deferrals, re-verifying the list will cost money and change nothing, because the addresses were fine and your domain is the issue.
What counts as a good rate
Benchmarks vary by market, source, and campaign type, so an absolute target is less useful than it looks. Two questions are more diagnostic than any threshold.
Is it moving? A stable rate reflects your normal source quality. A sudden spike means something specific changed - a new source, a bigger batch, a suppression rule that stopped running, a new sending domain. Find the change rather than re-cleaning everything.
Is it concentrated? Segment the rate by source, by import batch, and by list age. A rate that is uniform across segments is a process problem. A rate driven by one source or one import is a contained problem with a much cheaper fix - and it tells you which supplier or which workflow to stop trusting.
Tracing hard bounces back to a cause
If the breakdown points at your list, the next question is which upstream cause produced it. Each leaves a different signature in the data, which is what lets you tell them apart after the fact.
Decay. Bounces spread evenly across a list that has not been re-verified for months, with no single source standing out. People changed jobs, companies restructured, aliases were retired. The records were correct when collected. Check the collection dates - if the bad addresses skew old, this is decay rather than a sourcing failure.
Source quality. Bounces cluster in records from one supplier, scrape, or purchased file, while records from other sources in the same campaign perform normally. The comparison across sources is the diagnosis; without segmenting you cannot see it.
Unverified at entry. Bounces cluster in one import batch. Something reached the database without passing validation - often a one-off upload during a busy period. Look at what else arrived that day.
Formatting damage. Bounces on addresses that are visibly malformed on inspection: hidden characters, stray whitespace, two addresses in one field, notes stored in the email column. These fail as invalid rather than as unknown recipients, and they point at an export or merge step rather than at the source.
Suppression gaps. The same addresses bounce that bounced last time. This is the one worth checking first, because it is cheap to confirm and embarrassing to miss - it means your suppression list exists but is not being applied at send time.
Preventing all five is a pre-send discipline rather than a diagnostic one, and the pre-launch bounce preflight covers the procedure in full.
Matching the fix to the pattern
Once you know which failure mode dominates, the response narrows considerably. The common mistake is applying all of these at once, which is slow and teaches you nothing about which one worked.
| What the data shows | What to do |
|---|---|
| Hard bounces concentrated in one source | Stop using that source pending review; re-verify only its records |
| Hard bounces concentrated in one import batch | Audit that batch’s cleaning process, not the whole database |
| Hard bounces spread evenly, skewing towards older records | Age-based re-verification; the data decayed rather than arrived broken |
| Rate climbed after a source or supplier change | Compare the new source’s records against the old baseline before broader action |
| Mostly soft deferrals | Reduce sending volume and slow the ramp; the list is probably fine |
| Mostly reputation blocks | Pause outbound entirely and repair domain health first |
| Suppression list stopped being applied | Fix the workflow gap; re-cleaning the list will not stop repeat sends |
Note that only three of those rows call for cleaning data. Bounce problems get misattributed to list quality because that is the familiar explanation, which is how teams end up paying to re-verify a list that was never the cause.
For the systematic pre-send procedure that prevents most of the list-driven rows above, work through the pre-launch bounce preflight. If the fix points upstream to how records enter your database in the first place, the nine-check pre-import pass is where email quality gets decided. For UK phone compliance rules, see TPS checks and AI outbound compliance.
After the diagnosis: suppression and re-entry
Diagnosis only pays off if the result is written back somewhere the next campaign will read.
Suppress hard bounces globally, not per campaign. A hard bounce recorded against one sequence and nowhere else will be re-sent by the next list built from the same source. The suppression list has to sit above individual campaigns.
Do not re-verify a hard bounce and re-enrol it. A verification tool may return “valid” on an address that has already returned a permanent failure. The bounce is the stronger evidence - it is a live answer from the receiving server.
Give soft bounces a bounded retry. A soft bounce is a temporary condition, so a limited number of retries is reasonable. Convert to suppression once a record has soft-bounced repeatedly across separate sends, which usually means the mailbox is abandoned rather than briefly full.
Feed the pattern back to the source. If one source or one enrichment run accounts for most of the failures, the fix belongs at acquisition. Continuing to clean its output on every campaign treats the symptom indefinitely.
The forward-looking version of this - what to check before a campaign rather than after - is a separate workflow with its own checks, covered in the pre-launch bounce preflight and, for records entering the CRM in the first place, automated pre-import cleaning.
Final thought
A bounce report is diagnostic information, and most of it is discarded. Teams read the headline rate, conclude the list was bad, and clean everything more aggressively next time - which costs coverage without addressing the specific cause.
The bounce type, the concentration by domain, and the concentration by source between them usually identify what actually went wrong. Read those three before changing anything, and the fix is normally narrower than a full re-clean.
DataFixr helps outbound teams clean, deduplicate, validate, and prepare lead data before it reaches sales engagement tools - so bad records are caught before they damage deliverability. Start using DataFixr free ->