# Fake-but-Valid Email Domains: the Spam Trap Bounce Validation Can't See > Junk leads with addresses like alex@example.com passed email validation, synced to the CRM, and reached reps. Why bounce-based validation is blind to IANA-reserved domains, why the obvious phone-number fix backfires, and the two-gate fix that works. By Wajahat Mubashir, Marketing Technology Engineer · 2026-06-26 Canonical: https://wajahatmubashir.netlify.app/blog/fake-but-valid-email-domains/ --- 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 — ```text 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.