How to Tell If Your Email Verifier Is Lying to You

Email verification has an unusual problem: you cannot easily tell whether it worked.

If a verifier tells you an address is valid and you send to it, you find out weeks later from your bounce rate. By then the damage — sender reputation, deliverability, a burnt domain — is already done. Every tool in the category advertises "99% accuracy", and almost nobody checks.

Here is a test that takes about a minute, and what we found when we ran it on our own product.

The test

Invent an address that cannot possibly exist, at a provider you know rejects unknown mailboxes:

definitely-not-real-xyz9987661@gmail.com

Gmail rejects unknown recipients at the SMTP layer with a 550 response. This is not a guess about Gmail's behaviour — it is observable, and it is the entire mechanism verification is built on.

So there is exactly one correct answer: invalid.

Submit that address to your verifier. If it comes back valid, the tool did not check the mailbox. It looked at the domain, saw gmail.com, and assumed.

We failed our own test

We built this product. When we ran that address through our own engine, it returned:

definitely-not-real-xyz9987661@gmail.com  →  valid  ("Verified")

Not "risky". Not "unknown". Verified.

Two things in our own code caused it, and both are worth understanding because they are easy mistakes to make.

The provider shortcut. The engine held a list of major providers — Gmail, Yahoo, Outlook, iCloud and so on — and returned valid for any correctly formatted address at one of them, without ever opening an SMTP connection. The reasoning was that these domains definitely accept mail. That is true of the domain and says nothing about the mailbox. On a typical consumer list, that single shortcut rubber-stamps a large share of every file you upload.

The failure fallback. When the SMTP check did run and failed for any reason — timeout, blocked port, connection refused — the code fell through to a default of valid, on the logic that valid syntax plus a valid mail server probably means a real address.

That second one matters more than it looks, because of where verification usually runs.

Most cloud hosts block the port verification needs

Checking a mailbox means connecting to the recipient's mail server on port 25. Almost every major cloud provider blocks outbound port 25 by default to stop spam. We measured it on two:

Host	Outbound port 25
Railway	Blocked
DigitalOcean	Blocked

Put those two facts together. If a verifier runs on infrastructure that blocks port 25, and its code defaults to valid when the SMTP check fails, then every address on a live domain comes back valid — and the tool has verified nothing at all while reporting total confidence.

That is not a hypothetical failure mode. It is what our own code did until we fixed it.

What honest output looks like

The fix is not cleverer probing. It is being willing to say "I don't know."

A verifier should return three states, and the middle one is the important one:

• valid — a mail server confirmed this mailbox exists
• invalid — a mail server rejected it, the domain has no mail server, the syntax is broken, or it is a disposable address
• risky — the check could not be completed

Risky is the honest answer for genuinely ambiguous cases, and there are several:

Catch-all domains accept every address at the domain, real or not, so anything@theirdomain.com returns acceptance. Verification cannot distinguish a real mailbox from a typo there. Any tool reporting valid on a catch-all domain is reporting the domain's configuration, not the mailbox.

Providers that hide mailbox status. Some large consumer providers, Yahoo and iCloud among them, decline to give a clear answer for unknown recipients at the RCPT stage, so a probe against them is often inconclusive. Microsoft is not in this group: both Outlook.com and Microsoft 365 reject unknown recipients during the SMTP conversation.

Blocked or refused connections, as above.

Our engine now returns invalid for that fabricated Gmail address, with the reason Mailbox not found. Anything it cannot confirm goes to risky, and never to valid.

How to test the one you use

Build a small file with addresses whose answers you already know:

1. A fabricated address at gmail.com — must be invalid
2. Your own real address — must be valid
3. Something with no @ — must be invalid
4. An address at a disposable domain like mailinator.com — should be invalid
5. An address at a domain with no mail server at all — must be invalid
6. A role address like info@ at a real company — should be flagged risky or role-based

Six rows. Any verifier worth paying for gets all six right, and the first one is the one that catches guessing.

If your provider returns valid on row 1, you are not buying verification. You are buying a syntax checker with a confident tone — and you will find out the difference from your bounce rate.

Why we published this

It would have been easy to fix the bug quietly. We wrote it up because the test is more useful than the claim: you should not take our word for our accuracy any more than anyone else's.

Run the six rows against us. Run them against whoever you use now. The results will tell you more than any accuracy percentage on a pricing page.