About ZapBounce
We started from an irritation: every verifier advertises a number above 99%, and an independent test of the whole field measured 63% to 70%.
The short version
- Both sets of figures are arithmetically true. They count different denominators, and only one of them is printed on the pricing page.
- We report coverage next to accuracy, because either number alone can be improved by making the product worse.
- Unknown is a verdict here, not a footnote, and it is never billed.
- We have not published our own measured figures yet. Saying so is more useful than a number we cannot defend.
The number that started it
Hunter ran 40,000 verifications across the major services and published the results, including their own. The field scored between 63% and 70%. Every vendor in that test advertises something near 99%.
Nobody was lying. A vendor figure answers a narrow question: of the addresses we returned a verdict on, how many were right. It is calculated after the catch-all domains and the servers that refuse to answer have been removed from the denominator, and those are exactly the addresses that were hard.
The trouble is what the metric rewards. Resolve ambiguous addresses to valid rather than labeling them, and accuracy goes up while your bounce rate goes up too. The published number improves as the product gets worse.
So we report two
Coverage is the share of your list we reached a defensible verdict on. Accuracy is how often those verdicts held. Each one alone is gameable in opposite directions, and moving both at once is the only honest kind of progress.
The component that renders them will not accept one without the other. That sounds like a small engineering decision and it is the whole company.
Where the hard addresses live
The missing denominator isn't a rounding error. On one 10,000-address B2B benchmark, about 28% of the list sat on catch-all domains, which answer 250 to every address you ask about. Yahoo and AOL do the same on purpose, to stop anyone enumerating their users, and then bounce the bad ones later. Gmail and Microsoft 365 block probes that come from cloud IP ranges. A greylisting server returns a 4xx to every first attempt by design, so a verifier that asks once misreads it.
None of that is a bug. It's how receiving servers protect themselves, and no engineering gets a mailbox-level answer out of a server that won't give one. On domains that respond honestly, a careful SMTP check can be right somewhere between 95% and 98% of the time. That's the ceiling for everybody, and it only describes the addresses that could be judged in the first place.
What we put in writing
We run our own SMTP check over port 25. It isn't a wrapper around another company's verification API. We open the connection, ask the server about the address, and close before the DATA command, so no message is ever sent to the person you're checking.
Port 25 has a cost that marketing pages tend to skip. Most residential ISPs and many cloud providers block it, and the quality of a probe depends partly on the reputation of the IP it comes from. That's real infrastructure spend.
Some phrases will never appear on this site: 100% accurate, guaranteed inbox, spam trap removal. A pristine spam trap looks exactly like a working mailbox at the protocol level, so anyone promising to remove them is selling a probability. We may flag a likely recycled trap by heuristic, and when we do, it's labeled as a guess. The benchmark method is already published, written before the results exist, so the standard can't move to suit the numbers.
What we are not
Test the claim rather than believing it
A hundred free checks a month. Count what comes back unresolved.