Catch-All Email Detection That Actually Catches Them

What a catch-all server actually is

A catch-all (or "accept-all") mail server receives email for every possible address at a domain — both real mailboxes and ones that don't exist. The server doesn't reject mail for "made-up-name@catch-all-domain.com" — it accepts it, then either silently drops it or routes it to a single inbox.

For email verifiers this is a problem. The standard SMTP probe asks "do you accept mail for foo@example.com?" — a catch-all server says yes whether foo exists or not. A naive verifier sees the accept and marks the address valid. The mail then disappears, your sender reputation pays the price, and you have no idea why.

How KillBounce detects catch-alls

We use a multi-stage detection pipeline tuned per mail provider:

1. 01

   In-session SMTP probe

   After the server responds to the real address, we issue a RSET and immediately probe a clearly-fake address (like "xkj4r6tn9w2qv@" + the same domain) without dropping the connection. If both addresses get accepted, the server is a catch-all — and we label the original verdict accordingly.

2. 02

   Provider-specific shortcuts

   For Google Workspace, Microsoft 365, and Apple iCloud we skip the probe entirely — those providers reliably reject non-existent addresses, so the RCPT verdict is trustworthy and the extra probe just slows things down.

3. 03

   Enterprise gateway recognition

   Known enterprise mail gateways (Proofpoint, Mimecast, Barracuda, Cisco IronPort) are detected by MX hostname pattern. These are technically catch-alls but generally protect real mailboxes behind them, so they get a tuned verdict score (~80) instead of a flat "catch-all" label.

4. 04

   Score adjustment

   A catch-all verdict knocks the deliverability score down by 20–30 points. You get the honest verdict plus a numerical confidence so your downstream rules can decide what to do.

What "catch-all" means for your campaign

A catch-all verdict isn't binary good or bad — it depends on the provider, your sending volume, and your risk tolerance. The right answer is different for an outbound sales team vs a transactional email service.

KillBounce returns a catch-all flag plus the underlying SMTP signal, so you can make the call. Some teams send to catch-alls at lower volume and watch reply rates; others exclude them entirely. Either is valid — what matters is that you know.

Why most verifiers fail at catch-all detection

Cheap verifiers all run the same flawed playbook: single-RCPT probe, accept the 200 OK, mark valid. That misses every catch-all server. Here's why proper detection is harder than it looks:

• Single-RCPT probe always returns 200 OK on catch-all — looks identical to a real mailbox
• Detection requires holding an open SMTP session and sending two probes back-to-back
• Probes have to use unique unguessable local-parts (12+ random chars) so they're not pre-cached
• Some servers rate-limit RCPT TO within a single session — needs careful pacing
• Greylisting can defer the first probe but accept the second — needs retry logic
• Many cheap verifiers skip in-session probes to save infrastructure cost

Which industries run catch-alls most?

Catch-all configuration is more common in some industries than others. If your prospect list skews toward these, expect a higher percentage of catch-all verdicts:

If you're targeting universities or law firms, expect to see a lot of catch-alls and plan accordingly. Modern SaaS companies almost never run catch-alls — they use Google Workspace or Microsoft 365 which give honest RCPT verdicts.