DELIVERABILITY
Why verified email lists still bounce
Updated July 2026 // by Mark Glazer
A verified flag is only as good as the check behind it. Most lists are labelled verified from a data vendor's own claim, an MX record or a live website, none of which can see whether a mailbox exists. Only a live per-address mailbox probe can, and even that decays. Gateway rejections are a separate problem entirely.
This page is written from our own postmortem, not from theory. We shipped a campaign that bounced at 7.05%, traced every bounce, and found the cause was a single line of logic in our own list builder. The numbers below are ours. We publish them because the mistake is easy to repeat and almost impossible to see from the outside.
The word "verified" is doing no work
Our list builder marked an address verified if either of two conditions held: the data vendor's own validation field said it looked valid, or a mailbox-level SMTP probe said it was good. Written as code it looked reasonable. In practice that OR treated two completely unequal signals as interchangeable.
VERIFIED = provider_validation IN ('Valid','Valid (Esp)','Valid (Digital)')
OR smtp_status IN ('valid','safe')
An SMTP probe actually connects and asks the receiving server whether the mailbox exists. A vendor validation field is the vendor's opinion, of unknown age and unknown method. Joining them with OR means the weaker signal alone is enough to ship.
The fix: a verified flag must name the check that produced it. We now gate every send on a live per-address verdict and refuse the list outright if any address lacks one. A vendor column, an MX record, an SMTP status inherited from a previous quarter, and a live check are four different things.
Catch-all is not verification
A catch-all domain accepts mail for every address, whether or not the mailbox exists. Ask it about nobody-at-all@thatdomain.com and it says yes. So a catch-all result tells you precisely one thing: the check could not determine anything.
Verification vendors report this honestly as catch_all or accept_all, and a great many people then count those rows as deliverable because they are not marked invalid. On our lists catch-all routinely runs at 30 to 40 percent of a raw B2B pull, which is a large enough block to change a campaign's economics if you treat it as verified. The share depends heavily on where the prospect's mail is hosted: our measured catch-all rate by mail provider runs from 6.7 percent at Microsoft 365 tenants to 45.5 percent at Google Workspace.
The fix: treat catch-all as its own bucket, never as verified. Hold it back from a first send, or send to it only when you have separate evidence the person is real, such as a reply from that address in your own CRM. That exception should be deliberate and rare.
MX records are domain-level and cannot see a mailbox
An MX lookup tells you the domain has somewhere to receive mail. That is all. It cannot distinguish a company of four hundred people from a parked domain with a mail host attached, and it certainly cannot tell you whether firstname.lastname@ exists.
The same applies to a live website. We have measured this directly on our own data: a domain whose website is down is not the same as a domain whose email is dead, and the two correlate far more weakly than people assume. Companies let a marketing site lapse while the mail keeps flowing.
| Signal | What it actually proves | Can it see a mailbox? |
|---|---|---|
| MX record | The domain has a mail exchanger | No |
| Website responds | A web host is answering | No |
| Vendor "valid" flag | The vendor believed it, at some point | No |
| Catch-all result | The domain accepts everything | No |
| Live SMTP probe | The server accepted this specific address | Yes, at that moment |
Some bounces are not a list problem at all
This is the one that costs people the most time, because they respond to it by re-verifying a list that was already fine.
Corporate security gateways such as Mimecast, Proofpoint, Barracuda and Cisco IronPort sit in front of a real, working mailbox and reject mail from unknown senders by policy. The address exists. The person is real. Verification correctly said so. The rejection happened on the receiving perimeter, and no amount of list hygiene changes it.
On one campaign, 263 of the 2,748 recipients not yet contacted were on gateway-fronted domains — 9.6%. Of the 48 bounces recorded at that point, 31 were gateway blocks or policy refusals: 64.6%. A single gateway operator, Mimecast, accounted for 20 of the 48 (41.7%).
The fix: identify gateway domains before you send and segment them, rather than discovering them in your bounce log. We now split them into their own send with different sender warmth expectations. On the campaign above, removing 263 gateway recipients moved the bounce rate from 3.34% (59 bounces / 1,766 sends) to 1.19% (57 bounces / 4,791 sends made after the split), measured to 22 August 2026.
The bounce may be about your sending domain, not their address
Read the actual rejection text. A surprising share of what people log as "bad list" is the receiving server telling you, in plain language, that it does not like your domain.
We learned this the hard way. A set of our own sending domains shared an obvious naming pattern, all variations on one brand word. They ended up listed on a public abuse blocklist, and Gmail's rejection messages named the sending domain explicitly. The bounces traced to those domains, not to the recipients. Sending domains are now chosen with the cold email domain generator, which rejects any name that repeats a word already used in the fleet.
The fix: read the SMTP response, not the bounce count. A 550 that names your domain, a gateway rejection and a genuine "address not found" are three different failures with three different remedies. Also, do not build an entire mailbox fleet on one obvious domain prefix, because a pattern that is obvious to you is obvious to a filter.
Verification decays, so when you check matters
A verification result is a snapshot of one moment. People leave, roles are consolidated, companies restructure. A list verified when it was built and sent eight weeks later is not a verified list, it is a historical record.
B2B contact data ages faster than most people plan for. Job changes alone put a meaningful slice of any list out of date within a quarter, and the addresses that go stale are disproportionately the senior ones you most wanted to reach.
The fix: verify immediately before the send, not at list build. If a list has been sitting for more than a few weeks, re-run it. The cost of verification is trivial next to the cost of a bounce rate that damages the sending domain you will still need next month.
The operator's version
If you take nothing else from this page.
Method
What this measures. One B2B outbound campaign run by ReplyLead in July–August 2026, sending to business addresses at companies matching a single client's ideal customer profile. One campaign, one operator — not a cross-client study and not an industry benchmark.
How gateway domains were identified. Every recipient domain's MX records were resolved before sending. A domain was classified as gateway-fronted when its MX hostnames belonged to a security gateway operator — Mimecast, Proofpoint, Barracuda, Sophos, Trend Micro or Cisco IronPort — rather than to a mailbox host. Gateway classification was applied ahead of tenant-host detection, because the gateway sits in front of the tenant and is what accepts or rejects the connection.
How bounces were classified. Each bounce was categorised from its verbatim bounce body, most-specific-first: dead mailbox, gateway block, policy block refusing unknown senders, named blocklist, spam-filter reject, mailbox full, temporary deferral, dead domain.
The population. At the point of the split the campaign held 4,514 recipients: 1,766 already contacted and 2,748 not yet contacted. Of the 2,748 unsent, 263 were on gateway-fronted domains — 9.6% of the unsent list, or 5.8% of all 4,514.
Before and after, with both denominators. Before: 59 bounces / 1,766 sends = 3.34%, the rate at the point of the split on 25 July 2026. After: 57 bounces / 4,791 sends = 1.19%, counting only sends made after the split and excluding all pre-split volume, as of 22 August 2026. Both count hard and soft bounces as recorded by the sending platform. The after-figure is cumulative on a campaign that is still sending, so it will keep moving; it is published with its numerator, denominator and date so it can be checked and so its age is visible.
Why a sending platform reports something different. Platforms show a campaign-lifetime bounce rate that still contains the pre-split bounces — 116 / 6,557 = 1.77% on the same date. That answers a different question and is not comparable with the after-figure.
Limitations
One campaign, one client, one ICP, one operator. These are not industry rates and should not be read as such.
Small bounce base. The before-figures rest on 48 classified bounces. Percentages of a two-digit base move a lot on small changes.
Not a controlled experiment. The gateway cohort was removed, not randomised, and no holdout was retained. The before/after is an observed change under an intervention, not an isolated causal effect, and other things changed over the same period.
Domain-level classification. Gateway detection is a property of the domain's MX record, not of the individual mailbox behind it.
Rule-based bounce classification reads bounce-message text and can mis-file unusual wording; 2 of the 48 bounces were unclassified.
Point in time. MX records change and gateway deployment shifts. This reflects July–August 2026.
The mechanism is not our discovery. Security gateways rejecting mail from unfamiliar senders is well documented and acknowledged by the gateway vendors themselves. What is ours is the measurement on a live campaign.
Questions people actually ask
What bounce rate is acceptable for cold email?
Under 2% is the working target and under 1% is healthy. Above 5% you are actively damaging the sending domain, and mailbox providers respond to sustained high bounce rates by filtering everything from that domain, including the mail that would have landed.
Is a paid verification service worth it?
Yes, and the reason is arithmetic rather than loyalty to a vendor. Verification costs a fraction of a cent per address. A damaged sending domain costs weeks of warmup and the campaigns you could not run during them. We gate every list on a live per-address verdict and block the send if any address lacks one.
Why did my bounce rate spike when the list did not change?
Look at your sending side first. A blocklisted domain, a broken SPF record, a mailbox pushed past its volume ceiling and a newly warmed domain sending too much too early all produce bounce spikes on a list that was fine yesterday. Check what your own domain is publishing with the deliverability checker. Addresses that keep bouncing and keep being mailed are also the raw material of recycled spam traps, which is why every hard bounce is suppressed permanently.
Can I just remove bounces after the first send?
You can, and you should, but it is expensive learning. The first send is where the damage happens, because that is when the receiving providers form their opinion of your domain. Cleaning afterwards fixes the list and not the reputation.
We run this for clients on a revenue-share model
List verification, gateway segmentation and sending-domain health are part of the operation, not an add-on. We win when you win.
Apply to work with usDeliverability guide. For the practitioner's view of the same traps — verification decay, catch-all tiers and gateway accept-then-bounce — read why a "verified" email still bounces // Deliverability checker // SPF and DMARC generator // Lead list building // Benchmarks