Why catch-all email addresses can't be verified (and what to do instead)

If you've ever run a list through an email verifier, you've probably seen a result labelled catch-all, accept-all or unknown. It's tempting to treat that as a bug in the tool. It isn't. It's a hard limit of how email works, and once you understand it you'll make better decisions about what to send to.

How verification works under the hood

A verifier never sends an email. It runs a short conversation with the recipient's mail server and stops just before the message would be delivered:

1. Syntax check. Is anna@example.com even a well-formed address?
2. DNS lookup. Does example.com publish MX records, i.e. does anything accept mail for this domain?
3. SMTP handshake. Connect to the mail server and say who the mail is for:

EHLO verifier.example
MAIL FROM:<probe@verifier.example>
RCPT TO:<anna@example.com>

The interesting part is the reply to RCPT TO:

250 2.1.5 OK                       -> mailbox accepted
550 5.1.1 User unknown             -> mailbox does not exist

Then the verifier sends QUIT. No message is ever transmitted. For most domains, that 250 versus 550 is a clean answer.

Where it breaks: catch-all domains

Some mail servers are configured to accept every address at the domain. Ask about a real mailbox and you get 250 OK. Ask about xk2j9q-not-a-person@example.com and you also get 250 OK.

Companies do this for legitimate reasons: so a typo in an address still reaches someone, so mail to ex-employees lands in a shared inbox, or because their security gateway accepts everything first and filters later.

From the outside, a real mailbox and an invented one now look identical. The usual detection trick is to probe a random address that almost certainly doesn't exist. If that gets 250, the domain is catch-all. But that only tells you the domain accepts everything. It tells you nothing about whether the one address you actually care about belongs to a person.

No SMTP-based check can resolve this. Any tool that confidently labels these addresses "valid" is guessing.

Other reasons you'll see "unknown"

• Greylisting. The server temporarily rejects the first attempt (451 4.7.1) and expects a retry minutes later.
• Rate limiting and blocks. Large providers throttle or refuse verification-style connections.
• Timeouts. The server simply doesn't answer in time.

A good verifier retries some of these, but some addresses will stay undetermined, and that's the honest result.

What to do with catch-all addresses

1. Keep them as a separate segment. Don't mix them into your "verified" list.
2. Send to the most engaged ones first (people who opened or clicked recently) and watch your bounce rate.
3. Cap the volume. Hard bounces above roughly 2% of a send are where mailbox providers start to push back.
4. Use other signals. A recent reply, a signed-up account or an address you got directly from the person is worth more than any verifier result.

The pricing question

Here's the part I'd encourage you to check in whatever tool you use: do you get charged for results the tool can't actually determine? Many verifiers bill a catch-all or unknown result exactly like a confirmed one, and some count catch-alls as valid in their accuracy claims.

Disclosure: I work on ListCheckup, an EU-based email verifier. We label catch-all and unknown addresses separately and refund the credit for them, precisely because we can't honestly confirm them. There's a longer write-up on why catch-all domains can't be verified, and a 54-second video overview on YouTube.

If you've found other ways to handle catch-all segments, I'd love to hear them in the comments.