Instantly bounce rate suddenly high? Check the mail host before the list

Sunny Ray · Aug 15, 2026 · 7 min read

If your bounce rate in Instantly or any other sending tool suddenly jumps, don't start with the list. Start by grouping bounces by sending domain inside a single campaign. Same campaign means same copy and same leads, so if some sending domains bounce and others don't, the cause is your sending infrastructure, not your data. In our case it was one mail host, and the fix took minutes once we saw it.

The dashboard will push you toward the list. A red bounce badge reads like "your leads are bad." Sometimes they are. But a sending tool can count an SMTP relay rejection as a bounce exactly like a dead mailbox, so a broken sending path looks identical to a dirty list until you split the data.

The red badge that lied

On August 15 one of our workspaces showed 428 bounces on 2,220 sends. That's a 19.3% bounce rate, high enough to put every domain at risk and stop campaigns in their tracks.

The obvious suspects lined up. Maybe the verification was bad. Maybe the list was old. Maybe something in the copy was triggering filters. Each of those has a fix that costs money and time: buy a new list, re-verify everything, rewrite the copy.

Before doing any of that, we asked a cheaper question. Which mailboxes sent the emails that bounced?

Split by sending domain, inside one campaign

We pulled the contacted and bounced leads, read the sending mailbox for each one, and grouped the results by sending domain.

The answer was perfectly bimodal. Every sending domain on one mail host bounced between 26% and 100%. Every sending domain on the other host bounced 0.0%. Nineteen domains, zero exceptions.

That pattern can't come from the list. The same campaign sends the same leads through all its mailboxes. If the leads were bad, every domain would bounce at a similar rate. It can't come from the copy either, because the copy is identical across domains. When the bounce rate tracks which mailbox sent the email, the mailbox's path to the internet is the problem.

We confirmed the copy theory a second way. One campaign with no sensitive language at all, nothing about finance or investing, still bounced 89 to 100% on the bad host and 0% on the good one. Content can't explain a difference that follows the mail server.

Match the split to the MX record

Once you see a split, check the mail exchanger record for each sending domain. The MX record tells you which mail host handles that domain. In our case, every bouncing domain pointed to one host and every clean domain pointed to the other.

That's the confirmation. Bimodal split by host means infrastructure. A flat rate across all domains means you should look at the list or the copy next.

You don't need to be a mail engineer to run this check. A spreadsheet with sending domain, sends, bounces and MX host is enough. The pattern is usually obvious once the rows are lined up.

The fix: pause the dead stack, keep sending on the healthy one

We paused the 91 mailboxes on the failing host. The 11 campaigns resumed clean on the 208 healthy mailboxes.

That's the part I want founders to hear. We didn't buy a new list. We didn't re-verify thousands of contacts. We didn't rewrite a word of copy. The fix was turning off the mailboxes that couldn't deliver and letting the ones that could do their job.

If we had followed the dashboard, we would have spent money on a new list, seen the same bounce rate, and concluded the new list was bad too. That loop can burn weeks.

Why sending tools blur this

A bounce sounds like one thing. It's really two.

A hard bounce from a dead mailbox means the address doesn't exist. That's a list problem.

A rejection at the relay means your mail never got where it was going because something in the sending path refused it. That's an infrastructure problem.

The sending tool records both as a bounce. The number on the dashboard is the sum, and it doesn't tell you which kind you have. So the only way to know is to look at where the bounces come from.

What we didn't have to do

It's worth listing the fixes we were one bad guess away from making, because each one would have felt reasonable at the time.

Buying a fresh list. The list wasn't the problem, so a new one would have bounced the same way on the same mailboxes. We'd have paid for data and blamed the vendor.

Re-verifying everything. When we later re-ran a sample of real bounces through verification, nearly all of them came back as valid or catch-all. Verification wasn't the gap.

Rewriting the copy. The clean campaign with no sensitive words bounced on the bad host and delivered on the good one. A rewrite would have changed nothing.

Pausing all sending. That's the panic move, and it would have stopped the 208 healthy mailboxes along with the 91 broken ones. Weeks of warmup, idle for no reason.

Every one of those fixes treats the whole system as suspect. Splitting by domain lets you treat only the broken part.

There's a cost to guessing wrong that doesn't show up on any invoice. Each failed fix eats a week, and each week of thin results makes the team trust outbound a little less. By the third wrong guess, people start saying cold email doesn't work in their market. Usually it does. They just never found the broken pipe.

A five-minute bounce triage checklist

When the bounce badge turns red, run this before you change anything.

Pick one campaign. One campaign holds copy and leads constant.

Pull every contacted lead and every bounced lead, with the mailbox that sent to them.

Group by sending domain. Calculate the bounce rate for each one.

Look at the shape. If a few domains carry almost all the bounces and others are near zero, it's infrastructure. If every domain bounces at roughly the same rate, it's the list or the copy.

Check the MX record for the bouncing domains. If they share a host, you've found it.

Pause the affected mailboxes, keep the healthy ones sending, and fix or replace the broken stack at your own pace.

Only if the rate is flat across domains should you move on to re-verifying the list. And even then, re-verify a sample of actual bounces first. It tells you fast whether verification would have caught them.

The lesson underneath

Outbound has a lot of moving parts, and dashboards summarize them into a handful of numbers. Those numbers are useful, but they hide the shape of the problem. A 19.3% bounce rate told us something was wrong. It didn't tell us what.

The habit worth building is splitting before guessing. Hold the variables you can hold constant, vary the one you suspect, and let the data point. It's slower than reacting for about five minutes and faster for every week after that.

It's also why we set up the sending layer the way we do: separate warmed domains, never your main one, and mailboxes we can pause by host without touching anything else.

Frequently asked questions