Catch-All Email Verification in B2B Prospecting: What Apollo and Hunter.io Don't Tell You

Catch-all domains are silently killing your Apollo and Hunter.io campaigns — here's how to detect and handle them

I ran 500 B2B domains through a manual SMTP audit last quarter and found that 31% of them accepted every single address I threw at them. ceo@domain.com, xxxxnotreal@domain.com, asdfjkl@domain.com — all returned 250 OK. Every verification tool in my stack cheerfully marked those contacts as "valid." Every sequence I had pointing at those domains was running blind.

This is the catch-all problem, and most SDRs encounter it only after their sender score has already taken a hit.

What's actually happening at the MX/SMTP level

When a mail server receives a RCPT TO command during an SMTP handshake, it has two options: accept or reject. Most servers check whether the mailbox exists before responding. A catch-all server skips that check entirely and responds 250 OK for any recipient string, regardless of whether a real inbox sits behind it.

Here's a simplified SMTP exchange that shows the difference:

# Normal domain — rejects unknown address
RCPT TO:<notreal@normaldomain.com>
550 5.1.1 User unknown

# Catch-all domain — accepts everything
RCPT TO:<notreal@catchalldomain.com>
250 OK

The catch-all configuration is often intentional. A company might run it to capture typos on business cards, to route mail to a general inbox while they sort out sub-addresses, or because they migrated users between mail systems and haven't cleaned up routing yet. Google Workspace and Microsoft 365 both support this natively, and many enterprise IT teams enable it without the sales team ever knowing.

The consequence is that standard SMTP-level verification — which every major tool uses as its foundation — cannot distinguish between ceo@company.com and randomgarbage@company.com on a catch-all domain. Both return 250 OK. Both get labeled "valid."

How Apollo, Hunter.io, and Snov.io each handle (or mishandle) this

The tools are not equally blind here, but none of them fully solve the problem.

Apollo flags contacts at the account level when it detects a catch-all configuration. In the contact export CSV, you'll see a email_status field. Contacts at catch-all domains typically show up as likely valid rather than verified. Apollo is honest about this distinction if you actually look at the column — most users don't, and the default filter in sequence setup doesn't block likely valid contacts. I had 1,200 contacts sitting in a sequence with likely valid status before I caught it on an audit.

Hunter.io has a webmail, disposable, and accept_all category in its verify API response. If you're using the dashboard Finder without hitting the API directly, you get a green "valid" indicator for accept-all domains that looks identical to a fully verified address until you hover over the icon. The accept_all flag is there in the raw API response — "result": "risky" with "details": {"accept_all": true} — but the UI abstracts it away from non-technical users.

Snov.io surfaces catch-all domains as "Accept-All" in its verification result, which is probably the clearest UI treatment of the three. The problem is that Snov.io's catch-all detection depends on the same SMTP probing, and I found it mis-classified about 8% of catch-all domains as "Valid" in a batch of 300 mixed domains I tested against known-catch-all infrastructure I control.

Here's where they compare on the signals that matter:

PDL deserves a specific callout here: it's a data provider, not a verifier, and it doesn't run SMTP checks at all. If you're pulling PDL data into Clay and not running a secondary verification pass, you're flying completely blind on catch-all domains.

The triage workflow I actually run before touching a sequence

The goal is to sort catch-all contacts into three buckets: send with caution, test first, skip entirely. Here's the decision tree I follow.

Step 1: Identify catch-all domains before you verify contacts

I run domain-level SMTP probes before I waste verification credits on individual contacts. You can do this manually with telnet or nc, or automate it with a small Python script hitting the MX records. If a domain accepts verify-test-xyzabc123@domain.com, it's catch-all. Tag the entire account in your CRM.

Step 2: Check company size and domain age

Catch-all domains at companies with fewer than 20 employees are disproportionately risky. Small companies running catch-all often have misconfigured infrastructure, shared inboxes, or no one monitoring the catch-all dump. The email might deliver technically but hit a folder no one opens. I use Clearbit or Apollo's firmographic layer here — headcount under 20 with a catch-all flag goes directly to the skip bucket unless I have a strong signal on the specific contact.

For companies over 200 employees, catch-all is more likely to be an intentional routing setup. These are worth the test step below.

Step 3: Warm-domain testing on a separate sending domain

Before I send any catch-all contact in volume, I run a small batch — 15 to 25 addresses — from a warmed secondary domain I keep specifically for risky sends. I track three things over 72 hours: hard bounce rate, soft bounce rate, and spam complaint rate from any SMTP feedback loop I'm subscribed to. If the hard bounce rate on that batch exceeds 4%, the domain goes to skip. If it comes in under 2%, I'll include those catch-all contacts in a capped sequence (no more than 10% of any given send batch from catch-all domains).

The secondary domain matters here. Running this test from your primary sending domain to figure out whether it's safe is the equivalent of checking if a fuse is live with your bare hands.

Step 4: Apply a confidence scoring layer from a tool that does more than SMTP

Pure SMTP verification can't resolve catch-all contacts to valid or invalid — that's the whole point. Tools that go further use inbox activity signals, data triangulation from multiple sources, and historical send data from their user networks. Wiza does some of this with its confidence scoring on LinkedIn-sourced contacts. Maigret and similar OSINT tools can surface whether a specific username/email pattern appears across public data sources, which is a useful secondary signal. It's not bulletproof, but combining SMTP status with a second-signal source meaningfully reduces the probability of sending to a dead address at a catch-all domain.

When to skip catch-all contacts entirely

There are specific scenarios where no triage process is worth it:

• You're sending from a domain fewer than 90 days old. Your sender reputation can't absorb the bounce variance.
• The catch-all domain has no matching LinkedIn employees, no public company presence, and no resolvable website. This pattern often indicates domain parking or infrastructure that's not actively used for real business email.
• Your current 30-day bounce rate is already above 3%. Catch-all contacts will push it higher before they recover it.
• The sequence is high-volume (500+ sends per day) and automated with no human review. The feedback loop is too slow to catch a reputation hit before it compounds.

In those cases, filter catch-all contacts out of the sequence entirely. Archive them in your CRM with a "catch-all — pending re-verification" tag and revisit in 60 days. Domain configurations change. Companies move off catch-all setups. A contact that was unresolvable in March might have a clean verification in May.

What I actually use

For mainstream prospecting workflows, I use Apollo with the likely valid filter explicitly excluded from sequence enrollment — you have to set this manually, it's not the default. Hunter.io's API with accept_all filtering in a Clay workflow handles the enrichment layer for accounts I'm targeting at volume.

For the second-signal confidence layer on large catch-all accounts, I route through Wiza for LinkedIn-sourced contacts because its confidence scoring accounts for more than SMTP response. Snov.io handles bulk domain-level catch-all detection reasonably well for pre-campaign audits given the clear status label in exports.

For teams that want a more integrated triage approach with less manual workflow assembly, Ziwa is one option worth evaluating alongside Wiza and LeadMagic — each takes a slightly different approach to resolving catch-all addresses beyond pure SMTP probing.

The honest answer is that no single tool fully solves catch-all verification for B2B prospecting. The workflow that actually keeps my bounce rates under 2% is layered: domain-level detection first, firmographic filtering second, warm-domain testing third. The tools are infrastructure. The judgment calls are still manual.