How accurate is Valid Email Checker?
Valid Email Checker delivers 99%+ accuracy across the verification engine. That number is measured by running benchmark lists with known-good and known-bad addresses through the system and comparing our results to ground truth.
Accuracy is the right question to ask, but it is worth understanding what the number does and does not mean before pinning a campaign to it.
What "99%+ accuracy" actually means
When the engine returns a definitive status — safe, invalid, disposable, spamtrap, disabled, inbox_full, catch_all, or role_account — that classification is right 99%+ of the time. The complement is genuine ambiguity: situations where the underlying mail infrastructure itself cannot give a clean yes/no answer, which the engine reports honestly as unknown rather than guessing.
The mistake to avoid is treating accuracy as a single number applied to every input. A more useful framing:
- On `safe` results — when the engine says the mailbox is real and accepting, it is right 99%+ of the time at the moment of verification.
- On `invalid` results — the engine confirmed the mailbox does not exist, which is verifiable directly via SMTP. Near-perfect accuracy here; the failure mode would be a server lying about non-existence, which is rare.
- On `catch_all` results — the engine accurately identified the domain as catch-all, but cannot say with certainty whether the specific recipient exists behind it. The flag itself is accurate; the underlying question is unanswerable.
- On `unknown` results — the engine could not produce an answer at all. These do not count for or against the accuracy number because they are explicitly non-results, and the credit returns to your account automatically.
How we hit 99%+
The accuracy number comes from the depth of the 11-step verification engine. Every address runs through eleven separate checks before getting a status — syntax, domain DNS, MX records, SMTP handshake, mailbox existence (RCPT TO), catch-all detection, disposable provider check, role-account detection, spam-trap detection, inbox-full detection, and disabled-account detection. Each check looks at a different failure mode. The aggregated result is the status you see in the dashboard.
We also route across multiple verification providers in parallel. If the primary provider returns unknown for an address — rate-limited, anti-spam blocked, timed out — the secondary often has a definitive answer. This dual-provider stack is the single biggest reason our unknown rate stays low. Most single-provider verifiers report unknown somewhere in the 5–10% range; our dual-stack approach typically halves that.
When we can't reach 100% — and why no service can
"Is your accuracy 100%?" is a fair question. The honest answer is no, and any verifier that claims 100% is lying. Email infrastructure has several edge cases where certainty is mathematically impossible:
| Situation | Why certainty isn't possible |
|---|---|
| Catch-all domains | Server accepts mail to any address — there is no protocol-level way to ask "does this specific mailbox exist" when the answer is always yes. |
| Greylisting | Server temporarily refuses the first connection from any sender to fight spam. We retry, but if the server stays uncooperative we report unknown. |
| Rate-limited targets | Some servers cap verification attempts before they will answer. We back off and retry; sometimes the cap window does not lift in time. |
| Recent changes | Mailbox was real at verification time but deleted before you sent. Verification is point-in-time; we cannot predict the future. |
| Aggressive anti-spam configurations | Some corporate and government mail servers refuse to confirm any mailbox to any outside check. We get unknown here even though the mailbox exists. |
When the engine cannot reach certainty, the result comes back as catch_all, unknown, or with a lower confidence score — not a fake "valid" verdict to inflate the apparent success rate.
The Unknown auto-refund
Here is the commitment that backs the accuracy claim with a financial mechanism: you never pay for an `unknown` result.
When the engine cannot deliver a definitive answer, the credit is automatically refunded to your PAYG bucket the moment the job completes. No support ticket, no claim process — the refund just appears in your credit-history log. This makes the accuracy number meaningful: there is no incentive for the engine to fudge a marginal case as safe to avoid the refund, because the refund only happens on unknown, not on definitive-but-bad results.
See refunds and credit returns for the full refund matrix and our guarantee for the broader commitments around data handling and the engine.
The two trickiest cases in practice
In real-world use, two situations come up enough to be worth calling out:
Catch-all domains
A meaningful fraction of business domains (especially small-business and educational) are configured as catch-all. We detect this in step 6 of the engine and flag the result as catch_all so you know to send with care. The recipient may be real — usually is — but we cannot confirm it. Sending to catch-all is fine if you test small batches first; see the catch-all guide for the strategy.
Recently changed mailboxes
If you verify a list today and send three months later, some mailboxes will have been deleted, changed jobs, or moved domains in the interim. Verification is point-in-time, not predictive. The fix is straightforward: verify before you send, not weeks ahead.
How accuracy translates to your bounce rate
Accuracy on individual classifications is one thing; what really matters to you is whether your campaigns actually deliver. The accuracy number affects bounce rate, but it is not the same thing. Bounce rate is influenced by:
- Whether the engine correctly identified each address (accuracy).
- Whether the mailbox was still active at send time (point-in-time issue).
- Whether your sending domain reputation lets the message land at all (separate problem).
- Whether your content trips spam filters (separate problem).
- How much time elapsed between verification and send (data decay).
Sending only to addresses we marked safe typically produces single-digit-percentage bounce rates on a clean send setup. If you are seeing higher bounce rates on safe-only sends, the verification accuracy is rarely the culprit — start by checking your sending-domain authentication and the gap between verification and send.
Common questions
How do you measure the 99%+ number?
Benchmark lists with addresses where we already know the ground truth (some are real and active, some are deliberately invalid, some are catch-all, some are known spam traps). We run them through the engine and compare results to known truth. The percentage that matches is the accuracy figure.
Why don't you claim 100% accuracy?
Because no verification service can honestly claim 100%. Email infrastructure has edge cases — catch-all, greylisting, anti-spam blocks, recent changes — where certainty is genuinely impossible. Claiming 100% would mean either inflating the number or hiding the failure cases. The honest move is to commit to 99%+ and report unknown openly when we cannot answer.
What if my campaign bounce rate is higher than I expected?
Email support@validemailchecker.com with the verification task ID and what you observed. Common causes: addresses verified weeks before sending (data decay), sending-domain reputation issues, content tripping filters. We can re-run a sample to diagnose if the engine itself is the culprit, but in most "high bounce rate" tickets the answer turns out to be something downstream.
Next steps
Related questions
Still stuck? Email support