A disposable address is deliverable and worthless
Two questions get asked about a contact, usually as if they were one: does this mailbox exist, and is this person a buyer. A disposable address separates them cleanly. It exists, the server answers 250 without hesitation, and there is still nothing to do with it - nobody is reading it, nobody is going to reply, and in a few days it will not exist at all.
What actually distinguishes an address
| 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 exactly what an SMTP probe asks |
| Is it a throwaway or alias domain | Nobody at SMTP level; the domain is a normal domain | No - only a domain list or your own policy can |
| Does a human own it | Nobody, from the outside | No |
| Is it the person's work identity | Your own intake rules and the source of the address | No |
| Will it still 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 below it is a judgement about the address, and it belongs to a policy, not to a syntax check or an MX lookup.
How a throwaway address gets into a B2B list
- It arrived from a signup form, not from a company. A tool that harvests profiles, comments or form fields collects whatever the person typed there, and what people type into consumer-facing boxes is often a mailbox they consider expendable.
- It was scraped from a public page as an alias. Plus-addressing, relay aliases and forwarding addresses look like ordinary addresses and verify like them.
- It belongs to a contact whose real work address is unknown, so the pipeline filled the row with the only address it had.
In all three cases the check is right and the row is still not sellable. That is not a bug in the verification; it is the check answering the narrower question it was asked.
The rule: 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, is cheap and runs before any probing.
- 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 attached to 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, not on a schedule. A disposable domain is temporary by design, so the check that matters is the one that runs while a batch is going out.
Why this matters more for agent-built lists
When a list is assembled by an agent, nobody eyeballs the domains. The agent asks the source for contacts, gets addresses back, probes them and writes down the states. If the response contains no field that says where the address came from and no domain policy on the way in, then throwaway mailboxes and corporate mailboxes arrive identically labelled - and the only visible symptom is a list that looks clean and produces nothing.
What TAPAC returns
Each result carries a state - deliverable, undeliverable, or unknown for catch-all domains - together with the time of the probe and the source page or profile the address was taken from. The source is what lets you apply your own domain policy after the fact instead of guessing from the address itself.
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
Checked contacts carry a published 2-5% bounce rate against 10-35% for static, resold databases; TAPAC is pay-per-use at $0.10-0.50 per contact with 100 free searches. The list keeps moving underneath the answer: 23% of contacts change jobs annually (ZoomInfo, 2025) and 40% of email addresses are dead within two years (NeverBounce).
Related: catch-all domains and the unknown state, what cleaning a list can and cannot fix, and role addresses.
← Back to TAPAC