Key takeaway A catch-all email address sits on a domain whose mail server accepts every recipient at the SMTPRCPT TOstep, real mailbox or not. Ask it whetherjane.doe@exists and it answers yes. Ask it aboutzzq7-not-a-person@and it answers yes too. The acceptance carries no information about the mailbox, which is why verifiers hand the row back labelled "risky". Published catch-all shares run from 8.6% of all addresses one vendor has checked to 47% of Fortune 500 primary domains. Seven figures, four different populations, every one published by a company that sells catch-all verification. The comparison table is below, with dates. On the largest census anyone has published, 344 of 500 Fortune 500 domains (69%) are catch-all, sit behind a secure email gateway, or both. Only 156 present a standard setup. Read on August 29, 2026. One SMTP probe cannot settle a catch-all. Several can settle many of them: different regions, different times, measured against a control address that cannot exist. Enrow runs 10+ verification checks per address that way and returns the resolved ones as valid instead of flagging them risky and dropping them. Some domains never give in. Those rows are left out, and the reason is in the section on limits.
Two different people land on this page. One is staring at a verifier that just stamped a large slice of a list "catch-all" and wants to know whether those rows are pipeline or garbage. The other wants to switch a catch-all on for their own domain so a misspelled address stops bouncing. Both jobs are covered here, and the setup instructions with the exact setting name for each provider are near the end.
Everything below was read off a live source on August 29, 2026: two RFCs, Google Workspace's admin documentation, Microsoft Learn, Proton's support centre, and the published catch-all figures from six companies that sell verification. Where a number is arithmetic on top of those inputs rather than a published figure, the page says so in the same sentence.
Disclosure, since it shapes the last third of this page. I run Enrow, which finds and verifies work emails and direct dials, and catch-all handling is one of the things it sells. Read the vendor claims table knowing that mine is a vendor claim too.
How common are catch-all domains?
The seven figures measure four different populations, and only ZeroBounce and Allegrow publish a denominator.
Nobody has measured catch-all prevalence neutrally. Seven published figures exist, they span 8.6% to 47%, they measure four different populations, and every one comes from a company that sells catch-all verification. The only study with a stated denominator and a published method covers 500 US companies, not lists, not Europe.
| Published figure | What it counted | Population measured | Publisher | Date on the source | Method published |
|---|---|---|---|---|---|
| 8.6% of addresses | Every address the vendor has ever verified | All lists, all markets | MailerCheck | July 15, 2025 | No denominator given |
| 15.25% median | Catch-all share inside one customer list; average 541 catch-all addresses per list | Individual customer lists | MailerCheck | July 15, 2025 | No denominator given |
| more than 9% of addresses | Over 1 billion of the 11 billion addresses processed in 2025 | All lists, all markets | ZeroBounce | July 7, 2026 | Denominator stated (11 bn addresses) |
| 15–25% of addresses | "15–25% of B2B emails on average lists turn out to be catch-alls" | B2B lists | Clearout | Updated May 28, 2025 | None |
| ~30% of mail servers | "Approximately 30% of B2B email servers are configured with Catch-All" | B2B mail servers | Dropcontact | No date published on the article | None |
| ~30% of domains | "About 30% of B2B domains use catch-all configuration" | B2B domains | Findymail | Live FAQ, accessed August 29, 2026 | None |
| 47% of domains | 235 of 500 primary domains, from ~4.9 million individual validations, late June 2026 | Fortune 500 | Allegrow | Study accessed August 29, 2026 | Full census, method stated |
Sources, all read on August 29, 2026: MailerCheck, ZeroBounce, Clearout, Dropcontact, Findymail, Allegrow.
Four rows in that table are shares of addresses. Three are shares of domains or mail servers. They are not the same quantity and they cannot be averaged. A domain-level share of 30% and an address-level share of 9% can both be true at once, because your list is not evenly spread across domains — it clusters on the large employers, which is exactly where the catch-all rate is highest.
The Allegrow number deserves its own line because it is the only one with a census behind it. Two hundred and thirty-five of the Fortune 500's primary domains behaved as catch-all in late June 2026, from roughly 4.9 million individual validations. Detection came back inconclusive on 53 of the 500, and the authors write that "the 47% is therefore a floor, not an inflated estimate". Allegrow sells catch-all verification, so the incentive runs toward a big number, and they still rounded down. That is worth more than the four undated marketing percentages above it.
Only 156 of the Fortune 500 — 31% — run a domain with neither a catch-all nor a visible gateway, which is the row that decides how much of a US enterprise list a one-shot verifier can actually settle.
| Fortune 500 mail configuration, late June 2026 | Domains | Share of 500 |
|---|---|---|
| Catch-all | 235 / 500 domains | 47% |
| Behind a secure email gateway | 276 / 500 domains | 55% |
| Both catch-all and gateway | 167 / 500 domains | 33% |
| Either one (derived: 500 − 156) | 344 / 500 domains | 69% |
| Neither — a standard setup | 156 / 500 domains | 31% |
| Mailboxes in Microsoft 365 | 412 / 500 companies | 82% |
| Mailboxes in Google Workspace | 17 / 500 companies | 3% |
| Proofpoint, of the 276 gateway domains | 222 / 276 domains | 80% |
| Mimecast, of the same 276 | 21 / 276 domains | 8% |
Allegrow Fortune 500 study, accessed August 29, 2026. Vendor-run: Allegrow sells catch-all verification. Every figure above is published on that page except the 344 "either one" row, which is 500 minus the published 156.
That 69% is the sentence worth carrying away. On the biggest companies in the United States, a single-probe verifier gets a clean, meaningful answer on fewer than a third of domains. And 412 of those 500 companies run their mailboxes in Microsoft 365, which matters in a minute, because one Exchange Online setting explains a lot of the behaviour.
What actually happens in the SMTP conversation
A single probe records the 250 OK and never sees the bounce that comes back hours later.
The control address does all the work. A domain that accepts zzq7-not-a-person@acme.com has told you nothing whatsoever about jane.doe@acme.com, and that single comparison is the entire diagnosis.
| SMTP step | Normal domain | Catch-all domain | What the answer proves |
|---|---|---|---|
| MAIL FROM:<probe@…> | Accepted | Accepted | Nothing either way |
| RCPT TO:<jane.doe@acme.com> | 250 OK only if the mailbox exists | 250 OK | On a catch-all: only that the domain accepts recipients |
| RCPT TO:<zzq7-not-a-person@acme.com> | 550 5.1.1 The email account that you tried to reach does not exist. | 250 OK | This is the control. Two acceptances = accept-all |
| After DATA, minutes or hours later | Nothing further | Possible 550 mailbox not found returned as a bounce | Acceptance at RCPT TO was never a delivery guarantee |
The 550 5.1.1 wording is Google's own, from the Gmail SMTP error codes page stamped last updated August 26, 2026.
The protocol anticipated this, which surprises people. RFC 5321 §3.5.3 sets a hard rule for address verification: "A server MUST NOT return a 250 code in response to a VRFY or EXPN command unless it has actually verified the address." Then it concedes the real world in the next breath. "There may be circumstances where an address appears to be valid but cannot reasonably be verified in real time, particularly when a server is acting as a mail exchanger for another server or domain… In these situations, reply code 252 SHOULD be returned." The standard has a code that means I am not going to tell you, and it has had one since 2008.
Companies run catch-alls for reasons that are perfectly reasonable from the inside. A typo in a business card stops costing them an inbound enquiry. Somebody who left in March keeps receiving handover mail. An MX migration is halfway done and the safe setting is the permissive one. None of that is aimed at you. The consequence lands on you anyway.
Why a single SMTP probe cannot resolve a catch-all
Six documented behaviours produce a 250 or a deferral that a one-shot verifier cannot tell apart from a real acceptance. Four of them have nothing to do with the mailbox you asked about.
| What gets in the way | What one probe sees | The documented behaviour | Source, accessed August 29, 2026 |
|---|---|---|---|
| Greylisting | A 421 and a closed door on first contact | RFC 6647 §2.1: on an unrecognised source the server "returns a 421 SMTP reply and closes the connection", or "returns a different 4yz SMTP reply to all further commands in this SMTP session". §5 recommends keying it on the tuple of IP address, MAIL FROM and the first RCPT TO. §3 names the cost: "Some popular MTAs do not retry failed delivery attempts for an hour or more." | RFC 6647 §§2.1, 3, 5 |
| Rate limiting | The same 421, meaning something else entirely | Gmail: 421 4.7.28 — "Gmail has detected an unusual rate of email. To protect our users from spam, email has been temporarily rate limited." Also 550 5.7.1 — "This email has been rate limited." | Google Workspace admin KB, page updated 2026-08-26 |
| Verification deferred until after DATA | A clean 250 at RCPT TO, then a bounce hours later | RFC 5321 §3.3: "in practice, some servers do not perform recipient verification until after the message text is received. These servers SHOULD treat a failure for one or more recipients as a 'subsequent failure'." And: "Using a '550 mailbox not found' (or equivalent) reply code after the data are accepted makes it difficult or impossible for the client to determine which recipients failed." | RFC 5321 §3.3 |
| An Exchange Online tenant set to Internal relay | 250 for every address on the domain | Microsoft documents that Directory-Based Edge Blocking (DBEB) rejects unknown recipients with 550 5.4.1 Recipient address rejected: Access denied, and that DBEB only takes effect once the accepted domain is set to Authoritative: "Until all of your valid recipients have been added to Exchange Online and replicated through the system, you should leave the accepted domain configured as Internal relay." Relay is the permissive state, by design | Microsoft Learn, ms.date 2024-06-04, updated 2026-08-03 |
| Leakage even on Authoritative | 250 where the docs promise a rejection | Microsoft's own caveat: "There might be infrequent instances where recipient addresses that don't exist in your Microsoft 365 or Office 365 organization are allowed to relay through the service." | Same page |
| A secure email gateway answering first | A fast, confident 250 from something that is not the mailbox store | 276 of 500 Fortune 500 domains sit behind a gateway. The SMTP reply comes from the perimeter, which may not hold the recipient directory at all. | Allegrow, late June 2026 |
Put the Microsoft rows next to the 82% share and the mechanism falls out. Most large B2B mailboxes live in Exchange Online, and whether unknown recipients get rejected there comes down to one accepted-domain toggle that an admin flipped during a migration and may never have flipped back. Microsoft does not call Internal relay a catch-all feature and I am not claiming it does. The reading that this toggle sits behind a large share of B2B catch-all behaviour is mine.
One more row belongs in your head even though it is not a catch-all at all. 452 4.2.2 — "The recipient's inbox is out of storage space." Real person, real mailbox, temporary no. A verifier that collapses every non-250 into "invalid" deletes that person.
What each verification status tells you about the domain
Status labels are a statement about evidence, not about a human being. Four of the six below can be produced by a catch-all domain, which is why the label alone is never the end of the story. (For the list-hygiene view of the same six — what to physically do with each row at scale — see bulk email verification.)
| Status | SMTP evidence behind it | Can a catch-all domain produce this label? | What it does not tell you | Action |
|---|---|---|---|---|
| Valid | 250 at RCPT TO for your address, and a rejection for the control address | No, by construction — the control rejection rules it out | Whether anyone reads that mailbox | Send |
| Invalid | A permanent 5yz, typically 550 5.1.1 | Almost never. A catch-all domain rarely rejects anything | Whether the person exists elsewhere on the domain under another pattern | Delete. Do not retry |
| Catch-all / accept-all | 250 for your address and 250 for an address that cannot exist | This is the label | Anything at all about your specific mailbox | Verify properly. Never bulk-delete |
| Unknown | A 4yz deferral, a greylist, a timeout, a throttle | Yes — a rate-limited catch-all and a rate-limited normal domain look identical | Which of the two you hit | Re-check from another route and another hour |
| Role | The local part matches a shared-function mailbox (RFC 2142: info@, sales@, support@) | Yes — and on a catch-all it is doubly meaningless, since the acceptance proves nothing either | Whether it routes to a person or a ticket queue | Deliverable, wrong target for 1:1. Segment it |
| Disposable | The domain appears on a throwaway-mailbox blocklist | Yes, and disposable domains are frequently catch-all by design | Nothing you need for B2B outbound | Drop from outbound |
The "unknown" row is the one that quietly costs money. It reads like a soft version of "invalid" and it is nothing of the kind. It means the measurement failed, not that the mailbox did.
How do you verify a catch-all email?
You cannot settle a catch-all with one SMTP probe, because a single 250 from an accept-all domain is the same 250 it gives every string. You settle it by making the domain answer repeatedly under conditions it cannot treat identically: several origins, several regions, several moments, each paired against a control address that cannot exist. The verdict comes out of the differences.
| Pass | What it asks the domain | What a difference in the answer reveals |
|---|---|---|
| Control-address probe | An address that cannot exist, on the same domain | Rejection ends the question immediately — the domain is not accept-all. Acceptance confirms it is |
| Second origin, different region and IP | The same pair of addresses from elsewhere | A result that flips with the origin was IP reputation or a throttle, not the mailbox |
| Repeat after a delay | The same pair, later | A first-contact 421 that clears on retry was greylisting (RFC 6647), not a verdict |
| Reply code and timing comparison | 4yz versus 5yz, and how fast each comes back | A deferral is not a rejection. A domain answering instantly and identically for everything is answering from a rule or a gateway, not a directory |
| Control probe with a different local-part shape | firstname.lastname versus obvious noise | Some accept rules only take strings that look like names, which changes what the first control proved |
That sequence sits inside the 10+ verification checks Enrow puts every address through — the SMTP conversation happens more than once, the accept-all test happens more than once, and the origins are spread across regions on purpose. The verdict is assembled from how those answers disagree with each other, never from any single one of them. When it lands on valid, the address goes back into your file as valid and gets used — catch-alls are verified and delivered here, not stamped risky and handed back for you to guess about.
Doing this by hand does not work, and it is worth saying why rather than just asserting it. Telnet to port 25 from an office IP and a greylisting server has never seen that source before, so RFC 6647 §2.1 says it may hand you a 421 and hang up on the very first attempt — before you have learned anything. RFC 6647 §5 recommends a retry window running "from one minute to 24 hours", and you have no second region to retry from meanwhile. The method needs a distributed origin pool. That is the whole reason it is a product rather than a script.
What dropping your catch-alls actually costs
Whatever the catch-all share, verifying the segment costs a quarter of what finding those contacts again would.
Verifying a catch-all row costs exactly one quarter of what finding that same contact again costs, because a verification is 0.25 credit and a found email is 1 credit. That ratio, not any percentage, is the argument against deleting the segment.
| Catch-all share applied to a 10,000-row list | Rows in the segment | Credits to verify (0.25/row) | Cost to verify on Pro ($0.0087/credit) | Contacts discarded if you delete instead | Cost to re-find them later ($0.0087/valid email) |
|---|---|---|---|---|---|
| 15.25% — MailerCheck's median inside one customer list (July 15, 2025) | 1,525 rows | 381.25 credits | $3.32 | 1,525 contacts | $13.27 |
| ~30% — Findymail (B2B domains) and Dropcontact (B2B mail servers), no method published | 3,000 rows | 750 credits | $6.53 | 3,000 contacts | $26.10 |
| 47% — Allegrow, Fortune 500 primary domains, late June 2026 | 4,700 rows | 1,175 credits | $10.22 | 4,700 contacts | $40.89 |
Read that table as a model, not a measurement. It applies three published vendor shares, each measuring a different population, to one hypothetical 10,000-row file. No study I could find measures catch-all prevalence on European B2B lists, or compares Europe with the US, so this page does not claim a European number. The last column is also generous to the delete-everything option: it assumes every discarded contact is findable a second time, which on a 60% observed match rate is not how it goes.
Both cost columns are arithmetic on two published inputs — Enrow's plan price and its credit costs — not published prices in themselves. Across the ladder, the cost of one verification falls from $0.00425 on Start to $0.0020 on Scale, a 53% drop, because the 0.25-credit price per check is the same on every plan and only the credit price moves.
| Enrow plan | Monthly price | Credits included/month | Verifications at 0.25 credit each | Cost per verification | Cost per valid email found |
|---|---|---|---|---|---|
| Free | $0/mo | 50 credits, recurring monthly, no card | 200/month | $0 | — |
| Start | $17/mo | 1,000 credits | 4,000/month | $0.00425 | $0.017 |
| Start 4k | $47/mo | 4,000 credits | 16,000/month | $0.0029 | $0.0118 |
| Pro | $87/mo | 10,000 credits | 40,000/month | $0.0022 | $0.0087 |
| Scale | $397/mo | 50,000 credits | 200,000/month | $0.0020 | $0.0079 |
Plan prices and the 0.25-credit verification cost come from Enrow's own published pricing, re-read on August 29, 2026; the Email Verifier page states "0.25 credits per check" and "50 free credits / No credit card". The two right-hand columns are division. The free tier renews every month rather than once at signup, which makes 200 verifications a month a permanent floor rather than a trial.
What sending to an unverified catch-all costs
Amazon SES is the source most people quote here, and its advice number and its penalty number sit a factor of five apart: it asks for a bounce rate below 2% and takes no action at all until 5%.
| Published number | What it triggers | Who publishes it | Metric | Source, accessed August 29, 2026 |
|---|---|---|---|---|
| Below 2% bounce rate | Advice only, no action attached | Amazon SES | Hard bounces | SES enforcement FAQ, Q4 |
| 5% or greater bounce rate | Account placed under review | Amazon SES | Hard bounces | SES enforcement FAQ, Q4 |
| 10% or greater bounce rate | Sending may be paused | Amazon SES | Hard bounces | SES enforcement FAQ, Q4 |
| 0.3% | Bulk senders at 5,000+ messages a day to Gmail must stay under it | Spam complaints, not bounces | Gmail sender guidelines | |
| No figure at all | — | Google, for bounces | Gmail publishes no numeric bounce requirement | Gmail sender guidelines |
Rows one to three and rows four to five are not the same metric, and mixing them is the single most common error in articles on this subject. Google's 0.3% counts people clicking "report spam"; SES counts mail that came back permanently undeliverable. A campaign can pass one and fail the other on the same send. The full threshold set, provider by provider, is on email bounce rate.
Addresses sourced and verified through Enrow bounce under 1% across our own sends. That is an average we measure on our own files, not a number anyone can promise you, and there is no refund attached to it. A verified catch-all behaves the same way in that data as an ordinary valid address, which is the practical reason the segment is worth rescuing rather than binning.
On my own files, the accept-all pile has never once been the rounding error people assume it is before they look.
What other pages claim about catch-alls, and what the sources say
The dominant claim on this query is that catch-alls cannot be verified by anyone, and it is stated flatly by four vendors, one of them in a Verifalia article dated March 27, 2018 that still sits at position 16 in US organic results (DataForSEO pull, 2026-08-29). The accurate version is narrower and worth stating precisely: a single SMTP probe cannot settle a catch-all, which is true, and different from "no method can".
| Claim in circulation | Who says it, and when | The precise version | Source, accessed August 29, 2026 |
|---|---|---|---|
| "No email verification service can confirm that a specific mailbox exists at a catch-all domain" | Verifalia, article dated March 27, 2018, still ranking | True of a single SMTP probe. Repeated probes from different origins, against a control address, resolve many domains — not all | Verifalia |
| "there is no way to know if they are valid or invalid. No tool on the market can do this because they can't use SMTP to check out what's happening in the inbox" | MailerCheck, July 15, 2025 | The premise is right — SMTP cannot see inside a mailbox. The conclusion overreaches: acceptance patterns across origins carry signal that one session does not | MailerCheck |
| "no email verification solution can validate the existence of an email address on a domain in Catch-All" | Dropcontact, no date published on the article | The same overreach, on an article carrying no publication or update date at all | Dropcontact |
| "verification tools, including Hunter, can't verify if your email is deliverable or not" — then recommends filtering to a minimum 85% confidence score, 90% or above on a domain still warming up, easing down in 5% steps | Hunter help centre, undated | Honest about the limit, then substitutes a probability for a verdict. An 85% confidence score is a bet with the odds printed on it | Hunter |
| "you can't confirm whether the address belongs to a real person" — unresolved catch-alls steered into a separate 0–10 scoring product | ZeroBounce | Same substitution, sold as a second SKU | ZeroBounce |
| "Yes, but only with specialized tools… Tools like Clearout use AI-driven verification that provides confidence scores" | Clearout, updated May 28, 2025 | The one vendor arguing catch-alls are resolvable. Still a score, not a verdict | Clearout |
| "They can be identified, but not fully verified like standard emails" | Evaboot, July 15, 2025 | The most careful sentence in the set | Evaboot |
| "About 30% of B2B domains use catch-all configuration" | Findymail FAQ, live 2026-08-29 | Plausible, unsourced. No sample, no date, no method | Findymail |
Google's AI Overview for this query cites eight sources, and four of them sell email verification: ZeroBounce, MailerCheck, Dropcontact and Mailerio. A fifth, Evaboot, sells a LinkedIn export tool with verification attached. The remaining three are Proton, a list broker and an email agency. That is the honest context for every row above and for this one: I sell verification too. What separates the rows is not who benefits, it is who published a denominator — and across the seven prevalence figures earlier on this page, exactly two did.
And note the shape of the disagreement. Nobody in that table claims a single probe works. The argument is only about whether anything beyond a single probe counts, and three of them answer that by selling a confidence score instead.
How to set up a catch-all on your own domain
Half the people searching this term want the opposite job: turning a catch-all on. Three providers document it, they call it three different things, and not one of the three pages carries a spam warning — the closest anyone gets is Proton suggesting you point the traffic at an address that is not your own inbox.
| Provider | What the setting is called | Where it lives | Plan required | What the provider says about the downside | Source, accessed August 29, 2026 |
|---|---|---|---|---|---|
| Google Workspace | "Get incorrectly addressed messages in a catch-all mailbox" — "If someone sends a message to a user that doesn't exist at your domain, or sends an incorrectly addressed message to your domain, the message is delivered to the catch-all address." | Admin console → Gmail → Advanced settings → Email routing & delivery | The page names no edition requirement; check yours in the admin console | Nothing. No spam or volume warning appears anywhere on the page | Workspace admin KB, updated 2026-08-26 |
| Proton Mail | "Set catch-all" — "receive all mail sent to their domain, even if they are sent to an email address that has not been set up for their domain" | Settings → All settings → Organization → Domain names → Actions | Any paid Proton plan, with a custom domain attached | No explicit warning. Proton suggests routing to a dedicated address such as catchall@example.com so the traffic misses your main inbox | proton.me/support/catch-all |
| Microsoft 365 / Exchange Online | No setting called catch-all. The behaviour follows the accepted domain type | Exchange admin center → Mail flow → Accepted domains | Exchange Online | Documents the reverse configuration: Authoritative with Directory-Based Edge Blocking (DBEB) rejects unknown recipients with 550 5.4.1 Recipient address rejected: Access denied; Internal relay is the state you leave a domain in while recipients are still missing | Microsoft Learn, updated 2026-08-03 |
Registrar and shared-hosting control panels offer the same thing under names like catch-all forwarding or a wildcard alias. Namecheap, one.com, GoDaddy and doteasy all rank in the top 30 for this query on their own setup guides, and I did not read any of them today, so none of them is in that table. Check the date on whatever page you follow.
The part neither Google nor Proton quantifies is the cost. A catch-all address absorbs every dictionary-attack attempt aimed at your domain, and it makes your own team's addresses harder for other people's verifiers to confirm, which shows up as your emails sitting in somebody's "risky" bucket instead of their sequence. The vendors that ship the feature do not publish a number for either effect. Neither will I, because I do not have one.
Where Enrow stops on this
Three limits, and each has a reason worth knowing before you buy anything.
Some domains never resolve. Every pass agrees with every other pass, the control address gets treated exactly like the real one, and no signal separates out. Those rows come back unresolved and stay out of the send. A miss costs nothing; a bounce costs you the domain. I have no published figure for what share that is, and I am not going to estimate one on a page whose whole argument is about unsourced estimates.
Verification and finding draw on the same credit pool. So a big catch-all clean-up eats the month's sourcing budget. On a 1,000-credit Start plan the trade-off is stark: 4,000 verifications and zero new contacts, or 1,000 contacts and no clean-up. Plan it before the month starts.
And verification proves a mailbox accepts mail today. It does not prove a human opens it. A resolved catch-all can be an abandoned account kept alive by a forwarding rule, and no SMTP method on earth reaches that fact. Anyone telling you otherwise is selling you a score.
ready to stop wasting time?
Connected in minutes.
Verified data in seconds.
FAQ
What is a catch-all email address?
A catch-all address sits on a domain configured to accept mail for every recipient, including addresses that do not exist. At the SMTP RCPT TO step the server returns 250 OK for a real mailbox and for pure noise alike. That acceptance carries no information about any specific mailbox, which is why standard verification returns "catch-all" or "risky" rather than a verdict.
How do you verify a catch-all email?
Not with one probe. Offer the same domain a control address that cannot exist, alongside the real one, then repeat the pair from different regions, different IPs and different times. Rejection of the control ends the question. Identical acceptance across every pass, code and delay is what a genuine accept-all rule looks like, and the verdict lives in the differences between passes.
Can a catch-all email still bounce?
Yes, and RFC 5321 §3.3 explains why: "some servers do not perform recipient verification until after the message text is received." The server accepts your recipient during the SMTP session, then rejects the message after the data are sent, returning a 550 mailbox not found as a bounce hours later. Acceptance at RCPT TO was never a delivery guarantee.
What percentage of B2B domains are catch-all?
No neutral measurement exists. Published vendor figures run from 8.6% of all addresses one verifier has checked (MailerCheck, July 2025) to 47% of Fortune 500 primary domains (Allegrow, late June 2026, from a 500-domain census). Findymail cites roughly 30% of B2B domains and Dropcontact roughly 30% of B2B mail servers, neither publishing a method. Every one of those figures comes from a company selling catch-all verification.
How do I set up a catch-all address on my own domain?
In Google Workspace, enable "Get incorrectly addressed messages in a catch-all mailbox" under Gmail → Advanced settings → Email routing & delivery. In Proton Mail, use Settings → All settings → Organization → Domain names → Actions → Set catch-all, available on any paid plan with a custom domain attached. Exchange Online has no catch-all switch; the accepted domain type governs it, with Internal relay accepting unknown recipients.
Do catch-all domains hurt deliverability?
Someone else's catch-all only hurts you if you send to it unverified and the fake rows bounce. Your own is a different bill: it absorbs dictionary-attack spam, and it makes your team's addresses unverifiable for other people's tools, which parks your outbound in their "risky" segment. Neither Google nor Proton publishes a number for either cost.
How I verified this
Every figure on this page was read off a live source on August 29, 2026, and nothing was taken from another article's summary of a source.
Primary specifications: RFC 5321 §§3.3 and 3.5.3 for post-DATA recipient verification and reply code 252, and RFC 6647 §§2.1, 3 and 5 for greylisting behaviour and the IP/sender/recipient tuple. Both quoted from rfc-editor.org.
Vendor documentation: Google Workspace's Gmail SMTP error codes page and its email routing and delivery options page, both stamped last updated August 26, 2026; Microsoft Learn's Directory-Based Edge Blocking article, ms.date June 4, 2024, updated August 3, 2026; Proton's catch-all support article.
Prevalence figures: seven of them, from six publishers — Allegrow's Fortune 500 census, MailerCheck twice, ZeroBounce, Clearout, Dropcontact and Findymail — each cited with the date printed on its own page and the population it actually measured. Five of the seven arrive with no denominator, no date, or neither, and the table says which. Only ZeroBounce (11 billion addresses processed in 2025) and Allegrow (a 500-domain census) published one.
Enrow's plan prices, credit costs and the recurring free tier come from enrow.io (verified August 29, 2026) and were re-read on the live Email Verifier page the same day. Every per-verification and per-email figure in the cost tables is division on those two inputs. They are arithmetic, not published prices, and the tables say so.
Related reading in this cluster: bulk email verification for the list-hygiene workflow, email bounce rate for the thresholds, how to choose a B2B data provider where catch-all handling is one of the evaluation criteria, and email finder API for the catch-all signals in the response payload.
Stop deleting the segment. Run your accept-all rows through Enrow at 0.25 credit each, on 50 free credits every month, no card.
