Why verified email lists still bounce

TRAP 01

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.

TRAP 02

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 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.

TRAP 03

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

TRAP 04

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.

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 measured bounce rate from 3.33% to 1.09% on the sends that followed.

TRAP 05

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. 87.7% of one campaign's bounces traced to those domains, not to the recipients.

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.

TRAP 06

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.

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.

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.