What a verified email list actually verifies

Nine out of ten business domains sit behind a mail provider that refuses to confirm whether a mailbox exists. Here is what the verification industry is measuring instead, and what the badge on your list means.

Every list vendor sells you a green tick. We audited our own prospect book this month and found what the tick can and cannot mean. The short version is that for most business domains, nobody can confirm a mailbox exists, including the people charging you for confirmation.

How mailbox verification is supposed to work

There is one real method. You open an SMTP conversation with the domain's mail server and get as far as naming the recipient without sending anything:

MAIL FROM:<probe@example.com>
RCPT TO:<jane.doe@theircompany.com>

A compliant server answers 250 OK if the mailbox exists and 550 5.1.1 if it does not. You hang up before DATA, so no mail is sent and nobody is disturbed. That is the whole trick, and when it works it is genuinely definitive.

Why it does not work any more

Two things broke it.

Port 25 is closed on most infrastructure. Every major cloud provider blocks outbound port 25 by default to stop their address space being used for spam. If you have not explicitly arranged otherwise, your verification attempts are refused by your own network before they reach anyone. The failure looks exactly like "no such mailbox", which means an infrastructure problem quietly becomes a data point about someone else's company.

The large providers refuse to answer. Google Workspace and Microsoft 365 reject recipient probes from unknown senders regardless of whether the mailbox exists. They are not being obstructive, they are closing an enumeration hole: a server that answers honestly hands an attacker the company's entire staff directory one guess at a time.

We measured this on a live book of 179 companies. Thirty-six of the first forty we sampled sat on Google Workspace or Microsoft 365. Ninety percent of a real business list cannot be verified by the only method that verifies anything.

So what is being sold

Three things, in descending order of honesty.

A syntax and domain check. The address is well formed and the domain publishes an MX record. This is real information and it is worth having. It is also not what most people mean by "verified", and it catches typos rather than nonexistent people.

A catch-all detection. Many domains accept mail to every address and sort it later. On those, an accept proves nothing at all, because not-a-real-person@theircompany.com also accepts. A vendor that reports these as valid is reporting the server's politeness as a fact about a person.

Accumulated observation. The larger providers have seen the same address bounce or not bounce across many customers' campaigns. This is genuinely useful and it is the only thing that works on Google Workspace. It is also why the good vendors are expensive and the cheap ones are not: you are paying for a corpus, not for a check.

What we do instead, and what we mark

We publish addresses in three states rather than two, because the middle one is where the risk lives.

Observed. Somebody published this address. It appears on the company's own site, in a filing, or in a press page. It may never have been probed, and on a Google Workspace domain it never can be, but a human wrote it down and meant it.

Confirmed. The mail server accepted the recipient. Available on roughly one domain in ten, and definitive when it is.

Constructed. We knew a person's name and the company's domain and we built the address from a pattern. jane.doe@company.com looks identical whether a human published it or software inferred it, and the difference is invisible in the string. So it travels marked, it is barred from the list of confirmed addresses, and our own pipeline ranks it below a published shared inbox on the grounds that a bounce costs more than a slower path to the right person.

Why the third state matters more than it sounds

A constructed address that is wrong does not fail quietly. It bounces against a real company's mail server, and your sending domain absorbs the cost. Bounce rate is the single loudest signal in deliverability. A campaign that guesses at scale is buying a small number of correct addresses with the reputation of the domain that everything else you send depends on.

This is why the "verified" badge is worth interrogating rather than trusting. The question to ask a vendor is not "is it verified", it is "which of the three did you do, and on what share of the list". A vendor with a real corpus will answer. A vendor running syntax checks will talk about their accuracy percentage instead.

What to do with a list you already have

Sort it before you send to it, not after.

1. Separate personal addresses from shared inboxes. support@ and hello@ are not the same channel as a named person and should not receive the same message. A shared tray is read by a rota, so an opener addressed to one person reads as a mistake to whoever opens it.
2. Ask where each address came from. If the vendor cannot say, treat the whole file as constructed.
3. Send to the confirmed and observed addresses first, at low volume, and watch the bounce rate before you touch anything constructed.
4. Keep the constructed ones. They are useful. They are just not the batch you use to learn whether your sequence works.

The list is not the problem. Not knowing which third of it you are holding is.

See how RevFlowLab eliminates AI copy drift.

Persistent brand memory. Self-correcting generation. Built for DTC operators who can't afford generic copy.

Related Articles