Quick catch-all reference
A catch-all (or accept-all) domain accepts every email address at that domain, valid mailbox or not, without revealing which addresses are real. Email verification tools cannot definitively confirm individual addresses on catch-all domains via SMTP probing, because the server always responds “yes”. Catch-all detection identifies these domains; handling them well is what separates good verification services from bad ones.
| What it is | A mail server configured to accept any address at a domain, then sort, forward, or reject at the application layer (not at SMTP) |
| Why it matters for verification | SMTP-based verification cannot distinguish real addresses from typos on a catch-all domain |
| Detection method | Probe with a fake random address; if the server accepts it, the domain is catch-all |
| Real-world prevalence | 15-25 % of B2B domains, mostly Microsoft 365 deployments and corporate Exchange installations |
| Right handling | Separate bucket in your list, slower send rate, watch bounces, do not treat as either fully valid or fully invalid |
What is a catch-all domain?
A catch-all (also called accept-all or wildcard) mailbox configuration is one where the mail server accepts incoming messages to any address at the domain, regardless of whether a specific mailbox for that address exists. So a domain configured as catch-all will accept mail to nonexistent-user-12345@example.com just as readily as to john@example.com, returning a 250 OK at SMTP time for both.
What happens to those messages depends on the destination configuration. Three common patterns:
- Forwarded to a single mailbox. All catch-all mail goes to an admin or info inbox, often used as a customer service trap for misspelled addresses.
- Quarantined or filtered. Modern catch-all setups (especially Microsoft 365) route unknown addresses to a quarantine for manual review, or to spam.
- Silently discarded. Older or misconfigured setups accept and then drop the message, never delivering anywhere. From the sender’s view, this is identical to delivery; from the recipient’s view, the message vanishes.
From a sender’s perspective, a message to typo@catchall-domain.com looks fully accepted (250 OK, no bounce) but may never be read. That’s the deliverability trap: catch-all domains absorb misspellings without bouncing them back, so your bounce rate stays artificially low while open rates and engagement quietly suffer.
Why catch-all matters for email verification
Email verification works by simulating the start of an SMTP conversation up to the RCPT TO: command, then reading the server’s response. For a normal domain:
- Valid address → server responds
250 OK - Invalid address → server responds
550 No such useror similar 5xx
For a catch-all domain, the server responds 250 OK to every address regardless of whether the mailbox exists. Verification gets stuck: you can’t tell real-user@catchall.com from fake-address-87654@catchall.com using SMTP alone.
The honest answer in verification is “we can confirm the domain exists and accepts mail, but we cannot confirm this specific address is real”. Verification tools that report catch-all addresses as “valid” are lying to you. Tools that report them as “invalid” are also lying. The correct status is a separate category, usually called catch-all, accept-all, or unknown.
How catch-all detection works
The detection method is simple and well-established:
- Pick a random non-existent address at the domain. Something obviously fake like
xkcd-test-83942756@example.comwith high entropy in the local part. - Send a probe SMTP transaction. Connect to the MX server, run through HELO/EHLO and MAIL FROM, then issue
RCPT TO: xkcd-test-83942756@example.com. - Read the response.
- If the server returns
250 OK, the domain is catch-all. - If it returns
550(rejected), the domain is NOT catch-all. - If it returns
4xx(temporary), retry later or treat as unknown.
- If the server returns
- Reset and disconnect. The probe never actually sends a message; the SMTP transaction is aborted before the
DATAstage.
The technique is reliable in principle but has nuances:
- Greylisting. Some servers return a 4xx temporary failure on first contact and only respond accurately on retry. Verification services handle this by retrying after the greylist window (typically 5-15 minutes).
- Rate limiting. Probing 1000 addresses at the same domain in 60 seconds triggers anti-abuse defenses that respond with 4xx to legitimate probes. Verification services rotate IPs, slow probe rate, and cache catch-all status per domain to mitigate.
- Gray catch-all behavior. Some domains accept obviously fake addresses but reject others, especially when the local part follows a known abuse pattern (admin, root, postmaster). The detection probe must use a high-entropy random local part to avoid this.
- Microsoft 365’s variant. Microsoft 365’s default accept-all behavior is to accept at SMTP and then reject at the application layer with a delayed bounce (an asynchronous DSN sent minutes or hours later). The SMTP probe sees 250 OK and labels the domain catch-all, but real undeliverable addresses still produce bounces eventually.
Provider-specific catch-all patterns
| Provider | Default behavior | Probe result | Notes |
|---|---|---|---|
| Microsoft 365 / Exchange Online | Accept-all with quarantine for unknown | 250 OK on probe | Often misdetected as catch-all; real bounces arrive async |
| Google Workspace | Admin-configurable, usually reject unknown | 550 on probe for non-catch-all setups | Some admins enable catch-all forwarding to a single mailbox |
| Self-hosted Exchange (on-premise) | Admin-configurable, often catch-all in older deployments | 250 OK common | Legacy setups frequently catch-all |
| cPanel/Plesk shared hosting | Catch-all by default (admin can disable) | 250 OK common | Many small business domains end up catch-all by accident |
| Postfix/Sendmail/Exim self-hosted | Reject unknown by default | 550 typical | Catch-all is opt-in; less common than cPanel |
| Zoho Mail, FastMail, ProtonMail | Reject unknown | 550 typical | Catch-all is rare |
The high prevalence of catch-all among Microsoft 365 and cPanel deployments explains why most B2B lists show 15-25 % catch-all addresses: the corporate IT defaults push them there.
The percentage trap: not all catch-all addresses are bad
A common mistake is treating “catch-all” as a binary verdict on the domain and removing all addresses from any catch-all domain. That’s destroying your list. The reality is more nuanced.
A catch-all domain accepts every probe. But within that domain, some addresses are still real mailboxes (the boss’s actual email, the CEO’s address, real customer accounts) and some are typos or forgeries. SMTP cannot distinguish them, but other signals can:
- Open rates over time. If you send to a catch-all address and recipients open the message, the address is real. If 0 opens over 5 consecutive sends, the address is probably a typo or unmonitored.
- Reply rate. A response confirms an active human reads that mailbox.
- External enrichment. Cross-reference the address with LinkedIn, Clearbit, or your CRM. If
sarah@acme-corp.commatches a real person at that company, the address is likely valid even if the domain is catch-all. - Format heuristics.
firstname.lastname@patterns are more likely to be real thaninfo@orrandom123@at the same domain.
The right practice is to keep catch-all addresses in your list (especially B2B) with extra scrutiny: track engagement per-address, sunset non-engagers faster, and treat catch-all as a flag rather than a reject.
How to handle catch-all in your list
- Bucket separately. Mark catch-all addresses as a distinct segment in your CRM or ESP. Track their engagement metrics separately so they don’t drag your headline numbers.
- Send slower. A normal address gets a standard ESP send rate; catch-all addresses are throttled to lower-volume drips, reducing the risk of triggering spam filters on real but unmonitored mailboxes.
- Watch async bounces. Microsoft 365 catch-all often returns delayed bounces hours after SMTP acceptance. Your ESP should be configured to process these (DSN parsing) and suppress the address on the next send.
- Sunset faster. A catch-all address with 0 opens after 3 sends is dead weight. Remove or quarantine more aggressively than for normal addresses.
- Enrich before sending. Use external data sources to validate that the address corresponds to a real person at the organization. Pre-send enrichment costs less than post-send reputation damage.
- Skip transactional flows. Mission-critical mail (password resets, receipts) should not go to catch-all addresses without prior engagement confirmation. Use a separate verification path or fall back to alternative contact methods.
10 common catch-all mistakes
- Treating “catch-all” as “valid”. Tools that report catch-all as valid are misleading you. The correct status is unknown.
- Treating “catch-all” as “invalid”. Removing all catch-all addresses cuts genuine B2B targets, since 15-25 % of business domains are catch-all by default.
- Probing without rate limiting. Hammering a single domain with rapid probes triggers anti-abuse blocks. Spread probes across time and IPs.
- Using predictable probe addresses. A probe to
postmaster@orabuse@can be answered by real mailboxes. Use high-entropy random local parts. - Ignoring async bounces. Microsoft 365 catch-all returns delayed bounces; your ESP must parse and suppress, otherwise the same dead addresses are re-sent campaign after campaign.
- Greylisting confusion. A 4xx on first probe doesn’t mean catch-all; retry after the greylist window.
- Forgetting catch-all expires. A domain that’s catch-all today may be reconfigured tomorrow. Re-verify periodically (every 60-90 days) rather than trusting verification results indefinitely.
- Lumping catch-all into a single “risky” bucket. Catch-all is a specific signal; risky is a vague label. Track them separately.
- Charging the same verification price for catch-all results. Reputable verification services discount or refund credits used on catch-all results, since they can’t fully validate. Watch for hidden pricing on unclear results.
- Treating verification as a one-time event. Lists decay. Re-verify your full list every 90-180 days, especially the catch-all segment.
Catch-all FAQ
Should I remove catch-all addresses from my list?
Not blindly. 15-25 % of B2B domains are catch-all by default, mostly through Microsoft 365. Removing all of them cuts genuine targets. Better practice: bucket catch-all separately, monitor engagement per address, throttle send rate, and remove non-engagers faster than non-catch-all addresses. The catch-all flag is information, not a verdict.
Can email verification confirm catch-all addresses are valid?
Not via SMTP alone. The server accepts every address, so the probe always returns 250 OK regardless of whether the mailbox actually exists. Verification can only confirm “the domain exists and accepts mail to anything”; the per-address question stays unanswered. Some verification services combine SMTP probing with external data (LinkedIn, CRM enrichment, engagement history) to give a confidence score on individual catch-all addresses, but the SMTP layer cannot do it alone.
Why does my Microsoft 365 domain show as catch-all?
Microsoft 365 (Exchange Online) defaults to a configuration where SMTP accepts all addresses, then performs recipient validation at the application layer. From a verification probe’s view, every address returns 250 OK at SMTP, so the domain is correctly identified as catch-all. Real undeliverable addresses still bounce eventually, but the bounce is asynchronous (delivered hours after acceptance) instead of synchronous (delivered during the SMTP transaction).
How accurate is catch-all detection?
Very accurate at the domain level (over 99 % when probes are properly randomized and rate-limited). What detection cannot do is tell you which individual addresses at a catch-all domain are real. That gap is a fundamental property of the SMTP protocol, not a tool weakness. Reputable verification services are transparent about this limit.
Are role-based addresses (info@, support@) related to catch-all?
Related but distinct. Role-based addresses (info@, sales@, support@) are real mailboxes, often shared among multiple people. They’re typically not catch-all. The relevance is that you should handle both with extra caution: role addresses tend to have low individual engagement, high complaint rates, and shouldn’t be marketed to without explicit per-role consent. See our role-based email guide for the full picture.
How often should I re-verify catch-all status?
Every 60 to 90 days for the catch-all segment specifically, and every 90 to 180 days for the full list. Domains migrate (Microsoft 365 to Google Workspace and vice versa), admins reconfigure mail servers, and the catch-all behavior can flip without notice. Stale verification results don’t catch these transitions.
Final words
Catch-all is one of those areas where naive practice (treating it as either fully valid or fully invalid) does real damage. The better practice is to acknowledge that catch-all is an information state, not a verdict: 250 OK from a catch-all server means “the domain accepts mail” and nothing more. What you do with that information is what separates list quality.
The right tooling makes the distinction visible. Verification services that report a clear status (deliverable, undeliverable, catch-all, unknown, role-based) give you the granularity to handle each appropriately. Services that flatten everything into “valid” or “invalid” are oversimplifying in a way that costs you reach.
For broader context, see our guides on role-based email addresses, hard vs soft bounces, and the Deliverability hub.
Catch the catch-all before you send.
SMTPing reports catch-all status as a distinct verification result, separate from valid and invalid. Plus disposable addresses, role-based emails, syntax errors, dead mailboxes and known traps. 13 validation types, 25 free checks daily, no card required.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
