Fake-but-Valid Email Domains: the Spam Trap Bounce Validation Can't See

Your “valid” leads aren’t all real. Some of the fake ones will pass every validation check you have — and the reason is a blind spot built into how most email validation works.

This one started in the BDR queue and ended with a lesson about where to gate junk, plus a cautionary tale about the tempting wrong fix.

It started in the BDR queue

Leads with addresses like alex@example.com were syncing to the CRM, accumulating lead score, and landing on reps’ desks. Validation never flagged them. Nothing in the pipeline treated them as anything but healthy leads — reps were spending real time on addresses that were never going to answer.

The first question was the right one: how did @example.com get past email validation at all?

Bounce-based validation has a structural blind spot

Most marketing-automation email validation leans on bounce behavior. The platform flags an address as invalid when a send hard-bounces. No hard bounce, no flag — the address stays “valid” forever.

That heuristic works for typos and dead mailboxes, which hard-bounce reliably. It fails completely for a specific class of address: fake emails on real domains.

example.com and example.org are IANA-reserved test domains. They’re real, resolvable, permanently maintained — that’s their entire purpose. Mail to them is accepted or soft-bounces; it never hard-bounces. So the “Email Invalid” flag never flips, and a bounce-based filter is structurally blind to them. The spam wasn’t sneaking past the check — the check was never capable of catching it.

The tempting wrong fix

The junk had a second tell: the phone numbers used the reserved 555-01xx fake range (the one movies use). First instinct: block any phone containing 5550. It felt precise. It wasn’t.

Substring matching on phone numbers fails both directions:

• False positives — real numbers like (856) 374-5550 contain 5550 too. That rule quarantines legitimate leads
• False negatives — the junk itself often arrives formatted as (325) 555-0100, and the dash breaks a plain 5550 substring match. The rule misses its actual target

A filter that punishes real leads while missing fake ones is worse than no filter. If you must match phone patterns, you need normalization (strip everything but digits first) or a proper regex — never raw substring contains. We dropped the phone rule entirely, from the validation campaign and from the router where a copy of it had spread.

The reliable signal was the domain

The domain was everything the phone number wasn’t: unambiguous, format-independent, with zero legitimate reason to appear in a lead record. Nobody’s real work email is @example.com.

The fix: block the fake domains at the validation gate —

email address  not contains  @example.com
email address  not contains  @example.org

No bounce dependency, no false positives, no formatting fragility. The full IANA-reserved family is worth covering while you’re there: example.net and .example variants cost nothing to add.

Gate it twice: defense in depth

One filter isn’t enough, because a single gate has a single failure mode — one edited campaign, one bypassed flow step, and junk is back in the pipeline. We gated twice:

1. At the validation campaign — before a lead becomes marketable. Junk never enters scoring or nurture
2. At the CRM-sync step — before routing can touch it. Even if something upstream changes, fake-domain leads can’t reach a rep’s queue

The second gate is the insurance policy. Marketing-automation instances drift — people clone campaigns, reorder flows, add exceptions. The sync gate means the blind spot can reopen upstream without junk reaching sales.

The checklist version

For your next data-quality audit:

• Assume bounce-based validation misses soft-bouncing domains — it’s structural, not a configuration error
• Search your database for @example.com, @example.org, and friends — if they’re in there, they’ve been “valid” the whole time
• Never substring-match phone numbers — normalize first or use regex; check whether a fragile phone rule already lives in your router
• Gate junk at two points minimum — before marketable, and before CRM sync
• Audit downstream copies of old rules — the wrong fix propagates just like the right one

Bounce validation answers “does this mailbox reject mail?” It was never designed to answer “is this a real person?” The gap between those two questions is exactly where this spam lived.