Keeping Bounce Rate Under Control at Scale

A contact who changed jobs and left their old email active but unmonitored, a typo introduced during manual data entry, a role-based address that got decommissioned, or a list bought or scraped without real-time verification are the most common sources. Each has a different fix: job changes need periodic re-verification, typos need validation at entry, and unverified lists need a verification pass before their first send, not after bounces start showing up.

Batch verification checks a whole list at once before a campaign starts, catching most bad addresses upfront but going stale the longer a list sits before use. Real-time verification checks an address at the moment it's about to be used, catching a contact who changed jobs since the last batch check. Most teams benefit from both: a batch pass when a list is first built or imported, and real-time checks for lists that sit for weeks before a campaign actually goes out. A dedicated verification tool covers the batch pass well, checked against a fresh real-time pass for anything that's been sitting for more than a few weeks before it actually goes out.

Rather than reacting after a campaign has already run at a damaging bounce rate, set an automatic threshold that pauses a sequence mid-run if bounce rate on the sends so far crosses a level meaningfully above your recent baseline. This catches a bad list segment early rather than letting it run its full course and damage domain reputation for every other sequence sharing that sending inbox.

For example, a team imports a purchased list, verifies it in one batch pass, then sits on it for a month while the campaign is built. By send day, some contacts have changed jobs and some old addresses now bounce. A real-time check right before the send catches those, and a pause threshold set slightly above the recent baseline stops the run if bounces still climb. The rule of thumb: batch verify when the list is built, real-time verify when it is used, and pause automatically when the numbers drift, so a stale list never gets to run its full course.

Say a list of 5,000 contacts was verified and clean when built six months ago. By now, a meaningful share of those contacts have likely changed roles, and some of those old addresses will still accept mail temporarily before eventually bouncing or forwarding, which means the list looks fine on a quick check but has quietly degraded. Re-verify any list older than a few months before a new campaign rather than assuming a past clean bill of health still holds.

Pause the sequence immediately rather than letting it finish its run, re-verify the remaining unsent portion of the list before resuming, and review whether the spike traces to one bad data source (a specific list purchase or scrape) that should be excluded going forward. Resuming the same sequence without addressing the root cause just delays the same problem to the next batch.

Work through these steps in order:

1. Pause the sequence immediately instead of letting it finish its run at a damaging bounce rate.
2. Re-verify the remaining unsent portion of the list before you resume sending anything.
3. Split hard bounces from soft bounces, since a rising hard bounce rate usually points to a list sourcing problem.
4. Check whether the spike traces to one bad data source, such as a specific list purchase or scrape, and exclude it going forward.
5. Resume only after the root cause is addressed, and watch bounce data at the inbox level, not just in aggregate.

Hard bounces (a permanently invalid address) and soft bounces (a temporary issue like a full mailbox) point to different problems and deserve different responses. A rising hard bounce rate almost always means a list sourcing problem; a rising soft bounce rate can sometimes be a temporary provider-side issue unrelated to your list quality at all. Look at the split before assuming every bounce spike has the same root cause.

Keep bounce data visible at the sending-inbox level, not just aggregated across your whole domain, since a single problematic inbox or list segment can hide inside a healthy-looking overall average. Reviewing bounce rate only in aggregate is one of the easiest ways to miss a localized problem until it has already quietly dragged down a broader set of inboxes that happen to share the same sending domain.