Bounce Rate Was Fine Last Week and Jumped This Week: What Changed

If your bounce rate was fine last week and jumped this week, something changed, and the quickest way to find it is to pause the affected campaign for an hour, read the bounce messages, and split the bounces by day, lead source, sending inbox and recipient domain. Nonexistent-mailbox messages mean the new leads are the problem. Messages about policy, authentication or reputation mean your sending setup is the problem. Whichever it is, verify what is still unsent before you restart. SimpleVerifier Pro does that for $39 a month: the first 100,000 checks a month at full speed, then slower, never cut off, with 100 free checks to start.

Why a spike has a cause

Mailbox providers and lists do not usually change overnight without a trigger on one side or the other. Spikes tend to come from one of a short list of changes. Work through them in order, because the first few take minutes to check.

The checklist: what changed

1. A new lead file or a new source. The most common cause. A fresh import from a scraper, a database export or a purchased list brings addresses nobody has checked. Compare the day the bounce rate rose with the day the new file went live. See find which list source caused bounces and the bounce rate by source tool.

2. Older leads reached the front of the queue. A campaign that sends in order may have worked through the freshest leads first and reached the oldest ones this week. If your tool sends by list order, the spike can follow the age of the contacts rather than a change you made.

3. Follow-up steps began. Step one may have gone to a verified list, while step two or three include addresses added later or rotating through different inboxes. See follow-up emails bouncing.

4. A catch-all batch. Catch-all domains accept mail at the door and can bounce later, so a send that looked clean last week produces bounces this week. See catch-all leads in sequences.

5. One inbox changed. A mailbox that lost its authentication, was disconnected and reconnected, or hit a provider limit can produce bounces that look like a list problem. Check whether the bounces concentrate on one sender. See cold email bounce budget per inbox.

6. A DNS or authentication edit. A changed SPF, DKIM or DMARC record, a moved domain, or a lapsed tracking domain can make receiving servers start refusing your mail. See monitor sending domains' SPF, DKIM and DMARC and cold email bounce after domain migration.

7. A receiving provider started refusing you. If most bounces come from one provider's domains and say policy or reputation, the problem may be your standing with that provider. See domain, IP or mailbox reputation and email list segmentation by mailbox provider.

8. A change in how your tool counts. Some tools change which events count as bounces, or you changed a filter on the report. Compare against the raw bounce messages in the sending mailboxes before trusting a dashboard shift.

What to do in the next hour

1. Pause the affected campaign. Not every campaign, just the one with the jump. If you cannot tell which, pause the newest.
2. Export the bounces with messages and timestamps.
3. Sort by message. The bounce message analyzer turns codes into plain English. Mailbox not found, domain not found, full mailbox, policy block.
4. Group by day. The daily bounce rate tracker shows whether it started on a specific day. Match that day to a change on the checklist.
5. Group by recipient domain. The bounce domain hotspot finder shows if one provider or company dominates.
6. Group by sending inbox and by source. Whatever spikes in one group and not the others is your answer.

Step-by-step fix

Once you have the cause:

• If it is the list: suppress the hard bounces (suppression list guide), verify the unsent contacts on the verify page or the CSV email verifier, and restart with valid addresses. Put risky and catch-all addresses in their own small campaign, sized with the catch-all send limit calculator.
• If it is one inbox: rest it, fix its authentication and spread its leads across the others. See split leads across sending inboxes.
• If it is DNS or authentication: correct the record, wait for it to propagate, then send a small batch.
• If it is a provider block: reduce volume to that provider and follow restarting sending after a block. More volume does not fix a refusal. See also sender reputation recovery.

Resume at a fraction of the usual volume, read the next day's bounces and then scale. For the first 24 hours after any spike, what to do after a high bounce rate is the full checklist, and pause at a bounce spike describes how to set the pause line in advance.

Prevention: verify before every send

Most of the checklist is preventable by two habits. Tag every lead with its source and import date so a future spike can be split in minutes. And verify every file before it is imported, not after it bounces. Verification does not cover the DNS or provider items, but it removes the largest group, bad addresses, which makes the other causes easy to see.

Do not rely on any checker's accuracy figure. Check a slice, send to the valid ones, and judge by your own bounces.

A worked example

A team's campaign has bounced at a steady low number for weeks. On Wednesday the daily count triples. They pause the campaign and export the week's bounces. Grouped by day, the jump starts Tuesday afternoon, which is when a new file was imported. Grouped by source, almost all the new bounces come from that file. The messages say the mailboxes do not exist. Cause found in a few minutes: the new file was never verified.

Another team sees the same jump. Grouped by day, it starts Tuesday. Grouped by source, the bounces are spread across every file. Grouped by sending inbox, one inbox has most of them. The messages mention authentication failure. Cause: that inbox's DNS record was edited on Monday. A different cause, a different fix, and the same dashboard symptom.

The point of the split is that it takes minutes and stops you guessing. A list fix applied to an authentication problem accomplishes nothing, and the reverse.

Mistakes to avoid

• Fixing the first plausible cause. Check the others before you act, because several can overlap.
• Resuming because the bounce number dipped. A pause lowers the daily count by construction. It says nothing about the cause.
• Blaming the provider first. Check your own changes first, because they are the part you can fix.
• Not recording the change. Write down what you changed and when. The next spike will be much faster to solve.

What it costs

SimpleVerifier Pro is $39 a month. The first 100,000 checks a month run at full speed, then slower, never cut off. You can try 100 free checks first, no card. See pricing.

Bottom line

A spike is a signal that one thing changed. Pause the campaign, read the messages, split by day, source, inbox and domain, then fix the specific cause and verify what is left. Try the 100 free checks on the unsent contacts to see whether the new list is the culprit.