What To Do With Catch-All Email Addresses
By Aria Pramesi, founder of InboxPolicy · Updated July 4, 2026
Catch-all domains accept mail sent to any address at the domain, so SMTP verification cannot confirm whether a specific mailbox exists. About 30-40% of B2B email addresses sit on catch-all domains. InboxPolicy flags these with a catch_all evidence tag and returns action review by default, never guessing they're safe to send.
Why can't SMTP verify a catch-all address?
A catch-all domain is configured to accept mail sent to any address at that domain, whether or not a specific mailbox exists behind it. When a verification engine opens an SMTP session to check a mailbox on a catch-all domain, the mail server accepts the recipient regardless of whether the exact address is real, made up, or mistyped.
That means the one signal most verification tools rely on, an SMTP accept or reject response, doesn't distinguish a real mailbox from a nonexistent one on these domains. InboxPolicy's engine still runs the full sequence, syntax, MX, and live SMTP, but on a catch-all domain the SMTP step returns evidence that can't confirm the specific mailbox either way.
How common is catch-all in B2B email lists?
Roughly 30-40% of B2B addresses sit on catch-all domains, based on InboxPolicy's verification data. That's not a fringe case. On a typical outbound or cold-email list, a third or more of contacts can come back with an unresolved mailbox status, which makes how a verification tool handles catch-all results one of the bigger factors in overall list quality.
What action does InboxPolicy return for a catch-all result?
InboxPolicy tags the SMTP evidence with catch_all and, by default, maps that evidence to the action review, not send. Under a more aggressive policy configuration, the same evidence can map to send_with_caution instead. Either way, InboxPolicy never returns send for an address it cannot confirm exists.
Every response also includes a confidence score and the underlying SMTP evidence, so an agent or workflow calling decide_send or verify_email (via the MCP server or the REST API) gets more than a status label, it gets the reasoning behind the action.
Should you ever send to a catch-all address anyway?
A review or send_with_caution result isn't a rejection, it's an honest admission that SMTP alone can't resolve the mailbox. If you have other signals, a prior reply, a form-submitted address, known engagement history, those can inform the send decision alongside InboxPolicy's evidence.
What InboxPolicy won't do is guess. Unknown and catch-all results are treated the same way: routed to human or workflow review instead of being silently marked safe. That's a deliberate tradeoff between coverage and false confidence.
How do other verification tools handle catch-all addresses?
Most verification tools return a status field rather than a send decision, so catch-all handling comes down to how aggressively they try to resolve the unknown versus how clearly they flag it. See the comparison below for what's publicly documented about each.
- MillionVerifier resolves unknowns aggressively and is priced for one-shot bulk list cleaning, roughly $0.59 to $2.50 per 1,000 verifications.
- ZeroBounce and Kickbox report catch-all and other results through status fields (Kickbox adds a Sendex quality score), aimed at a dashboard workflow rather than a real-time send decision.
- Emailable is a dashboard-first verification suite built around bulk uploads and integrations; no reliable price figure is available to cite here.
| Tool | Entry price | Catch-all handling | Free tier |
|---|---|---|---|
| InboxPolicy | $0.01 per fresh verification (pay-per-call, x402), or credit packs from $5.00/1k down to $3.16/1k at Growth volume | Tags catch_all evidence, returns review by default or send_with_caution under an aggressive policy, never guessed safe | None; cache re-verification (72 hrs), malformed rejection, and idempotent retries are always free instead |
| ZeroBounce | ~$8.00 per 1,000 | Reports via status field; also maintains a spam-trap/abuse address database | 100 emails/month |
| Kickbox | ~$10.00 per 1,000 | Reports via status field plus a Sendex quality score | One-time free credits |
| MillionVerifier | ~$0.59-2.50 per 1,000 | Resolves unknowns aggressively; positioned for one-shot bulk list cleaning | Yes, free tier available |
| Emailable | No reliable price published | Dashboard-first suite with bulk uploads and integrations; catch-all handling not detailed publicly | Not specified |
Frequently asked questions
What is a catch-all email domain?
A catch-all domain is configured to accept mail sent to any address at that domain, whether or not a real mailbox exists. Because the mail server won't reject invalid addresses at the SMTP level, verification tools can't confirm a specific mailbox by SMTP response alone. This makes catch-all domains a blind spot for any tool that only reports mailbox status.
What percentage of B2B emails are catch-all?
Roughly 30-40% of B2B email addresses sit on catch-all domains, based on InboxPolicy's verification data. That means catch-all handling isn't an edge case, it affects a third or more of typical business-to-business contact lists, so how a tool treats catch-all results has a real impact on list quality and sender reputation.
Does InboxPolicy ever mark a catch-all address as safe to send?
No. InboxPolicy tags catch-all evidence with catch_all and returns the action review by default, never guessing the mailbox is valid. Under a more aggressive policy configuration it can return send_with_caution instead, but it will not silently return send for an address it cannot confirm exists.
Is a catch-all result the same as an invalid email?
No. Catch-all means the verification engine could not confirm or deny the mailbox exists because the domain accepts all mail. It is not a bounce prediction. InboxPolicy separates this from malformed or clearly invalid addresses, which are rejected before any SMTP check runs and never billed.
Which tool should I use for a catch-all-heavy list I just want to clean once?
For one-shot cleaning of a large scraped list at the lowest cost, MillionVerifier (about $0.59 to $2.50 per 1,000) is priced for that job and resolves unknowns aggressively. InboxPolicy is built for per-send decisions in live agent workflows, not one-time bulk list cleaning, so pricing and workflow fit differ.
How does InboxPolicy price catch-all verifications?
The same as any other verification, $0.01 per fresh check via pay-per-call x402, or from a prepaid credit pack such as Starter ($5 for 1,000 credits) or Growth ($79 for 25,000 credits). A cache hit within 72 hours returns from_cache and costs 0 credits, even for a previously seen catch-all result.