What is a catch-all email domain?
Updated 24 September 2026 // by Mark Glazer // measured on 569,984 verified addresses
- 569,984B2B addresses verified, 21 July-4 September 2026
- 6.7%of Microsoft 365 addresses came back catch-all
- 45.5%of Google Workspace addresses did
- 87.5%behind a Barracuda gateway
A catch-all domain (also called accept-all) is configured to accept incoming mail for any address at that domain - real or not. Because the server says yes to everything, email verification cannot confirm whether a specific mailbox actually exists, so verifiers return accept-all or unknown instead of valid.
How often that happens is not random. Across 569,984 B2B addresses we verified between 2026-07-21 and 2026-09-04, 6.7% of addresses at Microsoft 365 tenants came back catch-all, against 45.5% at Google Workspace and 87.5% behind a Barracuda gateway. In our lists, where a prospect's company receives its mail is closely tied to whether verification can answer at all - and that changes how you should build, segment and send to a list.
How a catch-all actually works
During delivery, the receiving server is asked whether it accepts mail for the specific recipient. A normally configured server checks its directory and refuses unknown users - which is precisely the signal verification services rely on. A catch-all server answers yes to every address at the domain, then decides internally what to do with the message: route it to a monitored inbox, file it somewhere nobody reads, or discard it.
Organisations set this up for defensible reasons: catching typos in addresses, surviving migrations where old addresses must keep working, or deliberately refusing to leak which employees exist. Many corporate security gateways behave the same way for their own reasons - they accept everything at the edge and filter afterwards, which means a gateway-protected company can look like a catch-all to a verifier even when the mailbox behind it is real. You can see which environment answers for any domain with our mail provider lookup.
Why verification cannot give you a yes
Email verification works by asking the server about an address without sending mail. Against a catch-all, that question has no informative answer: the server would say yes to anything@thatdomain.com. So honest verifiers stop short of valid and label the address accept-all, unknown or risky. This is not the verifier failing; it is the verifier refusing to guess. It is also one of the six traps in why verified email lists still bounce - a list can be freshly verified and still carry addresses whose real status is unknowable.
Catch-all rate by receiving mail stack: what 569,984 verifications show
Most writing about catch-all domains stops at the definition. We run verification on every list before a campaign sends, so we can put a number on how often the label appears and, more usefully, where. Every address below was verified with MillionVerifier; its domain was then classified by the owner of its MX host using our 9.85 million-domain MX census. Owner, not hostname, matters: Microsoft 365 issues a per-tenant MX hostname, so counting hostnames would hide the largest provider entirely.
First-party evidence - ReplyLead verification runs
569,984 addresses, 415,882 domains, 55 verification runs
B2B prospect lists built for our own and client programmes, verified between 2026-07-21 and 2026-09-04. Every figure is a count against a denominator we can name; none is an estimate of the wider market.
Method. 569,984 distinct addresses from 55 MillionVerifier result files; where an address was verified more than once the newest verdict is used. Domains were joined to the MX census and classified by the anchored suffix of the MX host (569,298 of 569,984 addresses matched a census domain). Consumer freemail, Yahoo-hosted domains (9,099 addresses, 49.9% catch-all), domains with no MX record and the 686 addresses whose domain is not in the census sit outside the business-stack figures; owners with fewer than 1,000 addresses appear only in the reconciled total. Verdict names are the verifier's own: ok, catch_all, invalid, unknown. The sample is our own prospect lists, not a random sample of the internet.
| Receiving stack (MX owner) | Addresses verified | Catch-all | Valid | Invalid | Unknown |
|---|---|---|---|---|---|
| Microsoft 365 (Exchange Online) | 235,560 | 6.7% | 58.0% | 34.6% | 0.7% |
| Google Workspace | 120,296 | 45.5% | 40.2% | 14.1% | 0.2% |
| Other or self-hosted (no recognised owner) | 109,702 | 40.0% | 28.5% | 22.2% | 9.2% |
| Proofpoint gateway | 44,559 | 43.4% | 30.5% | 20.9% | 5.1% |
| Barracuda gateway | 19,378 | 87.5% | 6.8% | 5.6% | 0.1% |
| Mimecast gateway | 18,736 | 18.0% | 48.9% | 30.5% | 2.6% |
| Zoho Mail | 1,850 | 18.9% | 42.5% | 12.9% | 25.7% |
| GoDaddy hosted mail | 1,600 | 31.2% | 21.7% | 46.8% | 0.4% |
| Trend Micro gateway | 1,542 | 71.8% | 14.4% | 12.0% | 1.8% |
| Hornetsecurity gateway | 1,293 | 15.8% | 63.2% | 20.9% | 0.1% |
| Cloudflare Email Security | 1,120 | 63.5% | 4.3% | 26.0% | 6.2% |
| Total of the 11 stacks shown | 555,636 | 28.3% | 43.7% | 25.4% | 2.7% |
| All business stacks in the dataset: the 11 shown plus Broadcom Symantec gateway (473) and Trellix gateway (334) | 556,443 | 28.3% | 43.6% | 25.3% | 2.7% |
Why the stacks differ
The difference is mechanical, not a quality judgement about any provider. Microsoft documents Directory-Based Edge Blocking for Exchange Online, which rejects messages for recipients that are not in the directory at the service perimeter; a verifier asking about an invented address gets a clean refusal, which fits the high invalid rate Microsoft 365 shows in the table (34.6%; only the small GoDaddy group is higher) - the stack answers in both directions. Google Workspace lets an administrator route mail for unrecognised addresses to a catch-all address, and our data cannot tell which of these applies to any given tenant. The documented mechanisms are consistent with the measured gap; they do not prove they caused it. Gateways are the other half of the story: they take delivery at the edge and validate recipients according to their own configuration, so their catch-all rate depends on the product and the tenant's settings. In our data Barracuda-fronted domains read catch-all 87.5% of the time, Trend Micro 71.8%, Cloudflare Email Security 63.5%, Proofpoint 43.4% and Mimecast 18.0%.
What actually happens when you email one
One of four things, and you cannot know which in advance. The address is real and the mail is delivered normally. The address is wrong but routed to a catch-all inbox a human occasionally reads. The address is wrong and silently discarded - no bounce, no reply, a send you will book as ignored when it was never seen. Or the server accepts the message and a later internal hop rejects it, producing a delayed bounce that lands your bounce accounting days after the send. That spread of outcomes is why catch-alls sit between valid and invalid in every serious verification taxonomy.
What our sending data adds is a correction to the usual advice. The instinct is to cut the catch-all segment to protect a bounce rate. When we read every dead-address bounce on one programme over a two-day window in August 2026, all 28 bounced addresses carried a verifier verdict of valid, and none was a catch-all. Another list on the same programme had excluded every one of its 115,876 catch-all rows, and that exclusion did not remove those failures, because they lived inside the "valid" tier. From that read we plan for roughly 0.67% dead-address bounces plus about 0.6% policy blocks on verified-valid B2B addresses; a catch-all segment is measured against that floor, not against zero.
The domain label is also not a dead-domain signal: 162,254 of the 162,532 catch-all addresses in the dataset (99.8%) sit on domains with a working MX record. A catch-all domain receives mail; the open question is only whether a particular mailbox exists behind it.
Catch-all is a property of the domain, not the person
A subtle point that changes how you read verification exports: accept-all describes the server. Every address at that company will carry the same label, from the founder to a guessed address that has never existed. The label therefore tells you nothing about the individual row - which is why treating accept-all as a quality verdict on the lead, rather than as missing information about the domain, throws away good prospects and keeps bad ones in equal measure.
The dataset bears this out with one honest caveat. Of 16,781 domains where we verified three or more addresses, 4,806 returned catch-all for every address and 2,030 returned it for only some. The mixed cases are almost always domains verified on different dates in different runs: a tenant changed its routing, a gateway was added or removed, or the verifier's view of the domain moved between runs. Read the label as a snapshot of the domain on the day it was verified, which is the practical argument for verifying close to the send.
What a second verification pass can and cannot recover
Because the label is about the domain, a second verifier that uses different techniques can sometimes say more. We tested one on 5,996 addresses drawn from our own campaign lists, grouped by what we had observed about each: accepted by the receiving server with no bounce notice inside the campaign window, bounced with an invalid-recipient code, or labelled valid, unknown, invalid or catch-all by the first verifier. Those are observed sending outcomes and vendor labels - not independent truth about inbox placement - and the sample is not random.
| Segment tested | n | Second-pass result | Reading |
|---|---|---|---|
| Addresses the first verifier called catch-all | 1,000 | 62.9% positive, 34.4% still unresolved, 1.6% invalid, 1.1% unknown | Roughly two thirds of a catch-all segment can be promoted to a sendable verdict; one third stays unknowable. |
| Addresses accepted by the receiver with no bounce notice | 2,935 | 0.24% rejected | The promotion is not bought with rejections of addresses that had accepted mail. |
| Addresses that bounced with an invalid-recipient code despite a valid verdict (61 of the 113 bounces in that read) | 61 | 19.7% caught as invalid | A second pass removes about one in five of the dead addresses the first verifier missed - useful, not a cure. |
The operating consequence: a second pass turns the catch-all segment from "unknown" into two segments, one sendable on the same terms as verified-valid addresses and a smaller residue that keeps the original rule below. It does not justify sending to catch-alls indiscriminately, and it does not find the dead addresses hiding in the valid tier, which remain the larger source of bounces.
The segmentation rule
Refusing to email catch-alls entirely throws away real prospects - at companies that use gateways or privacy-conscious mail setups, every address reads as accept-all, including the CEO's. Emailing them indiscriminately mixes an unmeasurable failure rate into your clean segments. The workable middle:
- Verify live, immediately before the send, so the valid/accept-all split reflects today's reality rather than the state of the list when it was built. The mixed-domain cases above are what staleness looks like.
- Send to catch-alls in their own segment, never blended with verified-valid addresses, so their bounce behaviour is visible instead of averaged away.
- Cap their share of any mailbox's daily volume. Per-mailbox capacity is small and precious; spend most of it on confirmed addresses.
- Watch the segment's bounce rate against the 2% ceiling. If catch-alls from one data source bounce hard, that source's accept-all rows are junk; if they behave like the valid segment, they are mostly real mailboxes behind permissive servers.
- Prefer other evidence when you have it. A person who demonstrably works at the company - active profile, listed on the site - behind an accept-all domain is a much better bet than a pattern-guessed address behind the same domain.
- Know your stack mix before you judge a verifier. A 45.5% catch-all share on a Google-heavy list is the expected outcome, not a bad export.
Triage a verification export
Paste the result counts from any verifier's export and this applies the segmentation rule above: each band's share of the list, what to do with it, and - if you already ran a catch-all segment - its bounce rate read against the 2% working ceiling. The defaults are the per-10,000 mix from the dataset on this page. Arithmetic only, in your browser; nothing is sent anywhere.
Enter the counts from your verifier's export; each band's share of the list and what to do with it appear here.
Download the data
The provider table is published as a small open dataset so you can check it, reuse it or compare your own verifier's export against it. It contains one row per receiving stack with the counts behind every percentage above; no addresses or domains are included.
Download catch-all-rate-by-mail-provider-2026.csv CSV, 15 rows, generated from the 2026-09-04 verification state
How we source and check numbers is described in our editorial standards and methodology. Provider shares measure how common a receiving stack is in our lists; they do not predict whether any particular message will be accepted, which depends on sender reputation, authentication, volume and the receiving organisation's own policy.
A verified address can still bounce. SMTP error codes lists the responses Gmail and Microsoft 365 return, so a bounce can be read as dead, full, blocked or temporary.
When this page does not apply
- You need a verdict on one specific address. The domain's answer cannot confirm a single mailbox (a second-pass verifier resolved about two thirds of a 1,000-address sample, as the second-pass section shows); this page is about how the label spreads across a list, and the triage tool works on counts, not addresses.
- You want a market-wide catch-all rate. The rates describe 569,984 addresses from ReplyLead's own and client programmes, verified with one service between 21 July and 4 September 2026; another verifier or list will read differently.
- Your list is consumer email. The figures cover business mail stacks in B2B prospect lists; consumer freemail and Yahoo-hosted addresses were set aside and are not in the provider table.
- You are reading this months from now. Receiving stacks change and so do verifiers; the dated dataset and its download are on this page, and the method below says what was counted.
How this page was built and checked
Every address in the dataset was verified with MillionVerifier between 21 July and 4 September 2026: 569,984 addresses at 415,882 domains across 55 verification runs, built for ReplyLead's own and client programmes. Each domain found in the census (569,298 of 569,984 addresses) was then classified by the owner of its MX host using ReplyLead's 9.85 million-domain MX census, so Microsoft 365's per-tenant hostnames are counted as one provider. Every rate is a count against a named denominator, not an estimate of the wider market. We did not send test mail to any receiving server for this page. Last checked 24 September 2026.
Common questions
Should you send cold email to catch-all addresses?
Selectively, yes. Exclude them and you exclude entire companies whose infrastructure hides mailbox existence - in our data that is close to half of all Google Workspace addresses and most of the addresses behind Barracuda or Trend Micro gateways. Send to them as a separate, capped, monitored segment built from rows with independent evidence the person is real.
Are catch-all emails safe?
They are unconfirmed rather than unsafe. The risk is a higher and less predictable bounce rate than verified-valid addresses; the mitigation is segmentation and live verification, not avoidance. Note that the dead addresses that actually bounce are mostly ones the verifier marked valid, so excluding catch-alls does not by itself protect a bounce rate.
How do I know if a domain is catch-all?
Any serious verification pass will label it accept-all. The signal is that the server accepts a clearly invented address; when it does, no address at that domain can be individually confirmed. You can also see which stack answers for the domain with a mail provider lookup: a Microsoft 365 tenant rarely reads as catch-all, a Google Workspace tenant or a gateway often does.
Do catch-all addresses bounce?
Some do, sometimes after initial acceptance - the server takes the message at the edge and an internal hop refuses it later. That is why catch-all segments need their own bounce monitoring rather than being judged inside a blended campaign average.
Why do more Google Workspace addresses read as catch-all than Microsoft 365 addresses?
The documented mechanisms differ, and our measurement is consistent with them, although we have not tested the cause directly. Microsoft documents Directory-Based Edge Blocking for Exchange Online, which rejects mail for recipients that do not exist in the directory at the network edge, so a verifier gets a clear no. Google Workspace lets an administrator route mail for unknown addresses to a catch-all address, and many organisations also front their tenant with a gateway that accepts at the edge and filters afterwards. In our verification data 6.7% of Microsoft 365 addresses returned catch-all against 45.5% of Google Workspace addresses.
Are companies behind a security gateway always catch-all?
No, but they are far more often. Addresses behind a gateway made up 26.1% of our catch-all verdicts and only 10.3% of our valid verdicts. Rates differ by product: Barracuda-fronted domains returned catch-all 87.5% of the time, Proofpoint 43.4% and Mimecast 18.0%, which may reflect how each product and tenant validates recipients at the edge; we have not tested that cause directly.
Can a second verifier resolve a catch-all address?
Partly. In our test a second-pass verifier using different methods resolved 62.9% of 1,000 verifier-labelled catch-all addresses to a positive verdict, called 1.6% invalid and left 34.4% unresolved, while rejecting only 0.24% of 2,935 addresses the receiving servers had accepted without a bounce notice. A second pass recovers roughly two thirds of the segment in that sample; it does not make the label disappear.
What does accept-all mean in email verification?
Accept-all is another name for catch-all: the domain is configured to accept incoming mail for any address at that domain, real or not, so a verifier cannot confirm that a specific mailbox exists and returns accept-all or unknown instead of valid. Across 569,984 B2B addresses ReplyLead verified between 21 July and 4 September 2026, 6.7% of addresses at Microsoft 365 tenants came back catch-all, against 45.5% at Google Workspace and 87.5% behind a Barracuda gateway.
How does catch-all email verification work?
A verifier asks the receiving server whether it accepts mail for the specific address, without sending a message. A normally configured server checks its directory and refuses unknown users; a catch-all server answers yes to every address at the domain, so an honest verifier stops short of valid and labels the address accept-all, unknown or risky. That is the verifier refusing to guess, not failing; the segmentation rule and the triage tool above cover what to do with the result.
Sources and check dates
ReplyLead's own data and pages behind the figures on this page (open data archived with DOI 10.5281/zenodo.22920956):
- Catch-all verification dataset (this page): the 569,984-address counts by receiving mail stack.
- B2B email provider market share (MX census): the 9.85 million-domain census used to classify each domain.
- Why verified lists still bounce: catch-all as one of six verification traps.
- Mail provider lookup: the same MX read for a single domain.
Outside primary sources, each read on the date shown:
- RFC 5321, Simple Mail Transfer Protocol (IETF): the RCPT exchange in which a receiving server accepts or refuses a recipient, which is the question a verifier asks. checked 24 September 2026.
- RFC 3463, Enhanced Mail System Status Codes (IETF): the X.1.1 'bad destination mailbox address' code a normally configured server returns for an unknown user (Exchange Online's edge block returns 5.4.1 instead). checked 24 September 2026.
- Microsoft Learn: Use Directory-Based Edge Blocking to reject messages sent to invalid recipients in Exchange Online: Exchange Online rejects mail to invalid recipients at the edge (550 5.4.1) when all of a domain's recipients are in Exchange Online. checked 24 September 2026.
- Google Workspace Admin Help: Get misaddressed email in a catch-all mailbox: how a Google Workspace administrator routes mail for unknown addresses to a catch-all mailbox. checked 24 September 2026.
- MillionVerifier: the verification service used for every address in this dataset; its homepage lists catch-all email verification as part of the service. checked 24 September 2026.
We verify every list live and segment what cannot be confirmed
List building, live verification, a second pass on the catch-all segment and per-segment monitoring are part of every ReplyLead cold email and LinkedIn programme, and our pay comes mostly from the revenue you close.
How list building works Why verified lists bounce How ReplyLead runs outbound