Catch-All Email Verification: Why Most Verifiers Return "Unknown" and How to Validate Properly [2026]

EmailShield resolves 100% of catch-all domain detection to a binary status (catch_all or not_catch_all) using domain-grouped SMTP probes on self-hosted proxy infrastructure with rotating egress IPs, while ZeroBounce and MillionVerifier publicly document that their primary catch-all output is a separate "risky" bucket that requires a paid add-on to reduce. This article explains why catch-all addresses appear as "unknown" in most verifiers at the SMTP protocol level, compares how ZeroBounce, MillionVerifier, and EmailShield handle the detection, and shows the verification workflow EmailShield runs in production at 99.8% verified accuracy and 100,000 emails per minute bulk throughput.

You uploaded a B2B list of 50,000 addresses into ZeroBounce or MillionVerifier. The job finished. You opened the report. Roughly 15,000 rows came back as "unknown" or "catch-all" or "risky," and the tool is asking you to pay extra credits to "score" or "re-verify" the bucket. That bucket is the most expensive part of any B2B list, and it is also the part the legacy verifiers handle worst.

This article walks through the SMTP protocol mechanics that produce "unknown" results on catch-all domains, the architectural reasons each major verifier returns the bucket the way it does, and how to validate catch-all addresses end to end without paying for a second round of credits on the same list.

What a Catch-All Email Address Actually Is

A catch-all email address (also called an accept-all address) sits on a domain whose mail server is configured to accept every incoming RCPT TO command regardless of whether the specific mailbox exists. The server replies with SMTP 250 OK to john.smith@example.com and xyz123abc@example.com with equal indifference. Anything addressed to the domain reaches some inbox somewhere, typically a shared catch-all mailbox routed to a receptionist, an auto-forwarder, or a black hole.

The configuration is common in three settings. Small businesses use catch-all to make sure typos and stray messages still reach the team. Enterprise organizations in regulated verticals (legal, healthcare, government, finance) deliberately enable catch-all to obscure their internal directory from third-party verifiers. Legacy domains often have a forgotten *@ rule that nobody has removed in a decade.

From a verifier's perspective, catch-all is a problem at the protocol layer. A normal mail server rejects unknown addresses with 550 5.1.1 user unknown and accepts real addresses with 250 OK. The difference between the two SMTP responses is the verifier's primary signal. On a catch-all server, every RCPT TO returns 250, the signal collapses to a constant, and the verifier loses the ability to distinguish real mailboxes from invented ones.

Industry estimates put catch-all domains at 5% to 10% of all observed sending domains in mixed lists, climbing to 30% to 50% on B2B lists concentrated in regulated verticals. EmailShield platform data across mixed B2B verification jobs in the year ending May 2026 shows a median catch-all rate of 8.4%, with a P90 of 27% on industry-specific lists.

Why ZeroBounce and MillionVerifier Return "Unknown" on Catch-All Domains

Both ZeroBounce and MillionVerifier are SMTP-handshake-based verifiers. Their per-email pipeline looks broadly like this: validate syntax, resolve MX records, open an SMTP connection, run the EHLO/MAIL FROM dance, send RCPT TO for the target address, capture the response code, and label the result. On a non-catch-all domain that pipeline works well: 250 maps to valid, 550 maps to invalid, repeated 4xx timeouts map to unknown.

On a catch-all domain that pipeline cannot produce a deterministic answer for the individual address. The 250 response carries no information about mailbox existence. The verifier has three architectural options for how to handle the bucket, and ZeroBounce and MillionVerifier each chose differently from each other.

ZeroBounce's approach

ZeroBounce returns two distinct labels for the difficult bucket. Catch-All means ZeroBounce ran an SMTP probe against a randomly generated address at the domain, got 250, and concluded the domain accepts everything. Unknown means the SMTP probe itself was inconclusive due to server timeout, rate-limiting, greylisting, or anti-verification protection. Both labels show up in the same downloadable CSV under different status codes, and both consume the same standard credit per address.

To reduce the bucket, ZeroBounce offers two paid add-ons. Activity Data is a behavioral scoring layer that returns a Quality Score (0-10) for catch-all addresses based on engagement signals from ZeroBounce's network. Verify+ is a deeper validation pass that runs only if at least 10 catch-all addresses are detected in the initial job, applies additional probes, and reports a refined verdict per address. Both add-ons cost extra credits beyond the standard verification price.

The result for a sender: a 50,000-address B2B list with 18% catch-all penetration produces 9,000 catch-all rows, which then need a second round of paid processing if you want anything resembling a deliverability decision on them. At ZeroBounce's published rate of $649 for 100,000 addresses (about $0.00649 per email), the catch-all reprocessing alone can add hundreds of dollars to a single list.

MillionVerifier's approach

MillionVerifier groups catch-all and unknown together under the broader Risky category. Their public documentation states that MillionVerifier "doesn't charge customers for Risky emails (Unknown and Catch-all), only for Good and Bad emails." That is genuinely useful for cost control on the initial pass, but it does not solve the underlying problem: a Risky row still needs to be resolved before send.

To resolve risky rows, MillionVerifier offers a separate catch-all email verifier add-on. Their published claim is 98% accuracy on catch-all identification and a 70% to 80% reduction in catch-all and business-unknown counts. The add-on is billed separately from standard verification and processes the risky bucket through additional signals (network analysis, behavioral patterns, third-party data enrichment). MillionVerifier's standard pricing at the 100K tier is $149 (about $0.00149 per email).

The result for a sender: cost-efficient first pass, but the same downstream decision applies. Anything in the Risky bucket sits in an "unresolved" state until either you ignore it (and accept the bounce risk if you send), exclude it (and lose 15% to 30% of contacts), or pay for the add-on (and accept the additional spend).

Why both approaches share the same root issue

Neither tool is doing anything technically wrong inside the SMTP protocol. Both are honestly reporting the limits of what RCPT TO can prove on a catch-all server. The disagreement is at the product layer: how much of the catch-all resolution work belongs in the base pricing, and how much sits behind a paid wall. For senders running monthly catch-all-heavy verifications, the cumulative add-on cost can exceed the base verification cost on the same list.

The SMTP Protocol Limit, Made Concrete

Here is the SMTP transcript for a successful verification against a normal (non-catch-all) domain:

> Connect to mx.regular-domain.com:25
< 220 mx.regular-domain.com ESMTP ready

> EHLO verifier.emailshield.co
< 250-mx.regular-domain.com
< 250 STARTTLS

> MAIL FROM: <verify@emailshield.co>
< 250 OK

> RCPT TO: <real.person@regular-domain.com>
< 250 OK                  ← real mailbox

> RCPT TO: <xyz123abc@regular-domain.com>
< 550 5.1.1 User unknown  ← fake mailbox rejected

> QUIT
< 221 Bye

The differentiating response is 550 5.1.1 User unknown on the fake address. The 250 on the real address carries information because the alternative is a rejection. Now the same transcript against a catch-all domain:

> Connect to mx.catchall-domain.com:25
< 220 mx.catchall-domain.com ESMTP ready

> EHLO verifier.emailshield.co
< 250-mx.catchall-domain.com
< 250 STARTTLS

> MAIL FROM: <verify@emailshield.co>
< 250 OK

> RCPT TO: <real.person@catchall-domain.com>
< 250 OK                  ← real mailbox

> RCPT TO: <xyz123abc@catchall-domain.com>
< 250 OK                  ← fake mailbox also accepted

> QUIT
< 221 Bye

Both addresses receive identical 250 responses. The protocol cannot expose enough information to distinguish them. This is a limitation of SMTP itself per RFC 5321, and no amount of retry logic, proxy rotation, or timeout tuning can produce a deterministic per-address answer on a catch-all server.

The fact that the limitation is in the protocol rather than in any specific verifier matters because it tells you what an honest catch-all strategy looks like: stop trying to per-address verify on a catch-all domain, classify the domain itself, and let your sending policy handle the bucket.

How EmailShield Resolves Catch-All Differently

EmailShield treats catch-all as a property of the domain rather than a per-email attribute. The verification pipeline runs four stages, with the catch-all probe sitting between basic checks and SMTP RCPT verification.

Stage 1: Basic checks (per email)

Every address passes through RFC 5322 syntax validation, MX lookup, disposable-domain detection, role-based local-part detection, and spam-trap detection. Addresses that fail syntax or MX are labeled invalid and never reach an SMTP probe. This is cheap and deterministic. For a 50,000-row list, Stage 1 typically clears in under 30 seconds.

Stage 2: Domain grouping and catch-all probe

All addresses that pass Stage 1 are grouped by (domain, MX host). For each unique pair, the orchestrator checks a Redis cache with a 24-hour TTL. On a cache hit, the cached catch_all or not_catch_all status applies to every address on that domain in the current job. On a cache miss, the orchestrator dispatches one catch-all probe: an SMTP RCPT TO for a randomly generated, plausible-but-nonexistent local-part. The probe runs through a self-hosted proxy with a rotating egress IP, retries up to 5 times across different proxies if the response is inconclusive, and writes a binary result back to the cache.

The status field is always binary. EmailShield never emits unknown for catch-all status. If all 5 probe attempts are inconclusive, the default is not_catch_all (which routes the addresses into normal Stage 3 SMTP verification rather than a "risky" purgatory bucket). Confidence on the catch-all label ranges from 0.75 to 0.95 depending on probe consistency and provider signals.

Stage 3: SMTP RCPT verification (per email)

Addresses on not_catch_all domains continue to per-email SMTP verification. The pipeline opens a connection through a proxy, attempts multiple ports in sequence (25, 465, 587, 2525), runs the EHLO/MAIL FROM/RCPT TO sequence, captures the response code and message, and writes a final result. Retries always rotate to a different proxy. The timeout budget escalates per attempt (10s, 15s, 20s).

Addresses on catch_all domains are labeled catch_all with confidence inherited from the domain probe. EmailShield does not attempt to guess valid or invalid based on local-part heuristics (a pattern that competitor "catch-all scoring" features rely on and that produces both false-positive and false-negative inflation).

Stage 4: Deterministic labeling

Every result passes through a single labeling function before being written to the database. The function combines the primary SMTP signal, catch-all status, role/disposable/spam-trap tags, and confidence score into a single deterministic label. The mapping is stable across the API, the dashboard, and the CSV export, with the same label semantics applied to every verification path on the platform.

The result for a sender running a catch-all-heavy B2B list: the catch_all bucket is fully classified at the domain level, never appears as "unknown," and ships in the standard verification credit (no add-on, no second round of processing). At a published rate starting from $0.00018 per email on EmailShield, the cost differential vs the ZeroBounce + Verify+ stack on the same list is substantial.

ZeroBounce vs MillionVerifier vs EmailShield: Head-to-Head on Catch-All

The comparison below covers only the catch-all and unknown-bucket handling. Pricing reflects publicly available rates as of May 2026.

Reading the table: ZeroBounce and MillionVerifier both produce a workable catch-all classification, and both have published add-ons that improve on the base result. The architectural difference at EmailShield is that the catch-all probe lives inside the standard pipeline rather than behind a paid wall, the status is binary by design (no "unknown" escape hatch on catch-all), and the per-domain probe + 24h cache means every address on the same domain in the same job shares one probe cost rather than paying per-row scoring credits.

At 100K addresses with 18% catch-all penetration:

• ZeroBounce: $649 base + Verify+ add-on credits on 18,000 catch-all rows
• MillionVerifier: $149 base (Risky rows free) + catch-all verifier add-on on the 18,000 risky rows
• EmailShield: ~$49 base on the Plus plan, catch-all classification included

Should You Actually Send to Catch-All Addresses?

The catch_all label is not a deliverability verdict. It is an honest statement that SMTP could not confirm the specific mailbox on a domain that accepts everything. Whether to send depends entirely on the source confidence of the address itself.

Industry data published by FullEnrich shows roughly 9% bounce on additional-verified catch-all addresses versus under 1% on confirmed valid addresses. BounceBan's published data puts the upper bound at 23% hard-bounce on unverified catch-all rows from cold lists. A campaign that ignores catch-all classification and sends a 20%-catch-all list will typically post an 8% to 10% bounce rate, above the 2% threshold that triggers reputation damage at Google Postmaster Tools and Microsoft SNDS.

A real production example

An outreach agency client running at roughly $890K ARR manages monthly verification for 18 active B2B clients across SaaS, fintech, legal services, and healthcare verticals. Total monthly verification volume across the book sits around 2.1M addresses, with individual client lists ranging from 8K to 240K rows. Before switching to EmailShield, the agency was paying for ZeroBounce on every list, seeing catch-all penetration varied 5% to 40% by vertical and the agency had no reliable way to predict which clients would generate large catch-all buckets.

After moving the full book to EmailShield, the catch_all bucket resolved inside the standard credit with no add-on. Per-list verification spend dropped 32% across the full agency book. Bounce rate on confirmed-valid sends held flat at around 1.4%, and the agency now routes high-source-confidence catch_all rows (warm referrals, existing partner contacts) into a separate slow cadence rather than discarding them outright.

A second production example

A mid-market B2B SaaS company at roughly $14M ARR (vertical: revenue operations tooling) ran a quarterly re-engagement campaign against a 47,000-record partner database. The database had accumulated four years of partner registrations, conference badge scans, channel program signups, and inbound demo requests, with no list hygiene between cycles. Catch-all penetration sat at 34% across the full database and climbed to 51% on the enterprise-tier partner subset, where large companies with strict directory privacy policies were heavily over-represented.

The team had previously sent re-engagement without catch-all segmentation and posted a 6.8% bounce rate on the prior cycle. For the next cycle, they ran the full database through EmailShield List Cleaning, exported the catch_all bucket as a separate segment, and built a two-track cadence: confirmed-valid rows received the standard re-engagement sequence at full volume, and catch_all rows from high-source-confidence segments (paid customers, named channel partners, closed-won accounts) routed into a slow warm-up cadence at 5% of normal send volume per batch.

The next cycle's combined bounce rate came in at 1.1% across both tracks, with the catch_all warm-up track contributing 2.4% bounce within its own bucket.

How to Verify Catch-All Emails End to End (the Workflow)

The verification flow below works whether you are coming from ZeroBounce, MillionVerifier, or building list hygiene from scratch. EmailShield's Single Email Verification handles per-address API/dashboard checks, and List Cleaning handles bulk pipelines.

Step 1: Upload the raw list

Upload your CSV (up to 25,000 rows per list) into List Cleaning. Format validation, whitespace normalization, lowercase conversion, and duplicate detection run first. Common typos in the gmail/yahoo/hotmail/outlook variants are auto-corrected and flagged in the output with a typo_fixed tag. This stage drops blank rows, removes exact and case-insensitive duplicates, and saves credits on the SMTP verification pass.

Step 2: Let domain grouping run

All addresses pass through Stage 1 basic checks first (syntax, MX, disposable, role, spam-trap). Addresses that pass are grouped by (domain, MX host) for the catch-all probe. For a 25,000-row list with 8% catch-all penetration across 3,400 unique domains, EmailShield runs roughly 3,400 catch-all probes (one per unique domain, MX pair) instead of 25,000 per-address probes. The cache shares results across the rest of the job and across subsequent jobs for 24 hours.

Step 3: Review the segmentation in the output

The output CSV carries five primary labels: valid, invalid, catch_all, inbox_full, disabled. It carries tags that can co-occur with any label: role, disposable, spam_trap, typo_fixed. It carries a confidence column (0.0 to 1.0) and a reason column that explains the verdict in plain language ("Mailbox confirmed", "Domain accepts all addresses", etc.).

For a sender focused only on deliverable rows, filter status = valid and export. For a sender willing to include catch-all rows from trusted sources, filter status IN (valid, catch_all) and segment further by confidence. For audit purposes, export the full file with all rows annotated.

Step 4: Apply policy to the catch_all bucket

This is the step most verifiers handle for you with a guess. EmailShield exposes the data and lets policy decide. For high-confidence sources (form submissions, customer database), include catch_all rows in the send. For low-confidence sources, exclude. For mixed sources, run the catch_all bucket through a separate warm-up cadence with conservative volume (5-20 addresses per send batch) and monitor bounce and complaint signals before scaling.

Step 5: Real-time verification at the form layer

For new addresses entering your CRM via form submission or signup, use the POST /v1/verify/single endpoint. Sub-2-second response, real SMTP handshake, multi-port attempts, catch-all probe inline. The response carries the same label structure as bulk verification:

curl -X POST https://api.emailshield.co/v1/verify/single \
  -H "X-API-Key: evf_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{"email": "user@example.com"}'

{
  "email": "user@example.com"
  "label": "catch_all"
  "tags": []
  "confidence_score": 0.88
  "reason": "Domain accepts all addresses"
  "details": {
    "mx_host": "mx.example.com"
    "smtp_code": "250"
    "catch_all": true
  }
}

The form layer can read the confidence_score and details.catch_all flag and apply your sending policy directly: accept the signup but tag the contact for low-priority cadence, or accept and route through warm-up, or accept and prompt the user for a secondary contact method.

Methodology

All EmailShield data points in this article (99.8% verified accuracy, 100,000 emails per minute bulk throughput, sub-2-second single-email response time, $0.00018 per-email starting cost, multi-port SMTP attempts 25/465/587/2525, 24-hour Redis cache TTL, 5-attempt probe retry budget, confidence range 0.75 to 0.95 on catch-all) come from EmailShield's production platform configuration as of May 2026.

Competitor data (ZeroBounce Verify+ behavior, ZeroBounce Activity Data Quality Score, MillionVerifier Risky bucket policy, MillionVerifier catch-all verifier add-on accuracy claim, per-email pricing) comes from each vendor's own published documentation linked inline (ZeroBounce catch-all docs, MillionVerifier risky emails docs, MillionVerifier catch-all help) as of May 2026. Pricing reflects publicly listed rates and is subject to change.

Bounce rate benchmarks (9% on additional-verified catch-all, 23% on unverified catch-all from cold lists, 2% Gmail/Microsoft reputation threshold) come from FullEnrich's published bounce data, BounceBan's published catch-all verification benchmarks, and Google Postmaster Tools reputation guidelines.

SMTP protocol references are drawn from RFC 5321 (Simple Mail Transfer Protocol) and RFC 3463 (Enhanced Mail System Status Codes).

Last updated: May 2026.

Written by Pavel Stoletov, CTO at EmailShield, where he leads verification and deliverability engineering. Pavel architected the multi-port SMTP pipeline, domain-grouped catch-all probe system, and self-hosted proxy infrastructure that EmailShield runs in production. Read more at emailshield.co/authors/pavel-stoletov or connect on LinkedIn.