A catch-all domain answers every question with “maybe”
A catch-all (accept-all) mail server takes any local part you invent and replies that it will accept the message. Ask it whether anyone@ exists, and it says yes. Ask about a random string, and it says yes. That reply is not a lie — it is a valid server policy — but it carries zero information about the mailbox you asked about.
This is the single most common way a verified list ends up bouncing anyway: the tool asked exactly the right question, the server answered in a way that cannot be interpreted, and the answer was written into the report as valid.
The three answers a verifier can give
| Reply | What it actually establishes | How it should be reported |
|---|---|---|
| Mailbox accepted, domain not catch-all | The mailbox exists right now | Verified |
| Mailbox rejected — no such user | The address is dead | Invalid |
| Server accepts everything | Nothing about this specific mailbox | Unknown — not valid |
Many verifiers fold the third row into the first because it makes the report look better. The consequence shows up weeks later as a bounce rate nobody can explain, on a list that was sold as verified.
Why catch-all domains are common
- It is the default posture of some hosted mail systems, and companies pick it so a mistyped internal address does not bounce.
- It is a defence against directory harvesting: if every address is accepted, an attacker cannot enumerate real users.
- It hides role accounts and aliases that route to a team rather than a person.
All three reasons are legitimate. None of them makes the mailbox knowable from the outside, and no amount of re-testing an SMTP reply will extract information the server deliberately withholds.
What to do with unknown results
- Keep them out of the verified segment. A catch-all row belongs in its own bucket, with its own expected bounce.
- Send to them last, after the verified portion of the campaign has established reputation.
- Do not average them in. A list reported as “98% valid” that is half catch-all is not a 2% list; it is a 2% list plus a coin flip.
- Prefer domains that answer honestly when a profile allows it — you are not choosing the supplier's mail server, but you are choosing which leads to spend sends on.
How TAPAC reports them
Every address returned by POST /v1/contacts/search carries its verification state from the same call, and catch-all servers come back unknown rather than valid. There is no separate enrichment step, so there is no interval in which a mailbox can stop existing between being found and being checked.
curl -X POST https://tapacapi.com/v1/contacts/search \
-H "Authorization: Bearer ***" \
-H "Content-Type: application/json" \
-d '{"industry":"ecommerce","job_titles":["founder","cmo"],
"company_size":"11-200","location":"netherlands","source":"website","limit":25}'
From an agent: npx -y @tapacapi/mcp, or point an MCP-capable client at the hosted endpoint https://tapacapi.com/mcp. Tools tapac_find_contacts and tapac_status; without a key the server returns onboarding instead of an error.
The honest limit. Unknown is not a failure of the tool, it is the accurate answer. A verifier that reports catch-all mailboxes as valid has not verified anything — it has moved the uncertainty into your bounce rate, where it is more expensive.
Where to go next
- Catch-all email verification · cold email bounce rate · lead scraping tool
- Install the TAPAC MCP server — npx, uvx or hosted endpoint, with the JSON block for Claude, Cursor, Codex and Windsurf.
- Verify email before sending · what an SMTP check proves · verification API
- Compare TAPAC with Apollo, ZoomInfo, Hunter and Lusha · Pricing · Get a free API key