Catch-all email domains: why no verifier can resolve them
A catch-all domain accepts mail addressed to any mailbox at that domain, whether or not the mailbox exists. Send to nonsense@example.com and the server says yes. Send to the CEO and it says yes. It says yes to everything, by design.
That single fact has a consequence worth being blunt about: no email verifier can tell you whether a specific address on a catch-all domain exists. Not the expensive ones. Not the ones advertising 99% accuracy. There is nothing to measure, because the server answers identically either way.
Why domains are configured this way
Usually to avoid losing mail. A company that has had sales@, info@, hello@ and a dozen departed employees’ addresses over the years would rather route everything to somebody than bounce a customer. Catch-all is the lazy-but-safe setting, and it is common on business domains for exactly that reason — considerably more common than on consumer mail.
Which means this is a B2B problem specifically. On a list of business prospects, the catch-all bucket can be a meaningful share of your addresses, and it is the share nobody can resolve for you.
How verifiers report them
This is where services genuinely differ, and it is the thing to evaluate rather than the accuracy percentage on the pricing page. The same domain may come back as catch-all, accept-all, unknown or risky depending on the vendor.
What matters is whether the bucket is reported at all. A verifier that quietly folds catch-alls into “valid” produces a beautiful report and a bounce rate you discover a week later, after the damage to your sending reputation is done. One that reports them separately is telling you the truth: here is what I could confirm, here is what nobody can.
When comparing two services, a seeded test list — including domains you know are catch-all — shows you which behaviour you are buying. That comparison is on our list to run; we have not run it yet.
What to do with the bucket
There is no correct answer, only three trade-offs. Pick deliberately rather than by default.
- Drop them. Safest for your domain reputation, and you discard addresses that may well be real. On a list with a large catch-all share this can mean binning a third of your prospects.
- Send anyway. You reach the real ones and bounce on the rest, with the bounces counting against you. Viable on a small, well-targeted list; reckless at volume.
- Isolate them. Send catch-alls from a separate domain and mailbox, so if the bounce rate is bad the damage is contained and your main sending domain is untouched. This is the sensible default at any real volume, and it is what the extra domains in a cold email setup are for.
If you isolate, watch the bounce rate on that segment specifically. It tells you the real quality of the bucket for your particular data source, which is information no verifier could have given you — and it is worth more than any vendor’s accuracy claim, because it is measured on your own list.
Reducing the bucket in the first place
Catch-all rates vary enormously by where the data came from. Addresses guessed from a pattern — firstname.lastname@company.com — land in the bucket constantly, because a guessed address on a catch-all domain is indistinguishable from a real one. Addresses from a maintained database, or captured directly, arrive with far fewer unknowns.
So the cheapest fix is usually upstream of verification: better sourcing produces fewer unresolvable addresses, and the money saved on cleaning a guessed list often exceeds the cost of not guessing.
For the mechanics of everything a verifier can resolve, see the list cleaning guide; for what the services cost, the verification tools we track.