How email verification actually works
Modern verification is a three-step handshake, and the first two steps are trivial. Syntax: is the address shaped like an email address. MX lookup: does the domain have mail servers at all. Anything can pass these. The real test is the third step.
The SMTP probe: the verifier connects to the domain's mail server and begins the delivery conversation, names the address as the recipient, reads the server's answer, then hangs up before sending anything. If the server says the mailbox exists, the address is marked valid.
When the server gives a straight answer, this genuinely works. The problem is how often the server does not.
The three blind spots
Catch-all domains. A significant share of business domains accept mail for any address whatsoever. Probe them with a real address, they say yes. Probe them with an address you invented seconds ago, they also say yes. Verification against a catch-all domain proves nothing about whether the mailbox exists. Honest verifiers label these separately. Dishonest pipelines count them as wins.
Servers that will not play. Large mail providers answer probes ambiguously or not at all, and many mail servers block or throttle verification traffic outright, especially from data-center IP addresses. These come back "unknown," and what a vendor does with unknowns decides how honest their headline number is.
The wrong-mailbox problem. This is the blind spot no verifier can fix. An address can be perfectly deliverable and still wrong: a shared inbox, an alias, a former employee's account that forwards to nobody. Deliverable and correct are different properties, and SMTP can only ever test the first one.
The survivorship math
Now put the pieces together with the way some tools construct addresses in the first place. The pipeline looks like this: find a name, take the domain, generate likely patterns, and probe each one until the server accepts something.
Then the accuracy number is computed over the addresses that survived. Not over the guesses that failed. Not over the catch-all domains where acceptance was meaningless. Not over the ambiguous unknowns. Not over the businesses where no address was found at all. The denominator has been quietly curated before the percentage was calculated.
"A 95% badge produced this way can be technically true and still tell you almost nothing about what fraction of your search results carries a contact you can trust."
That fraction, the honest one, is never on the landing page. If you want a practical checklist for probing a vendor on exactly this, we wrote one: 8 questions that expose weak data.
The question that beats every percentage
Provenance. Where did this address come from?
An email published by the business itself, on its own website, is a different object from an email an algorithm constructed and a mail server merely failed to reject. The first one is the business telling the world how to reach it. The second is a statistical guess wearing a verified badge.
Our position is simple: every email we deliver comes from the company's own website. We never pattern-guess an address, and when we cannot find one, the field says so honestly rather than filling itself with a plausible construction. We publish our entire data dictionary, including where every field comes from, so you can audit that claim rather than trust it.
And when we verify, we do it properly: through professional third-party verification infrastructure, not a homegrown prober. Catch-all domains are labeled catch-all, unknowns are labeled unknown, and we do not publish accuracy percentages we have not measured on our own pipeline. If that costs us a shinier badge than our competitors wear, we are comfortable with the trade.
Where verification actually belongs
None of this makes verification useless. It makes it a hygiene layer, not a source of truth.
Used honestly, verification is genuinely valuable: it catches dead mailboxes and defunct domains before they hurt your sender reputation, and flagging catch-all domains tells you where to lower your confidence. Running a verification pass before any large send is simply good practice, whoever your data comes from.
Just keep the roles straight. Verification can tell you an address probably will not bounce. It cannot tell you the address was ever real in the first place. Only provenance can do that, and provenance is decided at the moment the data is collected, long before any badge is printed on it.
That is exactly how verification is built into Lyre Leads: a hygiene layer with honest labels, sitting on top of provenance, not standing in for it. So the next time a tool leads with an accuracy percentage, ask the two questions that expose the whole machine: measured over what denominator, and constructed or found?
Provenance First, Verification on Top
Emails found on the business's own website, never guessed, with SMTP deliverability status labeled honestly on every check. See it on real leads in any niche and city. Free plan includes 500 tokens.
Start free, no credit card required
Lyre Leads