Catch-all domains: the hidden risk destroying your cold email deliverability

Every cold outreach team eventually gets burned by catch-all domains. It usually happens the same way: you buy a lead list, run it through ZeroBounce or NeverBounce, see a 97% valid rate, load it into Smartlead, and start sending. Within 48 hours, bounces start climbing. By day three, a mailbox is paused. By day five, the domain is on a blacklist. And you are staring at a verification report that said everything was fine.

The verification report was not wrong. It was incomplete. Catch-all domains break the fundamental assumption that verification relies on: that a mail server will tell you the truth about whether a mailbox exists. They do not. They say yes to everything.

What catch-all domains actually are

A catch-all domain is a mail server configuration where the domain accepts email for any address, whether or not a corresponding mailbox exists. Send an email to ceo@catchall-company.com, totallyFakeAddress@catchall-company.com, or keyboard-mash-xyz@catchall-company.com. The server responds 250 OK to all three.

Companies set up catch-all configurations for legitimate reasons. They do not want to miss important messages sent to misspelled addresses. A new employee might start receiving mail before IT creates their individual mailbox. Some organizations route all incoming mail to a central inbox for triage. The intent is not malicious. But the side effect for cold outreach teams is devastating.

Here is the technical flow. Your sending platform connects to the recipient's mail server and says "I have an email for mike@company.com." A normal server checks its mailbox list. If Mike exists, it says 250 OK. If Mike does not exist, it says 550 User Unknown. Simple. A catch-all server skips the check entirely. It says 250 OK to every address. The email gets accepted at the gateway, routed to the internal delivery system, and only then does the server discover that the mailbox does not exist. It generates a bounce notification. That bounce hits your sender reputation.

The key distinction: the bounce does not happen at the SMTP connection stage. It happens after delivery acceptance. This is why verification tools cannot see it coming.

Why verification tools cannot help

SMTP-based email verification works by simulating the first part of email delivery. The tool connects to the recipient's mail server, issues a RCPT TO command for the target address, and reads the response code. 250 means accepted. 550 means rejected. The tool never actually sends an email. It just asks the question.

On a catch-all domain, the answer to that question is always "yes." The tool asks "Will you accept mail for mike@company.com?" The server says yes. The tool asks "Will you accept mail for zzzzz99999@company.com?" The server says yes. There is no way to distinguish a real mailbox from a fictional one. The verification result is technically accurate — the server will accept the email. But acceptance is not the same as delivery.

Some verification tools try a secondary check. They send a probe to a deliberately impossible address like test-{random-hash}@company.com. If the server accepts that address, the tool flags the domain as catch-all. This is useful metadata. But it does not tell you whether your specific contact — mike@company.com — actually has a mailbox. You know the domain is catch-all. You still do not know if Mike is real.

The good verification tools — MillionVerifier, ZeroBounce, NeverBounce — will flag the address as "catch-all" or "accept-all" in their results. They are honest about the limitation. The problem is what teams do with that information. Most teams see "catch-all" and treat it the same as "valid." They send at full volume. Then they get burned.

The numbers: how bad is the problem?

Let me put some real numbers on this so it stops being abstract.

Think about what those numbers mean together. A third of your leads are on catch-all domains. Those leads bounce at dramatically higher rates. And the threshold for domain damage is low — 5% and you are in trouble.

Here is a concrete scenario. You have a campaign with 1,000 leads. 350 are on catch-all domains. The non-catch-all leads bounce at 0.5% (about 3 bounces from 650 sends). The catch-all leads bounce at 10% (35 bounces from 350 sends). Total: 38 bounces from 1,000 sends. That is a 3.8% bounce rate. Your ISP notices. Two more campaigns like this and you are looking at blacklist territory.

Now imagine you are running 5 domains, 3 mailboxes each, sending 50 emails per mailbox per day. Without catch-all awareness, those 350 catch-all leads get distributed evenly. Every mailbox absorbs roughly the same bounce risk. A bad batch of catch-all bounces can take down multiple mailboxes on the same day.

The damage pattern

The catch-all damage pattern is insidious because it looks like everything is working until it is not. Here is how it plays out in practice:

The delayed nature of catch-all bounces makes this worse. A normal invalid email bounces immediately — your platform sees it, maybe pauses, and you move on. Catch-all bounces can take hours or days to come back because the receiving server accepted the email first. By the time you see the bounce notification, you have already sent the next day's batch. The damage compounds before you can react.

This is exactly the scenario described in our guide on why verified emails still bounce. Catch-all domains are the single biggest contributor to post-verification bounces.

Detection approaches that work

You cannot verify individual addresses on catch-all domains. But you can detect which domains are catch-all and adjust your strategy accordingly. There are three practical approaches.

1. DNS-based detection

Some catch-all configurations are detectable through MX record analysis. The MX records themselves do not say "this is a catch-all," but certain hosting patterns correlate strongly with catch-all behavior. Google Workspace domains are almost never catch-all (Google disables it by default). Older Exchange servers running on-premise frequently are. Specific hosting providers and configurations have known catch-all tendencies.

DNS-based detection is fast and free — no SMTP probing required. But it is probabilistic, not definitive. It narrows the field. It does not give you certainty.

2. SMTP probe with dummy address

This is the standard approach. Send an SMTP probe to a deliberately fake address at the domain — something like verify-test-{randomstring}@company.com. If the server accepts it, the domain is catch-all. If it rejects it, the domain has individual mailbox checking enabled.

MillionVerifier, ZeroBounce, and NeverBounce all do this. MillionVerifier is particularly good at it — their catch-all flag is reliable and their pricing ($0.004 per verification) makes it viable even at high volume. The difference between validation and verification matters here: validation checks syntax and domain health, while verification is the SMTP probe that reveals catch-all status.

3. Domain-level caching

This is where most teams leave performance on the table. Catch-all is a domain-level property, not an address-level property. If company.com is catch-all, every address at company.com is catch-all. You only need to detect it once.

But most verification tools check each address independently. You pay for the verification of john@company.com, then sarah@company.com, then mike@company.com, and each time the tool discovers that company.com is catch-all. Three checks. Three charges. Same answer. Domain-level caching stores the catch-all status after the first check and applies it to every subsequent address at that domain.

If you are running 10,000 leads per month and 35% are on catch-all domains, domain caching can cut your verification costs by 15-20% while giving you faster, consistent results.

How Superkabe handles catch-all leads

We built catch-all handling into the core routing logic, not as an afterthought. Here is the pipeline:

The result: you send to catch-all leads without concentrating risk. If bounces happen — and some will — they are distributed thinly enough that no single mailbox or domain takes meaningful damage. And if a particular catch-all domain turns out to be especially problematic, the system learns and adjusts.

For more detail on how the email validation layer works with catch-all detection, see our documentation.

Practical strategy: distribute risk, do not block

The worst response to catch-all domains is to block them entirely. You lose a third of your addressable market. The second worst response is to ignore them and send at full volume. You burn mailboxes. The right response is in the middle: send to catch-all leads, but with controls.

These rules are simple to state and hard to implement manually. When you are running 15 mailboxes across 5 domains with 3 campaigns active, manually tracking which leads are catch-all, enforcing per-mailbox caps, and monitoring bounce rates per segment is unrealistic. This is exactly the kind of thing that should be automated.

The economics of getting it right

Let me put a dollar figure on this. Say you burn a domain because of uncontrolled catch-all sends. That domain took 3-4 weeks to warm up. It costs $10-15/year for the domain, $3-5/month for the mailbox, and the real cost: 3-4 weeks of warming time where it generates zero pipeline. If a warmed domain produces $5,000-10,000 per month in pipeline value, a burned domain costs $15,000-40,000 in lost opportunity during the recovery and re-warm period.

Now multiply that by the number of domains that could get hit. Teams running 10 domains who ignore catch-all risk are playing a game they will eventually lose. The question is not if. It is when.

What about enrichment tools?

Clay, Apollo, and similar enrichment platforms find the email address. They do not assess deliverability risk. Clay will happily give you mike@catchall-company.com and present it as a verified contact. Clay's job is to find data. Your job is to assess whether sending to that data is safe.

This is why a validation layer between enrichment and sending is not optional. Read our guide on email validation vs. verification for the full breakdown of what each layer does.

Frequently asked questions