Email verification accuracy explained: what "99% accurate" really means
· 4 min read · Email validation
Email verification accuracy is the share of addresses where the verifier's verdict matches what actually happens when you send. The catch is the denominator. Most "99% accurate" claims are measured on addresses the verifier could decide, so catch-all domains and servers that won't answer are either excluded or labelled "risky" and "unknown", outside the score. The useful questions are how many of your addresses get a definite answer, and how often that answer is right.
What verifiers can and can't know
An email verifier checks syntax, looks up the domain's mail servers, and opens an SMTP conversation to ask whether the server will accept a given recipient. It hangs up before sending anything. That gives it a clear answer in two cases:
- The server rejects the recipient with a "no such user" response. The address is
invalid. - The server accepts the recipient and rejects a random address on the same domain. The address very likely exists:
valid.
Everything else is inference:
- Catch-all domains accept every recipient, real or not. The server's "yes" carries no information. See catch-all email domains.
- Accept-then-bounce providers say yes during the conversation and send a bounce later. RFC 5321 allows a server to accept a recipient and fail delivery afterwards. Yahoo behaves this way, and so do some corporate mail gateways.
- Greylisting answers with a temporary failure to unknown senders on purpose. Details in greylisting and email verification.
- Blocks and rate limits. Big providers throttle or refuse connections from IPs that look like probers.
None of these can be fixed by a cleverer algorithm. The server hasn't told anyone the answer.
How to read an accuracy claim
Vendors advertise high numbers. ZeroBounce's home page says 99.6% accuracy, and MillionVerifier's says 99%+. Neither page we read explains how catch-all or unknown results are counted in that figure. That's common, and it isn't necessarily dishonest: if you measure only the addresses a verifier labelled valid or invalid, a well-run SMTP check should be right almost all the time.
Ask three things of any claim (ours included):
- What's in the denominator? All addresses submitted, or only the ones with a definite verdict?
- What's the unknown and catch-all rate on a list like mine? A verifier that labels 30% of a B2B list "accept-all" and is right on the other 70% may be more useful than one that labels everything valid or invalid and is wrong on a chunk of it.
- How was "right" measured? Against real sends and bounces, or against the vendor's own previous results?
We look at both vendors in more detail on our ZeroBounce and MillionVerifier comparison pages.
Why pingutil returns risky and unknown instead of guessing
pingutil's /v1/verify has four statuses. valid means the server confirmed the mailbox and rejected a random one. invalid means mail won't reach anyone. Catch-all and accept-everything providers come back risky with reason accept_all, never valid. Greylisting, blocks, rate limits and timeouts come back unknown. The full table is in the status reference.
That design means you'll see more risky and unknown results than a verifier that guesses. We think that's the honest trade-off: a wrong valid costs you a bounce and some reputation, while an unknown costs you a decision you'd have to make anyway.
There's also a score (0 to 100) that orders results within a status. It's our estimate of how likely a message would reach a person, not a probability you can multiply by your list size.
Measure accuracy on your own list
Don't trust anyone's number, ours included. Build a small labelled set and run it through each verifier you're considering:
- Known good: 20 or so addresses you know exist. Your own team, customers who replied last week.
- Known bad: random local parts on the same domains (
zz-not-real-4821@yourcompany.com). On domains that aren't catch-all these should come back invalid. - Known catch-all: a few domains you know accept everything. These should come back risky or accept-all, not valid.
- Real bounces: addresses that hard-bounced in a recent campaign.
Then score each verifier on:
| Metric | How to compute |
|---|---|
| Decided rate | (valid + invalid) / total |
| Accuracy on decided | correct valid + correct invalid, divided by decided |
| False valid rate | known-bad or bounced addresses labelled valid |
| False invalid rate | known-good addresses labelled invalid |
The false valid rate is the number that hurts deliverability. The false invalid rate is the one that costs you real leads. A single "accuracy" number hides both.
For a quick check without code, run a handful of your labelled addresses through the email verification demo. For a full test, POST /v1/verify/batch takes 50 addresses per request.
The only definitive test
A delivered message that someone acts on (a confirmation click, a reply) is the only proof an address reaches a person. Verification is the cheap filter in front of that. Use it to remove what's clearly dead, flag what's uncertain, and let real sends and engagement settle the rest.
Questions people ask
- How accurate is email verification?
- For addresses where the mail server gives a clear answer, verification is usually right, because the server itself said yes or no. Accuracy drops on catch-all domains, providers that accept every address and bounce later, and servers that refuse to answer. A good verifier reports those as risky or unknown instead of guessing.
- Why does my verifier return so many unknown or catch-all results?
- Because the list has many addresses on domains that don't reveal whether a mailbox exists. B2B lists in particular contain lots of catch-all company domains. A verifier that returns fewer unknowns isn't necessarily more accurate; it may be guessing where others admit uncertainty.