What an SMTP check actually proves
An SMTP check is a conversation with a mail server: the checker connects, announces itself, and asks whether a given mailbox exists. The answer is short, and everything that follows depends on reading it honestly. A check is a statement about a mailbox at a moment - not a statement about a person, and not a permanent fact.
The handshake, step by step
| Step | What is asked | What comes back |
|---|---|---|
| Resolve | Does the domain have a mail server, and does it answer | MX records, or nothing - nothing means no mailbox can exist |
| Greet | The connection itself | A banner; a server that refuses may be blocking checkers rather than reporting a dead mailbox |
| Ask | RCPT TO - is this particular mailbox accepted | Accepted, rejected, or "I accept everything" - the catch-all answer |
| Record | What did the server say, and when | The state that goes into the list: deliverable, undeliverable or unknown |
There is no step in this sequence that says the address belongs to the person you are writing to. That question - identity - is answered by a different source, and conflating the two is the most common way a clean list still produces bad results.
What the check can never prove
- Identity. "This mailbox accepts mail" is not "this mailbox is Pat's". A role address or a shared inbox passes every check.
- Permission. A mailbox that answers is not a mailbox that consented. Consent comes from the source the address was collected from, which is why the source field belongs in the record.
- Permanence. 23% of contacts change jobs every year (ZoomInfo, 2025) and 40% of addresses die within two years (NeverBounce). Any answer has a shelf life.
- Delivery to the inbox. A server can accept a message that later lands in spam. The handshake rules out dead mailboxes, not filters.
The catch-all case is a policy question, not a checkbox
A catch-all domain accepts every address it is asked about, including addresses that do not exist. It is not a yes and it is not a no. The honest thing a provider can do is return unknown and keep it out of the usable count - because the number that makes a verified list bounce 2-5% instead of 10-35% (TAPAC) is exactly the discipline of not promoting unknowns into deliverables. Unknowns can still be sent to under a separate policy, with their own test and their own volume; what they cannot be is silently counted as verified.
How TAPAC runs it
The check happens inside the search that finds the address, so the state belongs to the same call: verified contacts at 2-5% bounce against 10-35% for static databases, catch-alls marked unknown, every result carrying the source page or profile it came from. 100 free searches, then $0.10-0.50 per verified contact, pay-per-use.
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 verification log has to contain, what an SLA can and cannot promise, and finding an address versus proving it.
← Back to TAPAC