Email Verification, Explained Properly

Every lead tool advertises "verified emails" and almost none of them explain what that means. The word covers at least four different checks of wildly different strength, and knowing which one you are getting is the difference between a 1% bounce rate and a suspended sending domain.

Here is the whole mechanism, including the parts that are genuinely uncertain.

Why bouncing matters more than it used to#

A bounce is not a wasted email. It is a signal to the receiving mail provider that you do not know who you are writing to.

Gmail, Outlook and every serious provider score senders on reputation, and invalid-recipient rate is one of the loudest inputs. Legitimate senders write to addresses that exist, because they got them from people who gave them. Senders working from purchased or badly-collected lists write to addresses that do not, because nobody checked.

Cross the threshold — commonly cited around 5%, and you want to be nowhere near it — and the penalty is not a bounce warning. It is your mail going to spam for everyone, including the recipients whose addresses were fine. Recovering takes weeks.

So verification is not a data-cleanliness nicety. It is the thing standing between you and losing your sending domain.

Level 1: syntax#

The cheapest check, and the one everyone does.

Is the address structurally valid — one @, a plausible local part, a domain with a real top-level domain? Is the domain a typo of a common one (gmial.com, hotmial.com, outlok.com)? Is the local part obviously a placeholder — example@, youremail@, test@?

This catches transcription errors and scraper noise. It catches nothing about whether the mailbox exists. An address can be perfectly formed and belong to nobody.

What it removes: malformed addresses, obvious typos, placeholder text that pattern-matched as an email.

Level 2: the MX record#

A domain that receives email publishes an MX record in DNS naming the servers that accept it. No MX record means no mail server means the address cannot possibly work.

This is a fast, free, definitive check that eliminates a surprising share of a scraped list: parked domains, expired domains, sites that use a domain only for hosting, and the long tail of businesses whose domain registration lapsed two years ago while the site stayed cached.

It also identifies who actually runs the mail. An MX pointing at google.com or outlook.com tells you the mailbox is behind Gmail or Microsoft — useful, because those two behave very differently from a small self-hosted server when you probe them.

What it removes: domains that cannot receive mail at all. What it cannot tell you: whether the specific mailbox exists.

Level 3: the SMTP probe#

This is where real verification happens, and where the honest complexity is.

The verifier opens a connection to the domain's mail server and begins the conversation an actual delivery would begin — identifying itself, naming a sender, and then naming the recipient with an RCPT TO command. The server answers whether it would accept mail for that address.

Then the verifier stops. No message body is ever sent, so nothing arrives in anyone's inbox.

A cooperative server answers clearly: 250 means it would accept, 550 means no such user. That is a definitive valid or invalid.

Plenty of servers are not cooperative, and that is not a bug in the verifier.

Why "risky" exists#

Three situations produce a genuinely unknowable answer:

Catch-all domains. The server is configured to accept mail for every address at the domain and sort it out later. Ask about nonsense-string-9284@theirdomain.com and it says yes. Ask about the real address and it also says yes. The answer carries no information. A large share of small-business domains are configured this way, often without the owner knowing.

Greylisting. The server deliberately defers unfamiliar senders with a temporary error, expecting a legitimate sender to retry later. A probe gets the deferral and no answer.

Anti-verification measures. Some providers accept every RCPT TO specifically to defeat address harvesting, then bounce the message afterwards. Microsoft-hosted domains are notably inconsistent here.

Any verifier that reports these as "valid" is inflating its numbers. Any verifier that reports them as "invalid" is throwing away real customers. The correct answer is risky, and what you do with that category is a business decision, not a technical one.

What to actually do with each bucket#

Result	What it means	What to do
Valid	The server confirmed the mailbox	Send
Risky	Catch-all, greylisted, or the server refuses to say	Send separately, from a secondary domain, in small batches
Invalid	The server said no such user, or the domain has no MX	Delete, never retry
Disposable	A throwaway-mailbox provider	Delete
Role	info@, sales@, contact@ — real, but shared	Send, with copy written for a shared inbox

The one rule with no exceptions: never send to invalid. Everything else is a judgement about risk tolerance.

Segmenting risky addresses onto a separate sending domain is the trick that makes them usable. If a batch of catch-all domains turns out badly, the damage is contained on a domain you can afford to retire.

What verification cannot do#

It cannot tell you the person still works there. An address can be live and forwarded to a colleague for years after someone left. This is the single largest source of "verified" addresses that produce no reply.

It cannot tell you the inbox is monitored. Plenty of info@ addresses at small businesses accept mail into a folder nobody has opened since 2019.

It cannot make an address exist. If a business publishes only a contact form, there is no address to verify. No amount of tooling changes that, and a tool that returns a guessed firstname@company.com is manufacturing data, not finding it.

It is a snapshot. A result is true at the moment it was checked. Verify close to sending, not months in advance.

Roughly what a real list looks like#

Starting from businesses found on a public source, a realistic funnel:

• Some fraction have no website at all — no path to an email exists.
• Of those with a website, most publish an address somewhere, but a meaningful share publish only a form.
• Of the addresses found, syntax and MX checks remove the dead domains and the noise.
• Of what remains, the SMTP probe splits it into valid, risky and invalid.

End to end, a contactable, verified address for roughly one third to two thirds of the businesses a search finds is a normal outcome, and the range depends heavily on industry and country. German businesses are near the top, because an imprint page is a legal requirement. Sectors that live on Instagram are near the bottom, because the profile is the website and there is no contact page to read.

Anyone quoting you a much higher number is either guessing addresses or counting the ones they cannot verify.

How this fits the rest of the process#

Verification sits between collection and sending, and it cannot rescue mistakes made on either side. A list of the wrong businesses verifies perfectly and still earns no replies; a perfect list sent from an unauthenticated domain lands in spam regardless.

For where the addresses come from in the first place, see the B2B lead generation guide. For what happens after verification — SPF, DKIM, DMARC, warm-up and volume — see the cold email deliverability guide.

FAQ#

Does verifying an address send an email to it?#

No. The SMTP probe stops after the recipient is named and before any message data is transmitted. Nothing is delivered and nothing appears in the recipient's mailbox. Server logs may record the connection, which is why the probe identifies itself honestly rather than pretending to be something else.

What is a catch-all domain?#

A domain configured to accept mail sent to any address at it, rather than only to mailboxes that exist. Because it says yes to everything, a probe cannot distinguish a real mailbox from an invented one. Addresses at catch-all domains are reported as risky — they are frequently deliverable, but nobody can confirm it in advance.

Is a 5% bounce rate bad?#

Yes. Treat 5% as the line where mailbox providers start acting on it, not as a target. A properly verified list should bounce under 2%, and consistently above that means something upstream is wrong — usually a stale list or addresses that were guessed rather than found.

Should I send to role addresses like info@?#

Yes, but as their own segment with its own copy. At a small business a role address is often read by the owner; at a larger one it is a queue. Write to it as a shared inbox — state plainly who you are trying to reach and why — rather than opening with a first name that belongs to nobody.

How long do verification results stay accurate?#

Treat them as fresh for a few weeks and stale after about three months. Business email changes constantly: domains lapse, providers migrate, staff leave. Re-verifying immediately before a send costs very little and is the cheapest insurance available on a sending domain.