A verified email should mean a mail server was asked whether the mailbox exists and answered yes. It is different from a pattern-guessed address, which is assembled from a name and a domain and has never been tested against anything. Both arrive in the same field, as the same string, and only one of them has been checked.
The three things sold under one word
Pattern-guessed. The provider knows the company uses first.last@, has a name, and concatenates. No contact with the receiving server. This is cheap, fast, and right often enough to look useful, which is exactly what makes it dangerous.
Cataloged. The address exists in a database because it was collected at some point: a contributor network, a form, a public source, a purchased file. It was real when it was collected. That may have been three years ago and the person may have left in 2024.
Verified. A live check against the receiving mail server at or near the time you asked. The domain accepts mail, the mailbox exists, the server said so.
The gap between these is the difference between a working outbound motion and a sender reputation problem, and vendors use one word for all three.
Why the distinction costs real money
Two costs, and the visible one is smaller.
The visible cost is the credit you spent on an address that does not work. Annoying, budgetable, and self-correcting because you notice.
The invisible cost is your sending reputation. Mailbox providers track how much undeliverable mail a domain produces. Push enough of it and placement degrades for everything you send afterwards, including to correct addresses at accounts that were going to reply. That damage lands on messages you have not written yet, takes weeks to recover from, and shows up in your metrics as a mysterious drop in reply rate rather than as a data-quality problem. Nobody attributes it to the enrichment vendor, which is part of why the practice persists.
Where verification genuinely cannot help
Being fair to the vendors: verification has a hard limit, and it is called a catch-all.
A catch-all domain accepts mail addressed to anything at that domain rather than rejecting unknown mailboxes. Ask whether notarealperson@example.com exists and the server says yes, because it says yes to everything. Verification returns a positive for an address that does not exist.
Catch-alls are common at larger companies and at anyone running a particular class of mail gateway. There is no way around it from the outside. The question is what the vendor does about it:
- Good: the record distinguishes verified, unverified and catch-all as separate states, so you can decide what risk to take.
- Bad: catch-all results are returned as verified, because the check technically returned a positive and the boolean has nowhere else to go.
A vendor that has never mentioned catch-alls to you either has not thought about it or would rather the conversation did not start.
How to test what you are buying
Four questions. They take a minute and they are more informative than any accuracy percentage.
- Did a mail server answer, or did a pattern match? The only question that matters. Everything else is elaboration.
- What do you return for a catch-all domain? If the answer is "verified", you now know how the headline accuracy number was achieved.
- When was the check performed? At request time, or at collection time and cached? Cached verification is cataloged data wearing a better word.
- What is the accuracy in my segment? Not overall. Your geography, your company size band, your seniority. An average is the statistic designed to hide the segment where it fails.
Why accuracy percentages are close to meaningless
A published accuracy figure is an average across a whole database. Averages hide distributions, and B2B email accuracy has an extremely uneven one.
The easy part of any dataset is large US companies with predictable naming and public web presence. That is where the volume is, so that is what dominates the average. The hard part is small companies, non-US geographies, senior people with assistants, anyone at a company that rebranded, and catch-all domains.
If your ICP is the hard part, a vendor's 93% tells you about a segment you are not selling into. Two vendors quoting the same headline number can behave completely differently on your list, which is the practical argument for waterfall enrichment: different providers fail in different places.
What we do, and where it still falls short
enrich_lead returns a contact record with an explicit email_verified boolean rather than an implied one, so the question has an answer in a field instead of in a sales conversation.
Credits are charged only when a verified result comes back. A lookup that finds nothing, or finds only something unverifiable, charges you zero. We still pay the provider for those attempts, which is why attempts are metered separately from credits and both numbers are published on the fair use page.
The honest limits: we cannot solve catch-alls, because nobody can from outside the receiving server. Verification is a point-in-time check, so an address verified today can be dead next month when someone leaves. And we do not cover consumer email at all.
What to do with all this
Stop comparing accuracy percentages. Take fifty contacts from your actual ICP, run them through any vendor you are evaluating, and send to them. The bounce rate on your own segment is the only number that describes what you are buying, and it costs you one afternoon and fifty sends to obtain.
Related reading
- The bounce tax on what per-attempt pricing costs at real match rates.
- Waterfall enrichment on why one provider is never enough.
- Verified email for the short definition.