Email verification is very accurate for some results and only an educated guess for others. When a verifier says an address is invalid because the domain doesn’t exist, has no mail servers, or publishes a null MX, that verdict is essentially certain. When it says a mailbox is “valid” based on an SMTP check, it’s reporting what one server said at one moment, and catch-all domains, greylisting, and accept-then-bounce servers can make that answer wrong. The useful question isn’t “how accurate is this tool?” but “how accurate is this kind of result?”

This guide explains where verification errors come from, how to read headline accuracy claims, and how to test any verifier against your own data.

What “accuracy” means for email verification

A verifier sorts addresses into buckets, usually some version of valid, invalid, risky, and unknown. There are two ways it can be wrong:

False positive (a bad address marked valid). You send to it, and it bounces. This hurts your bounce rate and sender reputation.
False negative (a good address marked invalid). You drop a real customer or lead. This costs you revenue and, on a signup form, can block a real person.

Most tools are tuned to avoid one kind of error at the expense of the other. Twilio SendGrid, for example, says in its real-time validation documentation that its results are calibrated to produce few false negatives, so real addresses are rarely marked invalid. That’s a reasonable design choice for a signup form, where blocking a real customer is costly. It also means some risky addresses will come back as valid or risky rather than invalid.

There’s also a third outcome that a single accuracy percentage hides: unknown. A tool that labels every hard case “unknown” can look very accurate on the addresses it did classify. Always ask what share of your list ended up in the unknown or catch-all bucket.

Which checks are certain and which are estimates

Not all checks are equally reliable. Here’s how they compare:

Check	How reliable	Why
Syntax and length	Certain	It’s a string rule. An address with two `@` signs can’t be delivered.
Domain doesn’t exist (`NXDOMAIN`)	Near certain	DNS says the domain isn’t there. Rare exception: a temporary DNS outage.
Null MX	Certain	The domain explicitly says it accepts no mail, per RFC 7505.
Has MX records	Reliable for the domain	Proves the domain can receive mail, not that the mailbox exists.
Disposable domain	Reliable when listed	Depends on list coverage; brand-new disposable domains slip through.
Role-based	Reliable as a label	`info@` is role-based by definition; whether it’s risky depends on your use case.
Typo suggestion	Usually right, sometimes not	`gmial.com` is almost always a typo, but a few near-miss domains are real.
SMTP `550 5.1.1`	Strong	The server said the mailbox doesn’t exist. RFC 3463 defines `5.1.1` as “bad destination mailbox address.”
SMTP `250` on `RCPT TO`	Weak to moderate	Catch-all and accept-then-bounce servers say yes to everything.
SMTP `4xx`	Inconclusive	Temporary by definition. Could be greylisting, rate limiting, or a full mailbox.

The pattern: negative results from DNS are the most trustworthy thing a verifier produces. Positive mailbox-level results are the least.

Why mailbox-level results go wrong

Catch-all domains

A catch-all (or accept-all) domain accepts mail for any address at the SMTP stage. jane@, j.doe@, and zzz-not-real@ all get a 250. The server routes or discards the message later. Many business domains are configured this way, so a verifier can only honestly report “accept-all” or “unknown” for those addresses. See how to handle catch-all domains.

Greylisting and temporary failures

Greylisting is a deliberate anti-spam technique. RFC 6647 describes servers that return a temporary 421 or 450 reply to unfamiliar senders, expecting real mail servers to retry. The RFC suggests a default retry window of one minute to 24 hours. A verifier that checks once and moves on will see a temporary failure and has to call the result unknown.

Servers that won’t say

RFC 5321 lets administrators disable the VRFY command. When a server can’t verify a user but will still accept mail, the standard reply is 252, “cannot VRFY user, but will accept message and attempt delivery.” Many servers also give generic answers at RCPT TO to avoid helping address harvesters.

Accept now, bounce later

Some mail systems accept every recipient during the SMTP session and only check the directory afterward. The bounce arrives as a separate message minutes or hours later. The M3AAWG Sender Best Common Practices notes that most rejections happen synchronously during the SMTP conversation, but asynchronous bounces do happen, and B2B mail may see more of them.

Time

Verification is a snapshot. A mailbox that exists today can be deleted next week when someone leaves a job. If you verify a list in January and send in June, some of those “valid” results are stale. That’s an argument for verifying close to send time; see how often to verify your email list.

Spam traps

Recycled spam traps are former real addresses that a mailbox provider has turned into traps. They can accept mail normally, so a verifier usually can’t distinguish them from a real inbox. Avoiding them comes down to how you collect addresses and how you handle inactive subscribers. Our post on spam traps explains the two main kinds.

How to read accuracy claims

You’ll see verification services advertise a single accuracy percentage. Before you rely on one, ask:

Accuracy on what? Measured against which addresses, from which industries, at what date?
How are unknowns and catch-alls counted? Excluding them makes any number look better.
Is it measured by bounces? The most meaningful test is: of addresses marked valid, what share bounced when actually mailed?
Is there a guarantee, and what does it cover? Some vendors offer credits if valid-marked addresses bounce above a threshold. Read the terms.

A vendor that clearly explains its methodology and admits what it can’t determine is usually more trustworthy than one with a bigger number.

How to test a verifier on your own data

You can measure accuracy for your own list in an afternoon. You don’t need a lab, just addresses whose real status you already know.

Build a known-good sample. Pull a few hundred addresses that clearly work: customers who made a purchase or clicked an email in the last 30 days.
Build a known-bad sample. Pull addresses that hard-bounced with 5.1.1 or “user unknown” in recent sends. Your sending platform’s bounce logs or suppression list will have these. Don’t send to them again; you’re only running them through the verifier.
Run both samples through the tool. Record each verdict.
Score it.
- Of the known-good addresses, how many were marked invalid? Those are false negatives.
- Of the known-bad addresses, how many were marked valid? Those are false positives.
- How many of each landed in unknown, risky, or catch-all?
Repeat with a second tool if you’re comparing vendors, using the same samples.

This gives you numbers that reflect your audience. A B2B list full of corporate catch-all domains will score very differently from a consumer list dominated by big webmail providers.

Measure accuracy where it counts: your bounce rate

The ultimate test of any verification process is what happens when you send. Track hard-bounce rate on the first campaign after verification.

That number matters because platforms enforce limits on it. Amazon SES, for instance, recommends keeping your bounce rate below 5%, reviews accounts at 5% or more, and may pause sending at 10% or more. SES counts only hard bounces toward that rate, so it’s measuring exactly what verification is supposed to prevent.

If your post-verification bounce rate is still high, look at:

Unknown and catch-all addresses you decided to send to. Send to those in smaller batches, or after the rest.
Time between verification and send. Re-verify if it’s been months.
Bounce reasons. If bounces are 5.7.x policy rejections, the problem is your reputation or authentication, not the list. Our guide on bounce classification helps sort these out, and why emails still bounce after verification covers the common causes.

What our free tool is accurate about

Our free email verifier sticks to the checks that are deterministic or close to it: syntax, domain existence, MX and null MX records, disposable domains, role-based addresses, free-provider detection, and common domain typos. It does not attempt an SMTP connection to the mailbox, so it never reports that a specific inbox exists. When it says an address is invalid because the domain can’t receive mail, you can trust that. When it says an address looks fine, it means the address passed every DNS-level check, not that the mailbox is guaranteed to be live.

FAQ

Can any email verifier be 100% accurate?

No. Some answers aren’t knowable from outside the receiving organization. Catch-all domains, greylisting, and servers that accept first and bounce later all make mailbox-level results uncertain. The only certain proof is a confirmation email the recipient acts on.

Why do verifiers disagree about the same address?

They run different checks, at different times, from different IP addresses. A server might greylist one verifier and accept another, or a catch-all domain might be reported as “valid” by one tool and “accept-all” by another. Disagreement usually points to an address in the uncertain middle.

Should I send to addresses marked “unknown”?

Send to them carefully, if at all. Mail them separately from your verified segment and in smaller batches, then suppress whatever hard-bounces. If you’re on a new domain or close to your platform’s bounce limits, leave them out until your reputation can absorb a few bounces.

Is an invalid result ever wrong?

It can be, though rarely for DNS-based results. A temporary DNS outage can make a real domain look missing, and an SMTP check can misread a policy block as a missing mailbox. If a high-value address comes back invalid, re-check it later or ask the person directly.

How Accurate Is Email Verification? What the Results Really Mean