Catch-All Domains: Why They Confuse Verifiers and What to Do About Them

Run a bulk verification job on a clean B2B list and a familiar pattern emerges: 75% valid, 15% invalid, and a stubborn 10% labelled catch-all or accept-all. Those rows aren't a bug. They're the mail server admitting it won't tell you the truth. Understanding why — and what to do with them — is the difference between a 1% bounce rate and a 6% one.

What a catch-all actually is

A catch-all is a mail server configuration that accepts every message addressed to the domain, regardless of whether the local part (the bit before the @) corresponds to a real mailbox. you@company.com, nonexistent@company.com, sdfgsdfg@company.com — they all get a successful SMTP response.

Why would a company configure this? A few reasons:

• Catching typos. joh@company.com instead of john@company.com doesn't bounce; the admin sees it and forwards it.
• Catching role addresses you forgot to set up. New hire's mailbox not provisioned yet? Mail still arrives somewhere.
• Aliases everywhere. Some companies create per-vendor aliases on the fly (vendor-name@company.com) and don't want to manage allowlists.

It's a perfectly legitimate setup. It's also the single biggest reason email verification is harder than people expect.

Why verifiers can't tell you "valid" or "invalid"

The way an SMTP probe works is: connect to the recipient's mail server, do the handshake, and issue a RCPT TO: command for the address you're checking. A real address gets 250 OK. A non-existent address gets 550 Mailbox not found.

A catch-all says 250 OK to everything.

That's not the verifier failing — it's the receiving server's policy. There's no way for any verifier (ours, our competitors', or a hand-rolled script) to distinguish a real mailbox on a catch-all domain from a random string. The honest answer is "we don't know," and that's exactly what a result of catch-all means.

Beware any tool that claims 99% accuracy on catch-all domains. They're either:

1. Lying about their accuracy by excluding catch-alls from the denominator, or
2. Using ML-based "guessing" that pattern-matches to common formats — useful as a signal, dangerous as a guarantee.

How common are catch-alls, really?

In the lists we've benchmarked across hundreds of B2B campaigns, catch-all rates break down roughly like this:

• Fortune 500 enterprise: 5–10% catch-all. Big IT shops lock things down.
• Mid-market SaaS (50–500 employees): 15–25% catch-all. The "we set it up once and never thought about it" demographic.
• Small business + agencies: 20–35% catch-all. Especially common with shared hosting and small-MSP-managed Microsoft 365 setups.
• @gmail.com, @yahoo.com, @outlook.com: 0% catch-all. Consumer providers don't operate this way.

If your list is mostly mid-market or smaller, expect a meaningful catch-all bucket. It's not your verifier; it's the world.

What to do with a catch-all result

You have three reasonable strategies, each with a different risk profile.

1. Don't send to them. The safest move. Catch-all addresses contribute to your bounce rate the same way invalids do — except instead of getting a hard bounce, you get the mail accepted, then silently dropped or routed to a black hole. Either way, no reply, and the receiving system may flag your sending IP. Cutting catch-alls from your sending list typically improves overall reply rate by 1–3 percentage points just by concentrating volume on confirmed-valid addresses.

2. Send to a smaller subset. If a domain has 50 catch-all addresses on your list and the typical first-name.last-name pattern, you can send to the 5 highest-value contacts and accept some bounce risk. Spread the risk by sending no more than 10% of any single domain's catch-all addresses in a single batch. This is how outbound teams that depend on catch-all domains (mid-market SaaS sales especially) operate. Crucially: send these on a separate sub-domain or a dedicated IP, so when bounces inevitably happen, your main domain's reputation isn't impacted.

3. Run a confidence model. Some verifiers (ours included) attach a confidence score to catch-all results based on whether the local-part matches typical patterns for the domain, whether the name appears in LinkedIn data for the company, and similar signals. Treat the confidence number as a probability, not a guarantee. A score of 85 on a catch-all isn't an 85% chance of delivery — it's an 85% chance the address is plausibly valid, which is a different thing.

How to tell if your own domain is catch-all

If your verification results suggest a domain might be catch-all, you can test it manually. From a terminal:

# Replace company.com with the domain you're testing
swaks --to "definitely-not-real-12345@company.com" --from "you@you.com" --server "$(dig +short mx company.com | sort -n | head -1 | awk '{print $2}')"

swaks is the Swiss Army knife of SMTP debugging. If you get a 250 OK on a clearly-fake local-part, it's catch-all. If you get 550 User unknown, the domain is checking properly.

For your own domain, the cleanest fix is to disable the catch-all and explicitly configure aliases for every real address. Microsoft 365 calls this "Reject mail sent to recipients in the directory only"; Google Workspace handles it via the routing settings in the admin console. Doing this not only makes you verifiable, it also drastically reduces the spam volume your domain catches.

The summary

Catch-all is a server-side configuration, not a flaw in your verifier. About 1 in 5 B2B domains operates this way. The conservative move is to skip them; the pragmatic move is to send to a small, high-value subset from a sub-domain; the dangerous move is to treat a catch-all result as equivalent to a valid one.

What you should never do is shrug it off as a verifier limitation. Every tool faces it. The teams that consistently land at the top of the inbox are the ones that read the catch-all column and act on it.