When you verify an address and get back catch-all (some tools call it accept-all), the result isn’t “bad” — it’s “unknown, and unknowable over SMTP.” The domain is configured to accept mail for every possible address at that domain, then sort or discard it on the inside. So a probe for jane@company.com and a probe for doesnotexist9999@company.com both come back accepted. You genuinely cannot tell, from the outside, whether Jane’s mailbox exists. Whether you should send comes down to how much a bounce costs you and how strong your other signals are.
Why SMTP can’t confirm a catch-all address
Normal verification works by starting an SMTP conversation with the recipient’s mail server and issuing a RCPT TO command for the address — without ever delivering a message. A well-behaved server answers 250 (“I’d accept mail for that mailbox”) or 550 (“no such user”). That 550 is what lets a verifier say an address is undeliverable with confidence.
A catch-all domain removes that signal on purpose. It’s configured to accept every local-part and return 250 regardless, because the admin would rather over-accept than risk rejecting legitimate mail to an address they forgot to provision. The relevant machinery is plain SMTP — see RFC 5321 for how RCPT TO and reply codes work. Because a catch-all never returns 550, no verifier — ours or anyone’s — can prove a specific mailbox is real. Honest tools report this as catch-all rather than pretending it’s deliverable.
Treat an unknown result the same way. Unknown usually means the server timed out, greylisted the probe, or otherwise refused to give a clean answer — so you’re in the same “can’t confirm” bucket as catch-all and should apply the same caution.
The real bounce risk
Catch-all doesn’t mean the mailbox is fake — plenty of catch-all addresses are perfectly real people. It means a slice of them aren’t, and you have no way to know which. On a catch-all domain, a typo, an old address, or a made-up sign-up value all get accepted at probe time and can still bounce (or silently vanish) when you actually send. So a list heavy with catch-all contacts carries a higher effective bounce rate than one of confirmed-deliverable addresses.
That matters because mailbox providers judge you on bounces. Gmail, Yahoo and Outlook throttle or filter senders whose bounce rate climbs — keeping it under roughly 2% is the widely cited target. Blast an unsegmented catch-all list and you can blow past that in a single send, damaging the deliverability of your good mail too. This is exactly why the catch-all question is a reputation question, not just a per-address one.
A decision framework: send, segment, or suppress by value
Don’t make one rule for every catch-all address — weigh the cost of a bounce against the value of the contact:
- Send (with care) when the contact is high-value and you have corroborating signals — a real name, a company match, a recent opt-in, or prior engagement. A verified-real person on a catch-all corporate domain (very common in B2B, where whole companies run accept-all) is usually worth mailing.
- Segment the rest into their own group and warm into them: send to your confirmed-deliverable contacts first, then introduce catch-all addresses in smaller batches while you watch bounces and complaints. Never mix untested catch-all contacts into a big send to your best subscribers.
- Suppress low-value, no-signal catch-all addresses — a lone throwaway sign-up with no name and no engagement isn’t worth the reputation risk. When in doubt at the bottom of the value scale, leave it out.
For the full result-by-result playbook, see how to handle every verification result, and fold this into your list-cleaning workflow before a campaign.
Engagement is the better signal
Because SMTP is a dead end for catch-all domains, let behaviour do the validating. The most reliable proof that a catch-all address is real and wanted is that someone at it opened, clicked, or replied. So the winning pattern is: verify to remove the obviously-bad addresses, mail the catch-all segment cautiously, and then promote the ones that engage into your mainline list while quietly retiring the ones that never do. After two or three sends with zero engagement and any bounces, suppress. You’ve effectively used your own campaign as the verification the SMTP probe couldn’t give you.
Verify and segment before you decide
Start by finding out which of your addresses are catch-all in the first place:
- Run a single domain or address through the Catch-All Email Checker to see whether it’s accept-all.
- Run your whole list through the Email Verifier — it flags each address as deliverable, undeliverable, catch-all, role, disposable or unknown, so you can split them cleanly.
- Pull an Email List Health Report to see what share of your list is catch-all and unknown before you commit budget to a send.
Then apply the framework above: send to confirmed-deliverable first, segment catch-all, suppress the low-value tail.
Failure modes to avoid
- Treating catch-all as deliverable. It isn’t confirmed — mailing it like it is inflates your bounce rate. Segment, don’t assume.
- Treating catch-all as undeliverable. Blanket-deleting every catch-all address throws away real, valuable B2B contacts. Judge by value and engagement, not by the flag alone.
- Ignoring “unknown.” Unknown is catch-all’s cousin — same “can’t confirm” caution applies.
- Dumping a fresh catch-all segment into a big send. That’s how one segment’s bounces poison deliverability for your whole list. Warm in slowly.
- Verifying once and forgetting. A domain’s catch-all status and a contact’s validity both drift over time — re-verify on lifecycle triggers.
Sources
The SMTP behaviour behind all of this — RCPT TO, the 250/550 replies, and why an accept-all server never says no — is defined in RFC 5321 (Simple Mail Transfer Protocol). For the bounce and complaint thresholds that make catch-all a reputation issue, see Google’s Email sender guidelines and Yahoo’s sender best practices. To pull it together for a campaign, use the bounce-rate guide alongside this one.