The short answer#
A catch-all domain — also called an accept-all domain — is configured to accept
mail for any address at that domain, real or not. When a verification tool
asks the mail server whether a specific mailbox exists, a catch-all server says
yes to everything, so the answer carries no information. The address may well
be deliverable, but no tool can confirm it without actually sending mail.
Qualisend reports these addresses as risky with the reason
low_deliverability and a catch-all flag — never as "valid".
That last sentence is the whole editorial position of this guide: a mailbox behind a catch-all domain is unconfirmable, and any product or article that tells you otherwise is choosing a flattering label for the same uncertainty.
How catch-all detection actually works#
Catch-all detection is stage 7 of the verification pipeline, a domain-level test, and the technique is refreshingly unsophisticated. Alongside the address you asked about, the verifier probes a deliberately nonsensical mailbox at the same domain — a string of characters nobody would ever register. If the server accepts that too, the domain accepts everything, and no per-mailbox answer from that server can be trusted.
Here is the relevant part of the SMTP conversation against a normal domain, where the server actually checks its mailbox list:
> RCPT TO:<jane@example.com>
< 250 2.1.5 OK
> RCPT TO:<x9f2kq77c@example.com>
< 550 5.1.1 The email account that you tried to reach does not exist
The 550 for the gibberish address is what makes the 250 for jane@
meaningful: this server rejects unknown mailboxes, so an acceptance is a real
answer.
Now the same probe against a catch-all domain:
> RCPT TO:<jane@example.com>
< 250 2.1.5 OK
> RCPT TO:<x9f2kq77c@example.com>
< 250 2.1.5 OK
Both come back 250. The server said yes to an address that cannot exist, so
its yes for jane@ proves nothing. jane@example.com might be a real, active
mailbox — or a typo that will bounce the moment you send a campaign to it.
From the outside, at verification time, the two are indistinguishable.
Why detection itself can be inconclusive#
In practice the picture is messier than two clean transcripts. Mail servers
are actively hostile to strangers asking questions: they
greylist unfamiliar senders with temporary
4xx deferrals, rate-limit repeated probes from the same IP, answer slowly
on purpose (tarpitting), or drop the connection mid-conversation. Corporate filtering gateways add their own behavior — many
accept everything at the SMTP boundary and only evaluate the recipient
afterwards, which makes them look catch-all from the outside regardless of
what the mailboxes behind them would say.
Two consequences follow. First, the same address can produce different
verdicts on different days, because the server's mood changed, not the
mailbox. Second, an honest verifier needs an unknown verdict (with reasons
like timeout or unavailable_smtp) for the conversations that never reached
a conclusive answer, and it should treat unknown as "retry later" rather than
quietly filing it under valid or invalid. A tool that never says "unknown" is
not more accurate — it is less honest about the same network reality.
Why verification tools disagree about catch-alls#
Run the same B2B list through several verifiers and you will see the industry's quiet disagreement: one tool marks an address "valid", another calls it catch-all, a third gives it an opaque score of 87 with no explanation. They are all looking at the same SMTP behavior. What differs is what each is willing to claim about it.
The incentive problem is simple: "valid" sells better than "we can't know". A verifier that reports 95% of your list as deliverable feels more accurate than one that reports 70% deliverable and 25% risky — right up until the campaign goes out and the bounces arrive. Some vendors lean into this with "catch-all resolution" claims or AI-scored confidence that quietly rounds unconfirmable addresses up to sendable.
Third-party tests have documented this failure mode directly. In a 2026 hands-on comparison that ran 127,000 checks across B2B lists, three of the seven tools tested marked between 15 and 42 known catch-all addresses as "valid" — addresses the testers had specifically seeded as unconfirmable. A caveat we would apply to any such source, including ones that flatter us: comparison tests are usually published by companies with something to sell (that one comes from a sales-automation vendor), so read them for the raw per-category tables and the methodology, not the rankings.
The scoring shell game#
Watch for the opaque confidence score. A bare "87/100" on a catch-all address looks like precision, but it answers a question nobody asked. The question that matters — does this mailbox exist? — has a known answer for a catch-all domain: unconfirmable. Wrapping that in a two-digit number doesn't add information; it hides the category of the problem. A score is only useful when you can see what produced it, which is why every Qualisend verdict exposes its inputs: the status, the reason code, the sub-flags, the domain's MX provider, and what the SMTP conversation actually returned. Evidence you can read beats a number you have to trust.
Qualisend's position is the boring one: a catch-all address is reported as
risky with reason low_deliverability, the catch-all flag set, and a
mid-range confidence score — never rounded up to deliverable. Every verdict
ships with its evidence — the domain's MX provider and the probe detail — so
you can see why the verdict is what it is instead of trusting a bare number.
You can compare how we and other vendors handle catch-alls on our comparison
pages, for example Qualisend vs ZeroBounce and
Qualisend vs NeverBounce.
Competitor behavior referenced on our comparison pages was last verified July 2026.
If you are evaluating verifiers, three questions cut through the marketing quickly:
- What exactly do you report for a catch-all domain? If the answer is "valid" or a bare score, you now know how the tool handles uncertainty everywhere else too.
- Can I see the evidence per address? MX records, provider, and the SMTP response are checkable facts; a verdict without them is an opinion.
- Do you ever return "unknown"? A vendor that claims a conclusive answer for every address on every run is describing a network that doesn't exist.
How common are catch-all domains?#
The most attributable public number comes from
ZeroBounce's own aggregate data:
more than 9% of the ~11 billion addresses they processed in 2025 returned as
catch-all, and they note that enterprise-heavy B2B lists often run at 30% or
higher. Other vendors publish figures as high as 40–60% of B2B addresses —
typically without naming a data source, so treat any unattributed prevalence
number as marketing. The honest summary: roughly one in ten addresses overall,
several times that on corporate B2B lists, and the only number that matters is
your own list's — which verification tells you directly. Figures above last verified July 2026.
What the numbers reflect: catch-all configurations are far more common
on B2B lists than consumer ones. Google Workspace and Microsoft 365 both make
catch-all routing a simple admin setting, and many companies enable it so that
misspelled addresses (jhon.smith@ instead of john.smith@) still reach
someone. Corporate security gateways add another layer: appliances that accept
mail first and filter afterwards behave as accept-all at SMTP time even when
real mailboxes sit behind them. Large consumer providers, by contrast, reject
unknown mailboxes at RCPT time — gmail.com is not a catch-all domain.
The practical consequence: if you sell to businesses, a meaningful slice of your list will come back risky/catch-all no matter which verifier you use, and your sending strategy needs an answer for that slice — not a tool that relabels it.
Expect the share to vary with how the list was built. Consumer newsletter lists dominated by Gmail, Outlook.com, and Yahoo addresses will see very few catch-all verdicts. Lists built from business-card scans, webinar signups with work emails, or sales prospecting against company domains will see far more — and the older the list, the more of those domains will have changed mail providers or configurations since the address was collected.
Should you send to catch-all addresses?#
There is no honest yes/no answer. The right call depends on where the address came from, what a bounce costs you right now, and how much sender-reputation headroom you have. The one universally bad answer is treating catch-all addresses exactly like confirmed ones in a full-volume send.
"Reputation headroom" is worth spelling out, because it is the variable most senders ignore. A domain with a long history of clean sends and strong engagement can absorb a batch of catch-all bounces as noise. A young domain, a new IP, or a sender recovering from a spam-folder stint cannot — the same bounces land on a thin file and move the needle. The riskier your current standing, the stricter you should be with the unconfirmable slice of your list.
| Where the address came from | Recommendation |
|---|---|
| Recent opt-in signup on your own form | Send. A real person typed it minutes or weeks ago — that intent outweighs the uncertainty. Watch the segment's bounce rate. |
| Older opt-in, no engagement in 6+ months | Segment and throttle. Send small batches, and prune addresses that stay silent through a re-engagement attempt. |
| Purchased or scraped list | Don't send. Catch-all plus a bought list is the riskiest combination in email — unverifiable addresses from an unaccountable source. |
| B2B outbound prospecting | Small, throttled batches from a warmed domain, with bounce feedback reviewed after every batch before widening. |
Whatever you choose, keep catch-all sends in their own segment. Hard bounces from that segment are your real answer arriving late — they tell you which catch-all addresses never existed, and they do reputation damage you want contained and measurable, not diluted across your whole list. If you are not sure how much bounce damage you can absorb, read why bounce rate is the metric mailbox providers actually watch.
How to reduce catch-all risk without lying to yourself#
None of these techniques "verifies" a catch-all address. What they do is shrink the uncertainty over time and cap the damage while you learn:
- Segment and throttle. Catch-all addresses go in their own send group, at a fraction of your normal volume, so bounce feedback stays attributable and contained.
- Seed sends. Before a large campaign, send to a small slice of the catch-all segment first. Read the bounce results, then decide how wide to go.
- Engagement is the only real confirmation. An address flagged catch-all that has opened or clicked before is, for practical purposes, confirmed — a human is behind it. Prioritize engaged catch-alls; treat cold ones with suspicion.
- Monitor the segment's bounce rate separately. Providers read sustained hard-bounce rates as a sender-quality signal, so track the catch-all segment against your usual thresholds rather than letting it hide in the aggregate.
- Sunset policy. A catch-all address that stays silent through several sends should leave the list. Silence is data too.
- Fix the intake. Verify at the point of capture so obvious typos of corporate domains are caught at the door — every mangled work address you reject at signup is one fewer permanent resident of your future catch-all segment.
If your list lives in Klaviyo, the step-by-step cleaning guide applies this playbook end to end — export, verify, suppress, and segment the catch-alls.
A roadmap-honest note: heuristics can rank catch-all addresses by likely quality — the domain's MX provider, gateway type, and past engagement all carry signal, and Qualisend already shows you that evidence per address. But ranking is not confirmation. Nothing confirms a mailbox behind a catch-all domain short of sending to it, and a tool that claims otherwise is selling the label, not the fact.
Catch-all vs related verdicts#
Catch-all is one of several "can't fully bless this" situations, and they call for different actions — which is why collapsing them into one bucket (or one score) loses exactly the information you need. A full mailbox usually heals itself; a disposable address never will; a catch-all needs a sending policy; a timeout just needs another attempt. Suppressing all of them equally throws away reachable subscribers, and sending to all of them equally invites bounces. Here is how the situations map to Qualisend's status and reason vocabulary:
| Situation | Status | Reason code | What it actually means |
|---|---|---|---|
| Catch-all domain | risky | low_deliverability + catch-all flag | The server accepts every address; this mailbox is unconfirmable. |
| Full mailbox | risky | low_deliverability + full-mailbox flag | The mailbox exists but is over quota — mail may bounce until it's cleared. |
| Disposable address | risky | low_quality + disposable flag | A temporary inbox that will stop existing — deliverable today, worthless tomorrow. |
| Role address (info@, support@) | deliverable, role flag | accepted_email | A real mailbox read by a team rather than a person — fine to send, weak for outreach. |
| No clear answer from the server | unknown | timeout / unavailable_smtp /
unknown | The infrastructure didn't answer conclusively — worth retrying later, not a verdict on the mailbox. |
| Rejected or nonexistent | undeliverable | rejected_email / invalid_email /
invalid_domain | The address will bounce — suppress it. |
The distinction that matters most in practice: risky means "we reached the server and learned something concerning", while unknown means "we couldn't get a conclusive answer this time". Risky addresses need a sending policy; unknown addresses mostly need a retry.
Frequently asked questions#
Is a catch-all email address safe to send to?#
Sometimes. A catch-all address from a recent opt-in signup is usually worth sending to; a catch-all address from a purchased list is not. The honest framing is that "catch-all" describes the domain's behavior, not the address's quality — so the safety of sending depends on where the address came from and whether it has ever engaged. Send to catch-alls in their own throttled segment and let bounce feedback settle what verification cannot.
Why did my verifier say "valid" but the email bounced?#
The most common cause is exactly the subject of this guide: the domain was catch-all, the server said yes to the verification probe as it says yes to everything, and the tool rounded that up to "valid". The mailbox never existed, and the truth arrived as a hard bounce at send time. Addresses can also die in the gap between verification and sending, but persistent "verified-yet-bounced" results on B2B lists are usually catch-all optimism.
Can any tool fully verify a catch-all address?#
No. This is a property of SMTP, not a limitation of any particular vendor: a server that accepts every address gives a verifier nothing to distinguish real mailboxes from fake ones. Tools that claim to "resolve" catch-alls rely on heuristics, historical data, or engagement signals — which can usefully rank addresses by likely quality but cannot confirm a mailbox. The only confirmation is a delivered, engaged-with email.
What's the difference between accept-all and catch-all?#
Nothing — they are two names for the same configuration (you will also see "wildcard mailbox"). "Accept-all" describes the server's behavior; "catch-all" describes the mailbox that catches the mail. Verification tools use the terms interchangeably.
Do catch-all addresses hurt my deliverability?#
Not by themselves — having catch-all addresses on a list is normal, especially in B2B. The damage comes from sending blind: the subset of catch-all addresses that never existed will hard-bounce, and sustained hard bounces are the signal mailbox providers punish. Verify the list so the confirmed undeliverables are already gone, then send to the remaining catch-all segment gradually so any bounces surface early, in small numbers, where they cost little.
How do I check whether a domain is catch-all?#
You need a verifier that performs a real SMTP conversation, because catch-all detection requires probing the server (see the transcripts above). A full Qualisend check does this for every address and reports the catch-all flag alongside the domain's MX provider and probe detail — the free plan includes 100 credits to try it on your own list. Note that our free email checker runs syntax, DNS, and typo checks only — no SMTP probe — so it can rule addresses out but cannot detect catch-all; that takes the full check.
