Every email verification vendor is asked for one number, and it is the one number nobody outside the vendor can check. Not because the vendors are lying - because the thing being measured is decided by the receiving mail server at the moment of the call.
Three layers, only one of which is a fact
| Layer | What is being read | Deterministic? |
|---|---|---|
| Syntax and domain | Is the address well formed, does the domain publish mail records | Yes - same answer forever |
| Mailbox conversation | The receiving server's answer about that specific mailbox | No - an answer at a moment in time |
| Relevance and intent | Is this the right person, will they read it | Not a property of the address |
A single accuracy percentage collapses all three. The first layer is a property of the string. The second is a claim by a server. The third is not in the address at all.
A mailbox-level check has four possible answers
- The mailbox accepts. The strongest statement a check can make - and still only true at the time of the call.
- The server rejects. The domain is live, that mailbox is not. The most useful answer, because a rejected address costs a send, a bounce, and reputation.
-
The domain accepts everything (catch-all). It answers yes to addresses you invent. The check proved nothing about this mailbox, so the honest state is
unknown, never "deliverable". - No answer. Greylisting, rate limiting, a server that refuses third-party checks. An absence of evidence - which is not evidence of absence, and should not be counted as usable either.
Three of those four are not the word "yes". That is where an accuracy claim usually stops meaning anything.
Why the percentage resists verification
- The denominator is unknowable. Nobody holds the true state of every address. A rate over an unknown population cannot be reproduced by anyone else.
- The target moves. 23% of contacts change jobs in a year (ZoomInfo, 2025). 40% of mailboxes are dead within two years (NeverBounce). An answer that was correct when measured decays underneath its own percentage.
- The only external test uses your own mail. The measurable version of accuracy is the bounce rate on messages sent to addresses a provider called deliverable. That number lives in your delivery reports, not in the vendor's marketing page.
Four numbers that can be measured
- Bounce rate at the send - bounces among addresses reported deliverable. A real denominator.
- Unknown share - the fraction that came back catch-all or unanswered. Not a bug; it is the shape of the domains you target.
- Age of the record at the send - days between the check and the message. With 2-5% bounce on verified contacts against 10-35% for static resold databases, this is where the difference between the two regimes is actually spent.
- Re-check coverage - what share of the stored list was re-verified inside your own cadence. Everything else is a snapshot being used as a subscription.
Ask three questions before believing a number
Which states does the check return? How are catch-alls reported? Does every result carry a timestamp? A percentage with no states, no catch-all handling and no date is not a measurement you can act on.
What that looks like implemented
TAPAC runs the mailbox check inside the search that found the address, so a contact arrives with the state already attached - deliverable, undeliverable, or unknown for catch-all domains - with the time of the call and the source page or profile the address came from.
npx -y @tapacapi/mcp # tools: tapac_find_contacts, tapac_status
# hosted: https://tapacapi.com/mcp
# REST: POST https://tapacapi.com/v1/contacts/search
100 free searches, then $0.10-0.50 per verified contact, pay-per-use, no seat to renew in a month you do not send.
Top comments (0)