Catch-all email verifier: how to actually validate accept-all domains

• Why is catch-all hard? SMTP cannot distinguish a real mailbox from a non-existent one on a catch-all domain. The protocol is the limit, not the tool.
• Can any verifier reach 100% accuracy on catch-all? No. Industry consensus on r/emailmarketing is that any tool advertising 100% catch-all accuracy is overstating what the protocol allows.
• What's the right verdict for catch-all? 'Risky' or 'Unknown' — never 'Valid'. A false positive on a catch-all costs you sender reputation; a false negative costs you one lost contact.

A catch-all (sometimes called accept-all) domain is configured to accept mail to any address at that domain, even mailboxes that were never created. When a verifier runs the standard RCPT TO probe, the server returns 250 OK for every address — [email protected], [email protected], and [email protected] all come back the same way.

This is a deliberate server configuration, not a bug. Companies enable catch-all to avoid losing mail addressed to typos or to former employees. The downside, from a verification perspective, is that SMTP loses the one signal it normally relies on.

A naive verifier that only runs SMTP returns 'Valid' for every catch-all address. Senders trust the green label, send, and watch their bounce rate climb a week later when the receiving server quietly drops mail to the addresses that don't exist.

A cold-email agency posting on Reddit (r/emailmarketing thread) described running a B2B list through two well-known verification tools, both of which marked catch-all addresses as valid. After sending, bounces climbed to 8%, the domain reputation slipped, and Gmail started filtering follow-ups to spam. The lesson the practitioner posted afterward: a green label can still burn you.

Three things go wrong:

1. The verifier ran SMTP, got 250 OK, and stopped there.
2. There was no secondary check (domain age, MX inspection, mailbox-pattern matching) to flag uncertainty.
3. The user assumed 'valid' was a guarantee instead of a probabilistic verdict.

The fix isn't a better SMTP probe — that's not technically possible. The fix is to combine SMTP with at least three other signals before assigning a verdict.

A working catch-all verifier runs four checks in sequence and weights the result:

1. Detect catch-all status. Probe the domain with a deliberately invalid address ([email protected]). If the server says yes, the domain is catch-all.
2. Run the actual address. Send RCPT TO for the real address. On a catch-all this also returns 250 OK, but the result is now in context.
3. Inspect domain signals. Domain age, MX provider, presence of common role addresses (info@, support@), and historical bounce data on similar addresses.
4. Pattern-match the mailbox. Compare the local part to known patterns (firstname.lastname, first initial + last name) for that domain. Mailboxes that match the pattern get a higher trust score; random strings get flagged.

The combined signal becomes a verdict — typically Valid, Risky, or Unknown. user.cleaning's approach assigns catch-all addresses to the Grey list category by default, with the underlying signals exposed in the API response so you can apply your own threshold.

Three properties separate a working catch-all verifier from a basic SMTP-only checker:

1. Catch-all status returned as a separate signal, not collapsed into a binary valid/invalid verdict.
2. Supporting signals exposed — MX provider, domain age, mailbox-pattern match, role-address detection — so you can score by your own threshold rather than accepting the verifier's default.
3. A defined 'risky' category distinct from 'valid' and 'invalid', so catch-all addresses route to a separate decision branch in your pipeline.

user.cleaning's verifier returns catch-all status as is_catch_all: true alongside the Grey-list category, with the supporting signals exposed in the API response so you can apply your own confidence threshold per use case.

There are real situations where catch-all-but-probably-real is good enough. If the address came from a known good source — a contact form submission, a LinkedIn export of named employees, a data provider with engagement history — you can usually send and accept the higher bounce risk.

You should not send to catch-all addresses when:

• You're warming a new domain or IP. Bounces during warmup permanently scar reputation.
• You're sending high-volume promotional mail. Bounce thresholds tighten with volume.
• You're sending to a freshly-bought or scraped list. Catch-all + cold = the worst-case combination.

You can usually send when:

• The address is enriched from named-contact data (LinkedIn, Crunchbase, ZoomInfo).
• The mailbox pattern matches the company's standard format.
• You've sent successfully to other addresses on the same domain in the last 60 days.
• Your sending volume is low enough that 5–8% bounces won't cross your provider's threshold.

A practitioner on r/emailmarketing reported dropping their bounce rate from 2.1% to 0.9% by suppressing catch-all addresses entirely. The trade-off was losing roughly 30% of their B2B list — but their inbox placement on the remaining 70% improved enough that total responses went up.

This is the right call when you're cold-emailing into a new vertical, when you can't afford a reputation hit, or when your CRM costs scale by contact count. Suppression is reversible: re-run verification quarterly and re-import any address that flips to Valid (rare, but it happens when a domain disables catch-all).

The free tool at /email-verifier handles single-address checks and returns the Grey-list signal breakdown the API exposes. Bulk list verification via CSV upload and continuous API verification both run against the same underlying pipeline, so the verdict on a single address matches the verdict on the same address in a 100k-row job.

For real-time form validation, the REST API returns a JSON payload identical to the web tool's output. A typical response:

{
  "email": "[email protected]",
  "category": "grey",
  "is_catch_all": true,
  "mx_present": true,
  "domain_age_days": 4127,
  "mailbox_pattern_match": "firstname.lastname",
  "confidence": 0.78
}

The confidence score lets you set your own threshold — a checkout form might accept anything above 0.6, while a cold-email tool might require 0.85.