Email Verification Accuracy: What 99% Measures and Why Trueguard Returns Unknown

No email verifier can prove that every mailbox exists, because many mail servers accept any address you send them. An honest result set therefore includes unknown. Trueguard, which publishes this guide, returns unknown instead of guessing, and its advanced catch-all detection can validate a mailbox on a catch-all domain that SMTP alone leaves unproven.

Almost every verification vendor publishes a figure near 99%. The figures are hard to compare, because the pages that state them do not say what was counted, and accuracy is a weak measure on imbalanced data. Google's machine learning course gives the standard warning: "a model that predicts negative 100% of the time would score 99% on accuracy, despite being useless."

What does "99% accuracy" measure on a vendor page?

On the pages read for this guide, a headline accuracy figure appears without a published method, and the guarantee behind it covers only addresses the vendor marked valid or deliverable. The table records each claim as published, with the date it was read.

Two patterns hold across the table. The first is scope. NeverBounce excludes accept-all and unknown results by name, Emailable requires the Deliverable classification, and ZeroBounce's terms require that you mail only the valid file. Bouncer puts the scope into its own headline: "when we say an email is deliverable, it is." A guarantee on that bucket says nothing about how much of a list landed in risky or unknown.

The second is method. None of these pages publishes how its headline figure was measured: the sample, who decided the ground truth, or whether unknown results sat in the denominator. Read that as a gap on the page, on the date it was read. A vendor may measure its figure carefully and keep the method internal. The page alone cannot tell you.

Bouncer's guarantee page shows why the method matters. It reports "98% coverage", with 2% of emails marked unknown, beside "accuracy above 99%". Coverage and accuracy are separate numbers. A page that reports only accuracy leaves coverage unstated.

Why does SMTP verification give wrong or unknown answers?

Because SMTP was designed to accept mail, and a verifier has to read a mailbox verdict out of replies that were never meant to give one. An SMTP check connects to the server named in the domain's MX record, names the address in a RCPT TO command, reads the reply and disconnects before sending anything.

RFC 5321 section 3.3 defines the two basic replies: "If accepted, the SMTP server returns a "250 OK" reply and stores the forward-path. If the recipient is known not to be a deliverable address, the SMTP server returns a 550 reply". A 250 says the server accepted the recipient. Whether anything checked the mailbox is left open. Section 6.1 expects that delivery can fail after acceptance, in which case the receiver "MUST formulate and mail a notification message."

The RFC's strict rule applies to a different command. "A server MUST NOT return a 250 code in response to a VRFY or EXPN command unless it has actually verified the address." Sites may disable VRFY and must then return 252, and section 7.3 adds that RCPT commands "can be used to obtain the same information about address validity." Section 6.2 gives the reason servers hold back: accepting a message "may trigger additional undesirable traffic by providing verification of the address".

Catch-all domains

A catch-all, or accept-all, domain returns 250 for every local part. Verifiers detect one by probing a deliberately nonexistent address at the same domain alongside the real one. If both are accepted, the domain is catch-all, and the reply to the real address carries no information about the mailbox. The mechanics are covered in catch-all domain.

Greylisting and other 4xx replies

A greylisting server defers the first attempt from any sender it has not seen with a 4xx temporary reply. The decision uses the sending IP, the sender and the recipient, and the mailbox's existence is not one of the inputs, so a real address and a made-up one receive the same first answer. A 4yz reply tells the client it should try again later. A verifier that probes once gets no verdict. See greylisting.

Policy blocks

Some servers refuse the verifier itself. RFC 3463 assigns the X.7 subject to "Security or Policy Status", so a 5xx reply carrying a 5.7.x code is a refusal on security or policy grounds. The reply is permanent, and it concerns the check rather than the mailbox. It differs from the mailbox-level rejection covered in SMTP 550 5.1.1. A verifier that files a 5.7.x block as invalid reports something the server never said. The reply classes are set out in SMTP error codes.

Consumer providers that accept every address

Some consumer providers do not reveal mailbox existence over SMTP and accept every RCPT. For a provider like this, a 250 reads the same for a real address and a made-up one, so the SMTP reply alone cannot settle the result.

What does each verification result mean?

Four result types cover what an SMTP-based verifier can honestly report. Vendors name them differently (valid, deliverable or safe; risky or accept-all), but the causes behind each are the same.

The free plan includes 100 email validations a month, with no card required. Get your free API key.

What are false positives and false negatives in email verification?

They are the two ways a verifier can be wrong, and they depend on which result you call positive. Google's machine learning course defines them: "False positives are actual negatives that were misclassified", and "False negatives are actual positives that were misclassified as negatives". Take valid as the positive class:

• A false positive is a bad address reported valid. You mail it, and it becomes a hard bounce.
• A false negative is a real address reported invalid. On a signup form, that is a real person turned away.

Vendors do not use the labels consistently. A Bouncer blog post describes calling a bad address deliverable as the error it works to avoid and names it a false negative, the reverse of the textbook usage with valid as positive. Ask which error a vendor means before comparing.

Three ratios come from the same counts. Accuracy is correct classifications over total classifications. Precision is TP/(TP+FP): of everything called valid, the share that was. Recall is TP/(TP+FN): of every real address, the share called valid. A guarantee limited to the deliverable bucket is closest to a statement about precision.

The denominator decides the headline. Take a hypothetical list of 1,000 addresses. A verifier returns unknown on 100 and gets 880 of the other 900 right. Counted over all 1,000, as Hunter's benchmark formula does, accuracy is 88%. Counted over the 900 it answered, accuracy is 97.8%. The results are identical in both cases. Only the denominator changed.

Why do published email verification benchmarks disagree?

Because each benchmark chooses its own sample and its own scoring rules, and both published benchmarks found for this guide are run by companies that sell verification.

Hunter published its test on 3 November 2025. It used about 3,000 addresses: 2,700 real addresses "collected from the responses of recent outreach campaigns" plus 300 invalid ones, split into three cohorts by company headcount. Its formula is "Accuracy = (Number of correct predictions ÷ Total tested emails) * 100%", so unknown results lowered a score. Hunter discloses that it may have "an edge" from using "email activity recorded in Hunter to classify the email addresses." The page does not say how accept-all results were scored.

ZeroBounce ran its own test in the last two weeks of July 2026 on 9,901 addresses "drawn from the hardest domain pools to validate." Where tools agreed, "the consensus verdict stood". Every conflicting address was "manually verified by ZeroBounce deliverability engineers". Catch-all and unknown results both counted as not accurate.

ZeroBounce scored 60.70% in Hunter's test and 98.02% in its own. The two figures describe two experiments with different samples, different ground truth and different rules for catch-all. Neither number belongs to the product alone. The research for this guide found no independent, non-vendor benchmark. For published pricing and features side by side, see the email verification API comparison.

How can you test an email verifier's accuracy claim yourself?

Build a small list where you already know the answer for every address, and score each vendor against it.

1. Add known-valid addresses you control: team mailboxes and test inboxes at several providers.
2. Add known-bad addresses from your own bounce logs, taken from permanent 5xx rejections.
3. Add addresses on a catch-all domain you own: one real mailbox and several made-up local parts.
4. Run the same list through every verifier on the same day, so server behaviour is the same for all of them.
5. Count unknown separately. Report accuracy over the whole list and over answered addresses only, and note the unknown share beside both.
6. Count false positives (known-bad called valid) and false negatives (known-good called invalid) as separate numbers.

The catch-all rows show whether a verifier labels unproven mailboxes honestly. The bounce-log rows show its false positives on your real traffic.

How Trueguard handles this

Trueguard's email verification API returns one of four statuses: safe, risky, invalid or unknown. When it cannot reach a verdict, it returns unknown instead of guessing. Each non-safe result carries its reason, for example "Catch-all domain", "Could not verify", "Mailbox not found" or "Rejected by mail server".

The rules follow the causes above.

• A 5xx 5.7.x policy rejection is reported as unknown, because the server blocked the check and said nothing about the mailbox.
• To test for catch-all, Trueguard also probes a bogus address at the domain. If that probe gets a 4xx reply (for example a 451 under load), catch-all is unproven, and a 250 on the real address is reported as unknown rather than safe.
• On a catch-all domain, Trueguard uses advanced catch-all detection to check if the mailbox exists. A validated mailbox returns safe with isCatchall: true. A mailbox that cannot be validated returns risky.
• Only a disposable domain, a high-risk TLD or an unconfirmed catch-all downgrades a safe result to risky. Role addresses such as info@ and free-mail addresses are flagged with isRole and isFree, and neither changes the status (see role-based email address).

Trueguard does not publish an accuracy percentage. It reports what it could not establish as unknown, with the reason attached, so the decision about that address stays with you.

The free plan includes 100 email validations a month, with no card required. Get your free API key.