A throwaway mailbox passes every existence check you can run. The server answers, the address is deliverable, the row is clean - and there is still nothing to do with it. Nobody reads it, nobody replies, and in a few days it will not exist at all.
That is not a failure of verification. It is verification answering the question it was built to answer, which is a narrower question than the one the list is judged by.
Two questions, usually asked as one
Does this mailbox exist? Is this person a buyer? A disposable address separates them cleanly, because it is a yes on the first and a no on the second.
| Property | Who can answer it | Can a verifier decide it |
|---|---|---|
| Does the mailbox exist right now | The receiving server, when asked about that address | Yes - that is what an SMTP probe asks |
| Is it a throwaway or alias domain | Nobody at SMTP level; it is an ordinary domain | No - only a domain policy you own |
| Does a human own it | Nobody, from the outside | No |
| Is it the person's work identity | Your intake rules and the source of the address | No |
| Will it exist next month | Nobody | No - which is why a result carries a date |
The first row is the only one a mailbox probe owns. Everything under it is a judgement about the address, and judgements belong in a policy, not in a syntax check or an MX lookup.
How throwaway addresses get into a B2B list
- They arrive from a signup form, not from a company. A tool that harvests profiles, comments or public form fields collects whatever the person typed there, and what people type into consumer-facing boxes is often the mailbox they consider expendable.
- They were scraped as an alias. Plus-addressing, relay aliases and forwarding addresses look like ordinary addresses and verify exactly like them.
- They are the fallback for a contact whose real work address is unknown - the pipeline filled the row with the only address it had, and the row now looks complete.
In all three cases the probe is right and the row is still not sellable.
Policy at intake, probe at send
- Decide the domain policy once, at intake. A block list of throwaway and alias domains, plus a preference for the domain that matches the company you are targeting, runs before any probing and costs nothing.
-
Never mark a disposable domain invalid if it answers. The three honest states stay deliverable, undeliverable, and
unknown. A disposable address that answers belongs to the second question, so keep it out of the mailbox verdict and out of your accuracy numbers. - Keep the source on the row. "Came from a consumer signup field" and "came from the team page" produce the same probe result and completely different list value. Without the source you cannot tell them apart later.
- Re-probe before the send. Disposable domains are temporary by design, so the check that matters runs while a batch is going out, not on a calendar.
Why agents make this worse
When a list is assembled by an agent, nobody eyeballs the domains. The agent asks a source for contacts, probes them and writes down the states. If the response carries no field saying where an address came from, and no domain policy ran on the way in, throwaway mailboxes and corporate mailboxes arrive identically labelled. The visible symptom is a list that looks clean and produces nothing - and because the probe says deliverable, no report will tell you why.
The list also keeps moving under the answer. 23% of contacts change jobs in a year (ZoomInfo, 2025) and 40% of email addresses are dead within two years (NeverBounce), so a snapshot of existence has a shelf life regardless of how correct it was when taken.
What a checker can honestly return
The published spread is 2-5% bounce for checked contacts against 10-35% for static resold databases, and the gap made of exactly this kind of distinction: a check that answers about the mailbox instead of about the attempt.
TAPAC probes the mailbox inside the search that found the contact and returns one of three states - deliverable, undeliverable, or unknown for catch-all domains - plus the time of the probe and the source page or profile the address came from. The source field is what lets you apply your own domain policy afterwards instead of guessing intent from an address string.
npx -y @tapacapi/mcp # tools: tapac_find_contacts, tapac_status
# hosted: https://tapacapi.com/mcp
# REST: POST https://tapacapi.com/v1/contacts/search
Pay-per-use, $0.10-0.50 per contact, 100 free searches.
Top comments (0)