Accuracy is not one number
Every email verifier is asked for one figure, and it is the one figure that cannot be checked from the outside. The reason is not secrecy: what an address "is" gets decided by the receiving mail server at the moment of the call, and a check is a conversation with that server, not a lookup in a table of facts.
What a check can know, and what nothing can know
| Layer | What is being read | Deterministic? |
|---|---|---|
| Syntax and domain | Is the address well formed, does the domain publish mail records at all | Yes - same answer every time |
| Mailbox conversation | The receiving server's answer to a request for that specific mailbox | No - an answer at a moment in time |
| Relevance and intent | Whether this is the right person, whether they will read it | Not a property of the address |
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 provider that reports one number is collapsing three different things.
The answers a mailbox-level check can return
- The mailbox accepts. The server agreed that the address exists. This is the strongest statement a check can make, and it is still only true at the time of the call.
- The server rejects. The domain is live but that mailbox is not. The most useful answer: a rejected address costs a send, a bounce, and a hit to the sending reputation.
- The domain accepts everything - catch-all. The server answers yes to any address you invent. The check proved nothing about this particular mailbox, so a catch-all must be returned as
unknown, never folded into the usable count. - No answer. Greylisting, rate limiting, a server that refuses third-party checks. This is an absence of evidence, not evidence of absence, and the honest handling is to keep it out of the deliverable bucket too.
Three of those four answers are not the word "yes", and that is where an accuracy claim usually stops being meaningful.
Why a single accuracy percentage resists verification
- The denominator is not knowable. Nobody holds the true state of every address, so a percentage over an unknown population cannot be reproduced by anyone else.
- The target moves. 23% of contacts change jobs in a year (ZoomInfo, 2025) and 40% of mailboxes are dead within two years (NeverBounce). An answer that was right when it was 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 actually sent to addresses a provider called deliverable - and that number lives in your delivery reports, not in the provider's marketing.
Four numbers that can be measured instead
- Bounce rate at the send. Bounces among addresses reported deliverable. This is the false-positive rate of the check, and unlike an accuracy claim it has a real denominator.
- Unknown share. What fraction of the list came back catch-all or unanswered. A high unknown share is not a bug in the check - it is the shape of the domains you are targeting.
- Age of the record at the send. Days between the check and the message. With 2-5% bounce on checked contacts against 10-35% for static resold databases, this number is where the difference between the two regimes is actually spent.
- Re-check coverage. The share of a stored list that was re-verified inside your own cadence. Everything else is a snapshot being used as a subscription.
What TAPAC does with this
The mailbox check runs inside the search that found the address, so a contact arrives with its state already attached: deliverable, undeliverable, or unknown for catch-alls. Every result carries the time of the call and the source page or profile the address came from. 100 free searches, then $0.10-0.50 per verified contact, pay-per-use with no seat.
npx -y @tapacapi/mcp # tools: tapac_find_contacts, tapac_status # or hosted: https://tapacapi.com/mcp # or REST: POST https://tapacapi.com/v1/contacts/search
Related: what a catch-all answer means, what the SMTP handshake actually proves, and how often a list needs re-checking.
← Back to TAPAC