What Is a Catch-All Domain, and Why Can't Verifiers Check It?

If you have run a B2B list through a verifier, you have seen results that are neither valid nor invalid. They come back as catch-all, accept-all, or risky — and it is the single most misunderstood output in email verification.

It is not the verifier being lazy. It is the verifier being accurate about something it genuinely cannot determine.

How verification normally works

To check a mailbox without sending anything, a verifier opens an SMTP conversation with the recipient's mail server and asks whether it would accept mail for that address:

> MAIL FROM: <verify@example.com>
> RCPT TO: <someone@company.com>
< 250 OK                    ← the mailbox exists

If the mailbox does not exist, a properly configured server rejects it:

< 550 5.1.1 User unknown    ← no such mailbox

That difference — 250 versus 550 — is the entire mechanism. No message is ever sent; the conversation is abandoned before any data.

What a catch-all domain does differently

A catch-all domain is configured to accept mail for every address at that domain, whether or not the mailbox was ever created. So:

> RCPT TO: <ceo@company.com>              < 250 OK
> RCPT TO: <asdkjh2981@company.com>       < 250 OK

Both accepted. The second address obviously does not exist, and the server said yes anyway.

This is why acceptance from a catch-all domain tells you nothing. The correct way to detect it is to probe a deliberately absurd address first: if a random string is accepted, the domain accepts everything, and no result for any address there can be trusted.

Why companies configure it this way

It is usually deliberate and reasonable:

• They would rather receive a typo than lose it. Mail to jon@ instead of john@ still arrives.
• Small businesses on shared hosting often get it on by default.
• Departments change. Rather than maintain aliases as staff come and go, everything is accepted and sorted later.

None of that is misconfiguration. It just makes external verification impossible.

What a verifier should tell you

Three states, and the middle one is doing real work:

Result	Meaning
valid	A mail server confirmed this specific mailbox
invalid	Rejected, no mail server, broken syntax, or disposable
risky / catch-all	The domain accepts everything, so this cannot be confirmed

A tool that returns valid on a catch-all domain is telling you about the domain's configuration and letting you believe it is about the mailbox. That is the failure worth caring about, because it looks like good news right up until the bounces arrive.

What to actually do with catch-all addresses

Do not simply delete them — on B2B lists they are often a significant share of the file, and many are perfectly real.

Judge them by where they came from.

• An address published on the company's own website is likely real. Someone put it there to be contacted through.
• An address guessed from a naming pattern — firstname.lastname@ — is a coin flip. It follows the convention, but nothing confirmed the mailbox.
• An address from a scraped or purchased list with no provenance deserves the least trust.

Send to them separately. Keep confirmed-valid addresses in your main sends. Send catch-all addresses in a smaller, separate batch so that if the bounce rate is high, the damage is contained rather than dragging down your whole sending reputation.

Use other signals. A catch-all address attached to a named person, a matching LinkedIn profile, and a company that publishes the same pattern elsewhere is a much better bet than a bare guess.

The short version

Catch-all is not a verifier failing. It is a verifier refusing to guess.

A tool that never returns catch-all is not more accurate than one that does — it is just less willing to tell you when it does not know, and that is the more expensive of the two behaviours.