Ask an SMTP check whether sarah.keller@ exists at a domain whose server accepts everything, and the answer comes back as an acceptance. The verifier writes valid. Nothing in that exchange established that Sarah exists, and the mistake is not rare — it is the single most common way a "verified" list still bounces.
A catch-all domain (also called accept-all) is a deliberate configuration. Ask about any local part you like and the server replies that it will take the message. Refusing individual mailboxes is exactly what the operator turned off.
Three answers, only two of them informative
Every SMTP mailbox probe resolves into one of three states:
| Reply from the server | What it establishes | What it should be reported as |
|---|---|---|
| Mailbox accepted, domain not catch-all | The mailbox exists right now | Verified |
| Mailbox rejected — no such user | The address is dead | Invalid |
| Server accepts anything at the domain | Nothing about this mailbox | Unknown |
Many tools fold the third row into the first, because a list that is 98% valid sells better than a list that is 60% verified and 40% unmeasurable. The cost is deferred, not removed: it lands in your bounce rate three weeks later, on a sending domain that was still warming up.
Why companies run catch-all
None of these are bad reasons, which is why the configuration is everywhere:
- a mistyped internal address should not bounce back at an employee;
- directory harvesting gets much harder when every guess is accepted;
- aliases and role addresses route to a team, not a person.
The third reason is the interesting one for outreach: a catch-all domain can genuinely have a sales@ or founders@ that a human reads. The server simply will not tell you which local parts those are.
What an SMTP check proves
An SMTP handshake is a conversation with a server about a mailbox. It answers one question — will this address accept mail right now — and it answers it only when the domain cooperates. Compare that with the rest of a lead workflow:
- Deliverability — does the mailbox exist. This is the part SMTP can answer honestly, and the part catch-all servers refuse to answer.
- Relevance — is this the right person for the offer. Scraping and profile matching answer this, and no mailbox probe helps.
- Interest — will they reply. Neither the probe nor the profile answers this.
Confusing those three is how teams buy "verified" lists, still bounce, and conclude that verification does not work.
Handling unknowns as a first-class segment
The practical fix is not a better check, it is honest labelling:
- Keep catch-alls out of the verified count. They belong in their own bucket with their own expected bounce.
- Send to them last, after the verified portion has established your reputation.
- Never 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 the profile gives you the choice of which leads to spend sends on.
You cannot pick a supplier's mail server. You can pick which addresses you spend a send on, and that choice is where the bounce rate is actually decided.
Doing it in one call
The reason this goes wrong so often is structural: verification is normally a second step, run by a second vendor, after the list has already been assembled — so by the time the addresses are checked, they are a file rather than a query.
TAPAC keeps both halves in one request:
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}'
Each returned row carries the person, company, title, the source the contact was found in, and the verification state of that mailbox — with catch-all results marked unknown rather than valid. Nothing is stored between calls, so there is no interval in which a mailbox can disappear between being found and being checked.
For agents, the same search is an MCP tool: npx -y @tapacapi/mcp, or the hosted endpoint https://tapacapi.com/mcp. Two tools ship with it — tapac_find_contacts and tapac_status — and with no key set the server returns onboarding instead of throwing.
The uncomfortable part
A verifier that reports catch-all mailboxes as valid has not verified anything. It has moved the uncertainty out of the report and into your deliverability, where it costs more. "Unknown" is not a gap in the data; it is the accurate answer, and a tool that says it out loud is worth more than one that hides it behind a percentage.
Pricing, for the record: 100 searches free, then $0.10–0.50 per verified contact, pay-per-use. No seat licence, and verification is included in the search price rather than sold back to you as an add-on.
Sources for the decay figures and the bounce-rate ranges: NeverBounce (40% of addresses dead within two years), ZoomInfo 2025 (23% of business contacts change jobs annually), Harvard Business Review 2024 (freshly sourced data performs 42% better than stale stored records).
Top comments (0)