Every cold emailer eventually hits the same wall. You run your prospect list through a verification tool, and instead of a clean split between valid and invalid, a huge chunk comes back labeled **catch-all** - sometimes called "accept-all" or "risky." Across BounceZero's verification data spanning 50M+ emails, roughly **23% of B2B domains** are configured this way, and in some verticals - legal, finance, enterprise SaaS - the share climbs past 35%.
The frustration is understandable. You paid to verify a list and got back a shrug. But the shrug isn't your verification tool being lazy; it's a fundamental property of how the receiving mail server is configured. A catch-all server accepts mail for *any* address at its domain during the SMTP conversation, which means the standard verification handshake physically cannot distinguish a real mailbox from a fake one.
What you do with that 23% is one of the highest-leverage decisions in your cold email program. Skip every catch-all and you discard a fifth or more of your addressable market - often the *best* fifth, since large enterprises disproportionately use catch-all configurations. Blast every catch-all and you'll eat hard bounces that known-invalid suppression would have caught, pushing your bounce rate toward the 2% threshold where Google and Microsoft start throttling your entire domain.
This article goes deep on the technical mechanics of catch-all domains: what actually happens at the SMTP layer, why the configuration exists, how modern multi-probe fingerprinting narrows the uncertainty, and - most importantly - a concrete decision framework for whether to skip, send, or segment. The data throughout comes from email industry benchmarks and BounceZero's own verification telemetry across 50M+ verified addresses.
What a Catch-All Domain Is, Technically
To understand catch-all behavior, you need to understand the SMTP conversation that happens when any mail server - or any verification tool - checks an address. The verifier connects to the domain's MX server on port 25, issues EHLO, then MAIL FROM, then the critical command: RCPT TO:<[email protected]>. A conventionally configured server checks its directory at this point. If the mailbox exists, it replies 250 OK. If it doesn't, it replies 550 5.1.1 User unknown - a definitive, machine-readable "this person is not here."
A catch-all server short-circuits that lookup. It replies 250 OK to every RCPT TO command, regardless of whether the local part maps to a real mailbox. You could probe [email protected] and [email protected] in the same session and get identical acceptance for both. The directory check either doesn't happen at the SMTP boundary at all, or happens *after* acceptance - during internal delivery - at which point the message is silently discarded, routed to a shared inbox, or bounced asynchronously back to the sender.
That last behavior is the one that matters for cold email. Acceptance at RCPT TO is not delivery. On many catch-all domains, mail to a nonexistent mailbox is accepted at the edge and then bounced minutes or hours later with a delayed NDR (non-delivery report). Your sequencer records a send; your ESP records a hard bounce; mailbox providers watching your sending IP record another failed delivery against your reputation. From the receiving server's perspective nothing went wrong - from yours, you just took reputational damage that no standard single-probe verification could have predicted.
Why would anyone configure a server this way? Three main reasons show up in BounceZero's domain intelligence data. First, anti-harvesting: by accepting everything, the server denies spammers the ability to enumerate valid mailboxes via dictionary attacks - a 550 for every guess except real ones is effectively a directory listing. Second, operational safety: companies don't want to lose mail sent to sales@, a misspelled employee name, or a former employee's address, so everything funnels to a monitored catch-all inbox. Third, security gateway defaults: appliances like Proofpoint, Mimecast, and Barracuda often sit in front of the real mail server and accept-then-filter, making the domain *behave* catch-all at the SMTP edge even when the backend Exchange or Google Workspace tenant validates recipients strictly.
The practical upshot: "catch-all" is not a verdict on the email address. It's a verdict on the *domain's configuration* - and it means the question "does this mailbox exist?" cannot be answered by the standard handshake alone.
Why 23% of B2B Domains Are Catch-All - and Why It Skews Toward Your Best Prospects
Across BounceZero's verification data on 50M+ emails, 22.8% of unique B2B domains exhibit catch-all behavior at the SMTP edge. But that average hides a distribution that matters enormously for cold email targeting, because catch-all prevalence correlates strongly with company size and security posture.
Among companies with fewer than 50 employees - typically running vanilla Google Workspace or Microsoft 365 with default settings - catch-all rates run around 9-12%. Google Workspace, notably, rejects unknown recipients by default, which is why so many SMB domains verify cleanly. But among enterprises with 1,000+ employees, catch-all prevalence jumps to 40-55% in our telemetry. The driver is almost always a secure email gateway (SEG). Proofpoint alone fronts a large share of the Fortune 500, and its default "accept and filter" posture makes the protected domain look catch-all to any external prober. Mimecast, Barracuda, Cisco IronPort, and Sophos behave similarly in common configurations.
Vertical patterns are just as stark. In email industry data, legal services (~38%), financial services (~35%), healthcare (~31%), and government (~29%) show the highest catch-all rates - precisely the industries with the strictest compliance requirements and the heaviest gateway adoption. Ecommerce and local services sit at the bottom, under 10%.
This creates an uncomfortable asymmetry for B2B outbound teams: the higher up-market you sell, the more of your total addressable market hides behind catch-all configurations. A SaaS company selling into mid-market and enterprise accounts will routinely see 30-40% of a well-targeted prospect list come back catch-all - not because the data vendor did a bad job, but because that's simply what enterprise mail infrastructure looks like in 2026.
There's a second, less discussed driver: domain-based deal protection. Some companies deliberately run catch-all on secondary and legacy domains (acquired brands, regional TLDs) and forward everything to the primary tenant. Addresses on these domains are often perfectly deliverable - mail to [email protected] lands in a real inbox at the parent company - but they will never verify as a confirmed mailbox.
The takeaway is strategic, not just technical. If your policy is "never email a catch-all," you're not applying a neutral quality filter - you're systematically excluding enterprises, regulated industries, and acquired-brand domains from your pipeline. For most B2B teams that's the exact opposite of their ICP priorities. The right answer isn't to skip or to send indiscriminately; it's to narrow the uncertainty first, which is where multi-probe fingerprinting comes in.
Why Single-Probe Verification Fails on Catch-Alls - and How the 3-Probe Method Works
Most verification tools handle catch-all detection with a single trick: probe one obviously fake address like [email protected]. If the server accepts it, flag the domain catch-all and mark every address on it "risky." That's technically correct but analytically lazy - it detects the *configuration* and then gives up on the *address*. It's also fragile: greylisting, rate limits, and gateway tarpitting can make a single probe return misleading results. Industry-standard tools hover around 95% accuracy partly because of exactly this failure mode.
BounceZero's 3-probe catch-all fingerprinting - one of the six checks in every verification, alongside mailbox existence, role detection, disposable detection, MX validation, and spam trap screening - takes a different approach. Instead of one probe, we run three structurally distinct probes against the domain and compare *how* the server responds, not just *whether* it accepts:
Probe 1 - the target address itself. We record the full response: status code, extended status (e.g., 250 2.1.5), response latency at RCPT TO, and any server banner fingerprint identifying the MTA or gateway (Proofpoint, Mimecast, Exchange Online Protection, Postfix, etc.).
Probe 2 - a high-entropy synthetic address that cannot plausibly exist. This establishes the domain's baseline behavior for unknown recipients. Acceptance here confirms catch-all behavior; the *timing and phrasing* of that acceptance becomes the fingerprint.
Probe 3 - a differential probe designed to detect the servers that accept everything but don't treat everything equally. A meaningful subset of catch-all configurations - particularly Exchange servers with recipient filtering partially enabled, and gateways doing real-time directory lookups - leak information through response timing deltas, differing enhanced status codes, or session-level behavior between known-good and known-bad recipients. When RCPT TO for a real mailbox resolves measurably differently than for a synthetic one, the domain isn't a true black box; it's a *leaky* catch-all, and the target address can often be classified with high confidence.
These SMTP-layer signals then feed BounceZero's scoring engine along with domain intelligence (MX topology, gateway identification, DMARC posture) and independent existence evidence - signals that indicate the mailbox has a life outside the SMTP conversation entirely. The result isn't a binary flip from "risky" to "valid"; it's a calibrated confidence score on each individual address.
In practice, this resolves a meaningful share of addresses on catch-all domains that single-probe tools would blanket-flag as unknowable - which directly translates into pipeline you'd otherwise discard. It's a core reason BounceZero holds up to 99.8% accuracy in internal testing on SMTP-verifiable addresses against the ~95% industry benchmark, at $3 per 1,000 verifications and a provider-dependent API response time time. You can see the full check breakdown in our [API documentation](/api-email-validation).
The Numbers: Catch-All Bounce Rates vs Known-Invalid Rates
To make a rational skip-or-send decision, you need the actual failure rates - and they're more nuanced than most cold email advice suggests.
Start with the baseline. An address that verification flags as invalid (550 at RCPT TO, no MX, dead domain) bounces essentially every time you mail it: 97-99% hard bounce rates in email industry data. There is no debate here - sending to known-invalids is pure self-harm.
Now the catch-all population. Across BounceZero's verification data and post-send feedback loops on 50M+ emails, unscored addresses on catch-all domains hard-bounce at roughly 8-15% when mailed blind. The wide range reflects list source quality: catch-all addresses from a recent CRM export bounce near the bottom of that range, while pattern-guessed addresses (firstname.lastname@ scraped or generated by data vendors) bounce near the top, sometimes exceeding 20%.
Compare both to the thresholds that actually matter. Google's bulk sender guidelines demand spam-plus-bounce problems stay minimal, and practical deliverability consensus puts the danger line at a 2% bounce rate - above it, Gmail and Microsoft begin degrading inbox placement for the *entire sending domain*, not just the offending campaign. ESPs and sequencers typically suspend accounts between 3% and 5%.
Run the arithmetic on a realistic list. Say 10,000 prospects: 65% verify valid, 25% catch-all, 10% invalid. You suppress the invalids. If you now mail all 2,500 catch-alls blind at a 12% bounce rate, that's 300 bounces against ~9,000 sends - a 3.3% campaign bounce rate, comfortably into account-suspension territory, caused entirely by the catch-all segment.
But here's the counter-math that the "never send to catch-alls" camp ignores: 85-92% of those catch-all addresses deliver fine. In BounceZero's post-send data, reply rates on scored high-confidence catch-all addresses are statistically indistinguishable from confirmed-valid addresses - enterprise prospects behind Proofpoint reply just like anyone else. Discarding all 2,500 to avoid ~300 bounces means discarding ~2,200 deliverable prospects, disproportionately enterprise ones. If your reply rate is 3% and your lead-to-close economics are typical B2B, that's real revenue left on the table - you can model your own numbers in our [ROI calculator](/roi-calculator).
The conclusion the data supports is neither "skip" nor "send." It's this: the catch-all label alone is not decision-grade information, but a confidence score on each catch-all address is. High-confidence catch-alls behave like valids. Low-confidence catch-alls behave uncomfortably close to invalids. Treat them differently.
The Decision Framework: Skip, Send, or Segment
Here is the framework we recommend, and that our highest-volume cold email customers converge on. It hinges on three variables: your confidence score per address, the health and disposability of your sending infrastructure, and the value of the prospect.
Tier 1 - Send normally: high-confidence catch-alls. Addresses on catch-all domains where multi-probe fingerprinting and corroborating signals produce a high deliverability score. In BounceZero results these carry an explicit confidence score rather than a bare "catch-all" flag. Treat scores in the top band like verified-valid addresses and put them in your main sequences. Observed bounce rates on this tier run 1-3% - near the valid-address baseline.
Tier 2 - Send with guardrails: mid-confidence catch-alls. The genuinely ambiguous middle. These are worth mailing *only* under three conditions: (1) from a secondary, fully warmed sending domain - never your primary brand domain; (2) at reduced daily volume so bounces are diluted across time; (3) with bounce-triggered circuit breakers - if the tier's rolling bounce rate crosses ~4%, pause the segment automatically. Practically, cap this tier at no more than 20-30% of any day's sends from a given mailbox, blended with valid addresses so the mailbox-level bounce rate stays under 2%.
Tier 3 - Skip or route around email: low-confidence catch-alls. Pattern-guessed addresses on strict-gateway enterprise domains with zero corroborating existence signals. Expected bounce rates north of 15% make direct email a losing trade. But "skip" shouldn't mean "discard the prospect" - route these to LinkedIn touches, phone, or intent-triggered re-verification. Addresses churn; a prospect who was unresolvable in March often resolves in June after they've left a footprint. Re-verify quarterly - at $3 per 1,000, re-checking 5,000 skipped prospects costs $15.
Two overrides trump the tiers. First, prospect value: for a named target account worth six figures, a 15% bounce risk on one email from a burner-adjacent warmed domain is trivially acceptable - send it. Second, infrastructure fragility: if you're sending from your primary company domain (you shouldn't be, for cold email), skip everything below Tier 1 without exception, because you cannot afford *any* avoidable reputational damage on the domain your invoices and password resets come from.
One rule with no exceptions: never mail catch-alls from an unwarmed domain. New domains get maximum scrutiny from mailbox providers; a 10% bounce spike in week two of a domain's life can poison it permanently. Warm first - 3 to 4 weeks minimum - then introduce Tier 2 traffic gradually.
The Limited-Send Playbook: Mailing Catch-Alls Without Burning Your Domain
If you've decided to mail Tier 2 catch-alls, execution details determine whether it's a calculated risk or slow-motion self-destruction. This is the operational playbook.
1. Isolate the blast radius. Register 2-3 secondary domains (e.g., trybouncezero.com-style variants of your brand) used exclusively for cold outreach. Point them at real websites (redirects to your main site), configure SPF, DKIM, and DMARC correctly, and warm each for 3-4 weeks before any cold volume. Catch-all traffic goes *only* through these. If one domain's reputation degrades, you rotate it out; your primary domain - and your Tier 1 sequences if you keep them separate - never feel it.
2. Blend, don't batch. The single most common mistake is sending a dedicated "catch-all campaign." A mailbox that sends 200 emails and takes 24 bounces in one afternoon looks radically worse to Google Postmaster Tools than one taking the same 24 bounces spread across two weeks of mixed traffic. Interleave catch-all sends with verified-valid sends at roughly a 1:3 ratio, keeping every mailbox's rolling 7-day bounce rate under 2%.
3. Process bounces in near-real-time. Delayed NDRs are the signature failure mode of catch-all domains - the address "delivers" and then bounces hours later. Your sequencer must catch these asynchronous bounces, immediately halt the remaining sequence steps for that prospect, and write the suppression back to your CRM. A prospect who bounced on step 1 and still receives steps 2 through 5 generates four additional bounces from a single bad address. Multiply across a list and this alone can double your effective bounce rate.
4. Instrument circuit breakers per domain, per mailbox, and per segment. Set automated pauses at a 4% rolling bounce rate on the catch-all segment and 2.5% on any individual mailbox. Most modern sequencers support webhook-driven pausing; if yours doesn't, a daily check is the minimum viable version.
5. Feed delivery outcomes back into verification. Every catch-all address that successfully receives your email without bouncing is now empirically validated - record it. Every delayed bounce is an empirical invalid - suppress it globally, across all your sending domains and tools. Over a quarter, this feedback loop converts your ambiguous Tier 2 pool into known-good and known-bad populations, shrinking the uncertainty you have to manage.
6. Re-verify before every campaign, not just at list import. B2B email addresses decay at roughly 2.5-3% per month as people change jobs - and on catch-all domains you get no 550 to tell you someone left. An address verified in January carries meaningfully more risk by June. Running lists through [bulk verification](/bulk-email-validation) immediately before each send - 1,000,000 addresses per dashboard job, processed in 5-10 minutes - catches both decay and any newly resolvable addresses the fingerprinting can now score.
The Role-Address Overlap: Catch-All's Hidden Multiplier
There's a compounding risk on catch-all domains that most cold email guides miss entirely: the role-address overlap. In BounceZero's verification data, addresses on catch-all domains are disproportionately likely to *also* be role-based - info@, sales@, contact@, admin@, office@ - or to silently *resolve* to one.
The overlap has a structural cause. Remember why companies configure catch-all in the first place: to make sure nothing sent to their domain gets lost. The operational implementation is almost always routing unmatched mail to a shared role inbox. So on a large fraction of catch-all domains, [email protected] - where Jane left two years ago, or never existed - doesn't bounce *or* reach a person named Jane. It lands in a monitored office@ or admin@ queue, read (if at all) by whoever triages that inbox.
This creates three distinct problems for cold outreach. First, wasted personalization at best. Your carefully researched opener about Jane's recent LinkedIn post is read by an office administrator, or by nobody. Delivery metrics look fine - no bounce, maybe even an open from the triage inbox's preview pane - but the campaign is functionally dead on those addresses. This is why raw deliverability numbers on catch-all segments can *overstate* real performance.
Second, elevated complaint risk. Shared inboxes are where cold email goes to get reported. The person triaging info@ has no relationship with your message's ostensible recipient, no context for the outreach, and - critically - often has one-click access to "report spam" or to the company's gateway quarantine controls. Email industry data consistently shows role addresses generating 2-4× the complaint rates of personal addresses. A spam complaint is 10-50× more damaging to sender reputation than a bounce; mailbox providers weight it as an explicit human judgment against you.
Third, spam trap adjacency. Abandoned role addresses on catch-all domains are prime candidates for conversion into recycled spam traps - the address never bounces (the catch-all guarantees that), so list-hygiene-by-attrition never removes it. It just sits in your list, silently accumulating trap hits against your IPs.
The mitigation is a compound filter rather than two independent ones. BounceZero runs role detection and catch-all fingerprinting as separate checks in the same verification pass, so every result tells you when an address is both. Our recommendation: an address flagged *both* role-based *and* catch-all should be excluded from cold sequences unconditionally - the intersection of "can't confirm a human owns this" and "statistically likely to be triaged by a stranger with a spam button" has no positive expected value in outbound. Personal-pattern addresses on catch-all domains remain candidates for the tiered framework above; role addresses on catch-all domains do not.
Not All Catch-Alls Are Equal: Reading the Domain Signals
Treating "catch-all" as one homogeneous category is the second-biggest mistake in this space (after mailing them all blindly). The domain-level context around a catch-all flag changes the risk profile dramatically, and a good verification layer surfaces that context rather than hiding it behind a single label.
Gateway-fronted enterprise catch-alls are the *safest* subclass, counterintuitively. When BounceZero's domain intelligence identifies Proofpoint, Mimecast, or Exchange Online Protection in front of a Fortune-1000 company's MX records, the catch-all behavior is an artifact of the security appliance - behind it sits a strictly managed directory. Pattern-derived addresses at these companies (first.last@) follow rigid, IT-enforced conventions, so a correctly patterned address for a person you've confirmed works there carries low real-world bounce risk despite the scary flag. These are classic Tier 1 or high Tier 2 sends.
True open-relay-style catch-alls on small-business Postfix/cPanel setups are the opposite. No directory, no gateway, mail to anything@ genuinely delivers into one bucket. Here the address's deliverability is nearly certain but its *reachability* - whether your target human ever sees it - is nearly zero unless the address was sourced from something the person actually uses (an email signature, a CRM reply). Source provenance, not verification, is the deciding signal.
Parked and pre-launch domains sometimes exhibit catch-all acceptance with no real mail operation behind them at all. MX records pointing at registrar-default mail services, domains under 6 months old, and domains with no functioning website are red flags that BounceZero's domain intelligence stage weighs heavily downward. Sends here are wasted at best and trap-adjacent at worst - skip.
Legacy and acquired-brand catch-alls - the forwarding configurations discussed earlier - sit in between. The tell is MX records or DMARC/SPF includes pointing at a *different* organization's infrastructure. Addresses here often deliver to real people at the parent company, but you should prefer re-finding the prospect at the parent's primary domain, where verification can give you a confirmed answer.
The practical lesson: when your verification result says "catch-all," the next question should be "what kind?" BounceZero's results expose the underlying evidence - MX topology, gateway identification, domain age and web presence signals, plus the 3-probe fingerprint - precisely so the label becomes the *start* of a decision rather than the end of one. At a provider-dependent response time via the API, this classification happens inline at form-fill or CRM-entry time, not just in batch cleanup, meaning your routing logic (Tier 1/2/3) can execute automatically the moment a prospect enters your system.
Building the Catch-All Policy Into Your Stack
Frameworks fail when they live in a Google Doc instead of your tooling. Here's how to operationalize everything above into a cold email stack that handles catch-alls automatically.
At list acquisition. Every list - purchased, scraped, exported, or enriched - goes through [bulk verification](/bulk-email-validation) before it touches your sequencer. At 1,000,000 addresses per dashboard job with 5-10 minute processing, this is a same-hour step, not a project. Configure your import automation to split results four ways: valid > main sequences; high-confidence catch-all > main sequences (tagged for monitoring); mid/low-confidence catch-all > the guarded secondary-domain track or the non-email channel queue; invalid and role+catch-all > global suppression.
At point of entry. For inbound-adjacent flows - demo forms, lead magnets, chat capture - verify via the [real-time API](/api-email-validation) at submission. The provider-dependent response time fits inside a form-submit round trip, so catch-all classification and routing happen before the lead ever syncs to your CRM. This prevents the slow accumulation of unclassified addresses that makes quarterly cleanups painful.
In the sequencer. Encode the tiers as sending rules: catch-all-tagged prospects only ever attach to secondary-domain mailboxes; blend ratios enforced per mailbox per day; webhook-driven circuit breakers at the 4% segment / 2.5% mailbox thresholds. Most modern sequencers (Smartlead, Instantly, Lemlist, Outreach, Salesloft) support custom fields and conditional mailbox assignment - the plumbing exists, it just needs the policy wired in.
In the feedback loop. Pipe ESP bounce webhooks and delayed NDRs into two places: your global suppression list (immediately) and a delivery-outcome log (for the quarterly analysis). Once a quarter, re-verify the skipped Tier 3 pool and the delivery-outcome log together; addresses migrate between tiers as evidence accumulates. Teams that run this loop consistently report their "unknowable" catch-all pool shrinking by 30-50% within two quarters, because empirical outcomes plus re-verification steadily resolve the ambiguity.
In your reporting. Track bounce rate, reply rate, and complaint rate *segmented by verification status*, not just per campaign. This is the only way to validate that your tier thresholds are calibrated to your specific list sources - a team sourcing from CRM exports can safely run looser catch-all thresholds than a team sourcing from pattern-generation tools, and only segmented reporting reveals which one you are.
The economics of doing all this properly are almost embarrassingly favorable. Verifying 100,000 prospects at $3 per 1,000 costs $300. A single sequencer account suspension costs a week of pipeline; a degraded sending domain costs a month and a domain-migration project; and the 2,200-per-10,000 deliverable enterprise prospects you'd otherwise discard represent the largest number of all. Catch-all handling isn't a hygiene chore - it's one of the few places in cold email where better information directly converts to more pipeline *and* less risk simultaneously.
Frequently Asked Questions
What exactly does a "catch-all" verification result mean?
It means the domain's mail server accepted delivery for every address we tested during the SMTP conversation - including a deliberately fake one - so a standard mailbox-existence check cannot return a definitive valid or invalid verdict for any specific address on that domain. Crucially, it's a statement about the domain's configuration, not about your address. The address might be a perfectly real mailbox, a typo that will bounce hours later via a delayed NDR, or a ghost that routes to a shared admin inbox. BounceZero narrows this uncertainty with 3-probe fingerprinting and domain intelligence, returning a per-address confidence score rather than a bare "risky" flag, so you can make a graduated decision instead of a coin flip.
Should I ever send cold email to catch-all addresses?
Yes - selectively. Across BounceZero's data on 50M+ verifications, 85-92% of catch-all addresses deliver successfully, and enterprise domains (your highest-value targets) are the most likely to be catch-all in the first place, with gateway-fronted enterprises exceeding 40% catch-all prevalence. The rational policy is tiered: send high-confidence catch-alls normally, send mid-confidence ones only from a warmed secondary domain with blend ratios and bounce circuit breakers, and skip low-confidence ones or route those prospects to LinkedIn and phone. The one absolute rule: never send to catch-alls from your primary company domain or from an unwarmed domain.
What bounce rate should I expect from catch-all addresses?
Unscored catch-all addresses mailed blind hard-bounce at roughly 8-15% in BounceZero's post-send data - versus 97-99% for known-invalid addresses and under 1-2% for verified-valid ones. The range depends heavily on list source: addresses from real interactions (CRM replies, email signatures) sit near the bottom; pattern-guessed addresses from data vendors sit at or above the top. Since the practical danger threshold for a sending domain is a 2% bounce rate, mailing an unsegmented catch-all pool will usually push a campaign into reputation-damage territory - which is exactly why per-address confidence scoring, blending, and circuit breakers matter more here than anywhere else in your list.
How does BounceZero's 3-probe method actually resolve catch-all addresses?
Instead of one probe that merely detects the catch-all configuration, we run three structurally different probes - the target address, a high-entropy synthetic address, and a differential probe - and compare response codes, enhanced status codes, and RCPT TO timing across them. A meaningful subset of "catch-all" servers, especially Exchange environments and gateways doing real-time directory lookups, leak measurable behavioral differences between real and fake recipients. Those SMTP-layer fingerprints combine with domain intelligence (gateway identification, MX topology, domain age) and independent existence signals in our scoring engine to produce a calibrated per-address confidence score. It's a core contributor to BounceZero's up to 99.8% accuracy in internal testing on SMTP-verifiable addresses versus the ~95% industry benchmark.
Why are enterprise domains so much more likely to be catch-all?
Because of secure email gateways. Appliances and cloud filters like Proofpoint, Mimecast, Barracuda, and Exchange Online Protection sit in front of the actual mail tenant and commonly accept all recipients at the SMTP edge, filtering afterward - so the domain behaves catch-all to external verification even when the backend directory is strictly managed. In BounceZero's data, catch-all prevalence rises from 9-12% at sub-50-employee companies to 40-55% at 1,000+ employee enterprises, with legal, finance, healthcare, and government verticals highest. Counterintuitively, these gateway-fronted catch-alls are often the safest to mail: behind the gateway is a rigid IT-enforced address convention, so a correctly patterned address for a confirmed employee carries low real-world bounce risk.
How often should I re-verify catch-all addresses I decided to skip?
Quarterly is the sweet spot. B2B addresses decay at roughly 2.5-3% per month as people change roles, but the reverse also happens: previously unresolvable addresses become scorable as prospects leave new footprints and as domain configurations change - companies migrate gateways and mail platforms constantly. Teams that re-verify their skipped pool each quarter, combined with feeding actual delivery outcomes back into suppression and tier assignments, typically shrink their "unknowable" catch-all population by 30-50% within two quarters. At $3 per 1,000 verifications, re-checking even a 10,000-address skip list costs $30 - trivial against the pipeline value of the addresses that graduate into sendable tiers.
Stop Guessing on Catch-All Domains
BounceZero's 3-probe fingerprinting turns "risky" into a real confidence score - up to 99.8% accuracy in internal testing on SMTP-verifiable addresses, results in seconds, and 100 free verifications every month with no credit card.
Learn More