What to Do After a High Bounce Rate: The First 24 Hours

After a high bounce rate, stop every send that uses the affected list, then read the bounce messages before changing anything else. Sort the bounces by SMTP code: "mailbox does not exist" codes point at the list, and "refused by policy" codes point at your authentication or reputation. Fix the cause you actually have, verify whatever is left unsent, and resume with a small, clean batch.

This post is the first 24 hours: triage and containment. If the spike has already damaged your domain's standing, recovering a damaged sender reputation covers the 30-day rebuild that follows.

Hour 0: stop the bleeding

Pause everything that will send to the same list, including follow-ups and other campaigns. Most sending tools pause only the campaign that crossed their threshold. Instantly, for example, auto-pauses a campaign at a 5% bounce rate by default after 200 or more sends, per its help centre; our bounce limits by platform table lists the others. Those pauses are per campaign. If the same leads are loaded into a second campaign, or follow-up steps are still queued, those keep sending.

Checklist for the first hour:

1. Pause every campaign that contains contacts from the same import or source.
2. Pause scheduled follow-ups for contacts who have not yet bounced.
3. Do not delete anything yet. You need the bounce data and the list as it was sent.
4. Note the time, the campaigns and the sending inboxes affected.

Hour 1: export and sort the bounces

The bounce message, not the bounce count, tells you what went wrong. Export every bounce with the full SMTP response and sort by enhanced status code. The groups that matter:

Code	Meaning	Points at
550 5.1.1	Mailbox does not exist	The list
550 5.4.1	Microsoft 365 rejecting an address it does not recognise	The list (usually)
550 5.2.1	Mailbox disabled	The list
550 5.7.1 / 554 5.7.1	Refused by policy or as spam	Authentication, blocklist or reputation
552 5.2.2 / 452 4.2.2	Mailbox full	Usually an abandoned mailbox
421 4.7.0 / 450 / 451	Temporary deferral	Volume, rate or reputation; retried automatically

Then count. If most bounces are 5.1.1-type, the problem is data quality: addresses that never existed, or people who left. If most are 5.7.x, your messages are being refused even where the mailbox exists. That is not a list problem, and cleaning the list will not fix it.

One pattern needs a closer look: a single recipient domain returning 5.4.1 for every address. That often means the Microsoft 365 tenant is blocking unknown recipients wholesale. Remove the domain from this campaign rather than treating each address as individually dead.

Hours 2-4: find the source

Trace the bad addresses back to where they came from. Bounce spikes often have one origin. Group the hard bounces by:

• Import or list source. One vendor export, one scrape, one old CRM segment.
• How the address was obtained. Published, pattern-guessed, or from a finder tool.
• Verification status at import. Were these addresses verified? When? Were catch-all results mixed in with valid ones?
• Sending inbox and domain. If 5.7.x bounces cluster on one domain, that domain's authentication or reputation is the issue.

The usual findings are an unverified import, a list verified months before sending, or catch-all addresses treated as valid. Each has a different fix:

Finding	Fix
Never verified	Verify the remainder before any more sends
Verified long ago	Re-verify; old results go stale as people move jobs
Catch-alls sent as valid	Split them into a separate, small, slow batch, or drop them
Pattern guesses for unverifiable domains	Drop them, or confirm another way
5.7.x clustered on one domain	Check SPF, DKIM, DMARC and blocklists for that domain

Hours 4-8: check the infrastructure

Even when the list is the cause, check that the spike has not already triggered blocks. Three checks:

1. Authentication. Run each sending domain through the deliverability audit to confirm SPF, DKIM and DMARC pass. A 5.7.1 wave right after a DNS change is usually an authentication break, not a reputation hit.
2. Blocklists. Run the blacklist check on the sending domains. A listing changes the plan from "clean and resume" to "delist first".
3. Google Postmaster Tools. If you have it set up, check domain reputation and spam rate for the days around the spike. Data can lag, so check again over the following days.

Hours 8-24: clean what has not been sent

The unsent part of the list is the same data that just bounced, so verify all of it before sending again. Then:

• Suppress every hard-bounced address at workspace level, so it cannot be re-imported into another campaign.
• Verify the remaining contacts and remove invalid results.
• Separate catch-all and unknown results from confirmed-valid ones.
• Remove the worst source entirely if one vendor or segment produced most of the bounces.

SimpleVerifier runs that check on CSV uploads and exports valid, risky and invalid rows separately, which makes the split straightforward; any verifier that separates those groups works.

Resuming: small, clean and watched

Restart with only confirmed-valid addresses, from the healthiest inboxes, at reduced volume. If you were sending 40 a day per inbox, start well below that for a few days. Watch bounce and complaint rates after each batch. Only reintroduce catch-all addresses, in small numbers, once the main batch has stayed clean.

If the bounces were 5.7.x and authentication was fine, resuming at normal volume will make things worse. That is a reputation problem, and the 30-day recovery plan linked at the top applies.

What not to do

• Do not switch to new domains and resend the same list. The list will bounce just as badly from the new domains.
• Do not raise volume to dilute the bounce percentage. More sends to a bad list produce more bounces.
• Do not delete the bounce log. You will need it to check the next import from the same source.
• Do not re-verify only the bounced addresses. They are already known bad; the risk is in the ones you have not sent to yet.

The takeaway

Pause wide, read the codes, find the source, check the infrastructure, verify what is left, and come back small. Most bounce spikes are a single bad list doing what bad lists do, and the fix is in the data. The ones that are not show up in the 5.7.x codes, and those need a reputation fix rather than a cleaner list.