Catch-All Email Domains: What They Are and How to Handle Them
Standard email verification works by asking the mail server a question: "Does this mailbox exist?" Most mail servers answer honestly. Catch-all domains don't — they say yes to every address, regardless of whether anyone actually reads it.
This guide explains what catch-all configuration is, why it's common, how to detect it, and how to make intelligent decisions about catch-all addresses without defaulting to blanket rejection.
What is a catch-all domain?
A catch-all domain is configured with a wildcard mailbox rule: any email sent to any address at the domain will be accepted and delivered to a designated inbox, rather than bounced back as undeliverable.
For example, if acme.com is configured as catch-all:
john.smith@acme.com— delivered (likely real)xq87zk@acme.com— also delivered (almost certainly fake)ceo@acme.com— delivered (probably real)asdfjkl@acme.com— delivered (probably not real)
The domain accepts all of them. SMTP verification returns 250 OK for every address at that domain.
Why do organisations configure catch-all?
There are legitimate reasons:
Forwarding aliases: A company may want info@, sales@, hello@, contact@ — and any variant someone might guess — to all forward to the same inbox. Rather than creating each alias individually, the IT admin sets a catch-all rule.
Avoiding missed mail: If a customer has jane.smith@company.com in their contacts and sends to jsmith@company.com instead, catch-all ensures the message arrives. For customer-facing teams, this reduces dropped inquiries.
Privacy: Employees can use unique aliases per service (newsletter-amazon@company.com, newsletter-linkedin@company.com) without creating each address in their mail system.
Legacy migration: After a domain rename or acquisition, catch-all on the old domain catches mail to old addresses during the transition period.
These are all real, common configurations. Catch-all is not inherently suspicious — it's a standard mail server feature used by a significant percentage of professional domains.
How catch-all breaks SMTP verification
Standard SMTP verification works like this:
→ RCPT TO: <user@example.com>
← 250 2.1.5 OK ← mailbox exists
or:
→ RCPT TO: <user@example.com>
← 550 5.1.1 User unknown ← mailbox does not exist
On a catch-all domain, every RCPT TO gets 250 OK. The probe address technique — sending a deliberately random address to test the domain's behaviour — is how catch-all is detected:
→ RCPT TO: <xk9a2b3c4d@acme.com> ← random, almost certainly doesn't exist
← 250 2.1.5 OK ← catch-all confirmed
If a random address gets 250 OK, any 250 OK for a real-looking address is meaningless — we can't distinguish deliverable from undeliverable via SMTP alone.
How common are catch-all domains?
Industry data suggests roughly 10–20% of professional email domains are configured as catch-all. The percentage is higher in certain segments:
- Large enterprises (IT teams prefer centralized control)
- Professional services (law firms, consultancies)
- Older companies with legacy infrastructure
- B2B domains generally vs B2C
For consumer email providers (Gmail, Outlook, Yahoo), catch-all configuration is not possible — they always reject invalid addresses with a 550. So catch-all is predominantly a B2B concern.
The problem with binary handling
A naive approach to catch-all domains is to reject all of them. The logic: if I can't verify the address, I shouldn't accept it.
The problem: you'd be rejecting a significant percentage of your legitimate B2B prospects. A sales tool that rejects cmo@acme.com because acme.com is catch-all is functionally broken for professional outreach.
The better model is probabilistic: accept catch-all addresses that have signals of legitimacy, and reject those that look auto-generated.
Scoring a catch-all address
Some verification services score catch-all addresses with a machine learning model trained on historical sending data. Mailbeam does not, and it is worth being clear about why: we have no sending corpus to train on, and a confidence number produced by a model you cannot inspect is difficult to act on when it is wrong.
What Mailbeam returns instead is an additive score built from a fixed set of signals with published weights and caps:
- Syntax, mail route, probe result, disposable, role address, catch-all
- A catch-all address is capped at 70, because no probe can confirm it
- The
reasonfield sayscatch_all_unverifiable, andstatuscomes back asriskyrather thandeliverable
Every point is traceable to a check, so when a score surprises you it is possible to work out why. The trade-off is honest: a rubric will not out-predict a good model on ambiguous addresses. It will tell you what it knows and where it stopped, which is what you need in order to set your own threshold.
Implementing tiered handling
// No SDK yet — this is the 12-line wrapper from /docs/quickstart.
import { verifyEmail } from "./lib/mailbeam";
async function verifyEmailForUseCase(
email: string,
useCase: "signup" | "cold_outreach" | "lead_import"
) {
const result = await verifyEmail(email);
// Non-catch-all: straightforward
if (!result.catchAll) {
return { accept: result.valid && result.score >= 50 };
}
// Catch-all: use score thresholds based on use case
const thresholds = {
signup: 40, // lenient — user is present and motivated
cold_outreach: 70, // strict — high cost of bounce on cold lists
lead_import: 55, // balanced
};
const threshold = thresholds[useCase];
return { accept: result.score >= threshold, catchAll: true };
}Different contexts warrant different thresholds:
| Use case | Recommended minimum score | Reasoning |
|---|---|---|
| Signup (user present) | 40 | Low cost of a mistake; user can fix it |
| Newsletter import | 55 | Moderate risk; easy to clean later |
| Cold outreach | 70 | High reputation risk from bounces |
| Sales prospecting | 65 | Balance reach vs bounce risk |
What to do in the UI
When you detect a catch-all address, you have a few options:
Option 1: Accept silently — Use a permissive score threshold and accept without telling the user. Good for B2B signups where you don't want to create friction for corporate users.
Option 2: Accept with a note — Show a non-blocking message: "We couldn't fully verify this address — please make sure it's correct before continuing." Useful for lead capture forms.
Option 3: Require confirmation — Send a confirmation email and require a click before activating the account. Standard for high-value signups.
The wrong approach is to show an error message saying the address is invalid — it's not. It's unverifiable via standard SMTP, which is a different thing.
Catch-all in bulk verification
When cleaning a list, you'll encounter batches of catch-all addresses. The right approach:
const auth = { Authorization: `Bearer ${process.env.MAILBEAM_KEY}` };
// Submit the list; the response is a job id, not the results.
const job = await fetch("https://api.mailbeam.dev/v1/verify/batch", {
method: "POST",
headers: { ...auth, "Content-Type": "application/json" },
body: JSON.stringify({ emails }),
}).then((r) => r.json());
// Wait for the batch.completed webhook, or poll /v1/jobs/:id until it is done.
const { results } = await fetch(
`https://api.mailbeam.dev/v1/jobs/${job.job_id}/results?format=json`,
{ headers: auth }
).then((r) => r.json());
for (const result of results) {
// A catch-all domain accepts everything, so the verdict comes back as
// "risky" rather than a confident yes or no. Segment on the score.
if (result.status === "risky" && result.reason === "catch_all") {
if (result.score >= 70) keepInList(result.email);
else if (result.score >= 40) flagForReview(result.email);
else suppress(result.email);
} else if (result.status === "undeliverable") {
suppress(result.email);
}
}Don't suppress catch-all addresses wholesale. Segment them by score and make decisions per segment.
Summary
Catch-all domains are a normal feature of professional email infrastructure, not an anomaly. They affect 10–20% of B2B domains. Standard SMTP verification is blind to them — every address at a catch-all domain returns a positive result.
The right response is not blanket rejection. It's probabilistic scoring:
- Detect catch-all via probe address
- Score the address using domain and local part signals
- Apply thresholds appropriate to your use case
- Accept high-confidence addresses, flag medium, reject low
This approach lets you maintain list quality without turning away a significant segment of legitimate B2B users.