A domain check and a mailbox check answer different questions
Most "verified" lists are checked at the domain level, because that check is cheap, needs no conversation with a mail server, and never fails in a way anyone has to explain. It also does not answer the question the list is being used to answer: can this mailbox receive mail?
Four levels of evidence, four different claims
| Check | What it proves | What it cannot prove |
|---|---|---|
| Syntax / RFC shape | The address is well-formed | Anything about the domain or the mailbox |
| Domain and MX records | The domain exists and announces a mail server | That the server accepts mail, or that this mailbox exists on it |
| SMTP probe of the mailbox | That server responds about that specific address, now | Interest, consent, or that the answer will hold tomorrow |
| SPF, DKIM, DMARC | Something about your sending domain and how it is authorised | Anything at all about the contact's address |
The last row is the one most often misread: an authentication record is a statement about the domain you send from. It never says a word about the mailbox you are sending to. A file can be perfectly authenticated and still be full of addresses that do not exist.
Where a domain check gives false comfort
- A valid MX record is a doorbell, not an answer. The domain announcing a mail server says nothing about which local parts that server holds. A single mistyped letter in the local part survives every DNS-level check.
- Catch-all domains accept everything. On a catch-all, the server answers 2xx for addresses that never existed, so a mailbox-level "yes" is not evidence either - which is exactly the case the honest third state,
unknown, was made for. - Role addresses are structurally alive. A domain-level pass on
info@,sales@orsupport@says the mailbox is likely to exist and nothing about whether anyone reads it. - Parked and dead domains pass shape checks. The syntax is fine and nothing resolves, so a check that never touches DNS reports a clean list of addresses that could not have received mail for years.
The order that produces a usable verdict
- Shape first. Cheap, catches typos and truncation, and costs nothing to run on every row.
- Domain next, and treat a failure as final for that row. If there is nowhere to deliver, no later check will improve on that answer.
- Probe the mailbox before you send. This is the only step that produces a claim about the address itself, and the only one that has to be repeated over time.
- Record three states, not two. Deliverable, undeliverable, and
unknownfor catch-all domains and unanswered probes. - Keep the probe date on the row. A domain can stay valid for a decade while the mailbox behind it changes hands next month.
What TAPAC does
TAPAC runs the mailbox probe as part of the search that found the contact, so the list you get back has been checked at the level that answers the sending question, not just the shape of the domain: state per contact plus probe time and source. Checking a live mailbox at the moment of use is what a published 2-5% bounce rate for checked contacts against 10-35% for static, resold databases is a claim about.
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
100 free searches, then pay-per-use at $0.10-0.50 per contact.
Related: an MX record is not a mailbox, catch-all domains and the unknown state, and what SMTP verification actually checks.
← Back to TAPAC