Notes
Arguments rather than announcements. Mostly about the gap between what this industry measures and what it publishes.
Building a signup form that rejects junk
Most bad addresses got in through a signup form that checked format only. Add an MX lookup first, suggest typo fixes, and never block on a timed-out check.
Credits that expire are a second price
Buy 100,000 credits on a twelve-month clock, use 60,000, and your real price per address is two-thirds higher than advertised. ZapBounce credits never expire.
DMARC for people who hate DNS
DMARC only works once SPF or DKIM passes for the domain in your From header. Align one, publish p=none, read reports for two weeks, then raise the policy.
Greylisting, and why it fools verifiers
Greylisting answers a first contact with a temporary 4xx and expects a retry, so a single-shot verifier calls a working mailbox invalid. A 4xx is no verdict.
How fast a list actually decays
Lists decay through job changes, closed ISP accounts and abandoned webmail, not on a calendar. Re-verify B2B data older than six months before a big send.
How Microsoft throttles everyone
Microsoft caps SMTP connections per IP and answers 421 4.7.500 under load, so one Outlook or Microsoft 365 address can return two results on the same day.
How SMTP verification actually works
SMTP verification checks syntax and MX, connects on port 25, sends RCPT TO, reads the response code, and closes before DATA. No email is ever sent.
How to audit a purchased list
Verifying a purchased list tells you which addresses exist. It says nothing about consent, pristine spam traps or legal exposure, which decide the risk.
How we are building our benchmark
We are publishing our benchmark method before any results exist: known send outcomes, coverage and accuracy reported together, and the cases where we lose.
Nobody can remove spam traps
A pristine spam trap accepts mail exactly like a real mailbox, so no verifier can detect or remove one. Consent and sunsetting are what protect you.
Reading an email header
An email header lists every server hop in reverse order, plus the receiver's SPF, DKIM and DMARC verdicts. Read Authentication-Results first.
Reading bounce codes properly
A 550 5.1.1 is a dead mailbox and a 550 5.7.1 is a policy block on you, yet both land in the hard bounce bucket. The text after the code is the diagnosis.
SPF flattening is a time bomb
SPF flattening swaps includes for hardcoded IPs to beat the ten-lookup limit, then breaks silently when a vendor changes ranges. Use a subdomain instead.
The 99% accuracy problem
Vendors reach 99% accuracy by leaving unknown and catch-all results out of the math. Hunter's 40,000-verification benchmark measured the field at 63% to 70%.
The case for publishing your limits
Every verifier claims the same 99% accuracy and spam trap removal, so checkable limits are what a careful buyer can evaluate. Here is why we publish ours.
The IP pool nobody mentions
Port 25 is blocked by most residential ISPs and restricted on new cloud accounts, so a verifier's coverage depends on the reputation of its probing IPs.
The two numbers every verifier hides
No verifier publishes its unresolved rate or its false positive rate. Run a few thousand of your own addresses through two vendors and count the unresolved.
What a catch-all domain really means
A catch-all domain answers 250 for every address, even an invented one, so no verifier can confirm the mailbox. Expect it on about a quarter of a B2B list.
What a dirty list actually costs
Mailing 8,000 dead addresses costs a few dollars. The real cost is a bounce rate that teaches Gmail and Microsoft to send your 92,000 good addresses to junk.
What deliverability tools cannot fix
Seed tests, DMARC monitors and blocklist alerts show where mail lands and why. Placement is decided by recipient behavior and sender history, not by a tool.
What February 2024 changed
Since February 2024, anyone sending over 5,000 messages a day to Gmail needs SPF, DKIM, DMARC, one-click unsubscribe and spam complaints under 0.3%.
What Gmail blocks, and why
Gmail rejects nonexistent addresses with a clear 550 5.1.1, but it refuses or tarpits probes from many cloud IP ranges. A 421 from Google means unknown.
What scale does to verification results
Verification coverage tracks the mailbox providers in a list more than the list's source. Consumer Gmail resolves well, and catch-all business domains do not.
What we cannot verify, and why
An SMTP probe shows only whether a mailbox accepts mail right now. Catch-all domains, Yahoo, pristine spam traps and engagement are all out of reach.
When not to verify
Skip verification on a recently confirmed list, a transactional sender that validates at signup, a list with a consent problem, or when engagement answers it.
Why a regex cannot validate an email address
A regex can confirm an address is well formed, not that the domain exists or the mailbox takes mail. Keep the pattern loose, then check MX records.
Why we do not bill for unknowns
Billing for results a verifier could not resolve pays it the same for failing. ZapBounce never charges for unknown results or duplicate rows.
Why we report coverage alongside accuracy
An accuracy figure covers only the addresses a verifier chose to judge, so guessing on hard ones raises it. Coverage and accuracy together cannot be gamed.
Why Yahoo says yes to everything
Yahoo answers 250 or 252 to every RCPT TO as an anti-harvesting policy and bounces bad addresses hours later. No verifier can confirm a Yahoo mailbox.
Why your verified list still bounced
A verified list still bounces because addresses die after the check, catch-all domains were never confirmable, and codes like 550 5.7.1 describe the sender.
Run a sample through it
100 free checks a month, no card, and the unknowns come back labeled.