About 38% of email domains are configured to accept mail at any address you send to, according to Hunter’s analysis of over 2,500 domains. These are catch-all (or accept-all) domains: the mail server accepts every message during the SMTP handshake, whether or not the specific mailbox actually exists. That single design choice is why a catch-all address can’t be verified the normal way. Standard verification relies on the server rejecting invalid addresses outright; a catch-all server accepts everything, so a verifier has no way to distinguish a real inbox from a typo. That’s why these addresses show up as “unknown,” “catch-all,” “accept-all (unverifiable),” or “risky” instead of “valid,” and why sending to them carries meaningfully higher bounce and spam-trap risk than sending to a confirmed list.
How a Catch-All Domain Behaves at the SMTP Level
Standard address verification works by opening an SMTP connection to a domain’s mail server and issuing a RCPT TO command for the address in question, without sending an actual message. RFC 5321, the specification for SMTP, defines the reply for a nonexistent recipient: “If the recipient is known not to be a deliverable address, the SMTP server returns a 550 reply, typically with a string such as ‘no such user’ and the mailbox name.” On a normally configured domain, that 550 response is how a verifier learns an address doesn’t exist, before any real message goes out.
A catch-all domain skips that check entirely. Its mail server accepts the RCPT TO command for any local part, returning the same 250 OK response for a real address and for a string of random characters at the same domain. Regex-based validation can confirm an address is correctly formatted, but it never touches the mail server, so it can’t detect catch-all behavior either.
| Verification Step | Normal Domain | Catch-All Domain |
|---|---|---|
| RCPT TO on a real address | 250 OK | 250 OK |
| RCPT TO on a nonexistent address | 550 no such user | 250 OK (accepted anyway) |
| What a verifier can conclude | Valid or invalid | Unknown / catch-all |
| Safe to send without further checks | Yes | No |
Why Domains Are Set Up to Accept Everything
Catch-all configuration isn’t inherently a red flag. Hunter’s guide to accept-all domains traces the original intent: “Accept-all mailboxes were first a method to prevent legitimate emails from bouncing because of a mistyped or mistaken address.” A small company routing every unrecognized address to a shared inbox, or a solo consultant catching typos in their own name, has a legitimate reason to run a domain this way.
The purpose has since expanded. As Hunter notes, catch-all now also serves defensively: “its purpose is to prevent email finders from using brute force methods to find valid addresses set up on the domain.” If every address returns 250 OK, a tool guessing at name combinations learns nothing from the attempt. That’s a deliberate anti-scraping measure on the domain owner’s side, not evidence of a poorly maintained mailbox.
Either way, the result for anyone sending to that domain is the same: the SMTP response alone can’t tell you whether the address you’re mailing belongs to an actual person.
Why Verification Tools Return “Unknown” Instead of “Valid”
Email verification vendors handle this ambiguity with a distinct status rather than forcing a false valid or invalid call. ZeroBounce’s documentation states the underlying problem directly: “Catch-all domains are email domains that always return a ‘Valid’ response from the SMTP service, whether the address is valid or invalid.” Because the SMTP layer can’t distinguish them, ZeroBounce classifies these addresses as Catch-all rather than Valid, with a secondary check available that can reclassify some of them using additional signals.
NeverBounce uses a comparable category it calls Accept All (Unverifiable): “A Catch-All (or Accept-All) email address is one that the receiving mail server accepts emails for, regardless of whether the mailbox exists,” and once a domain is flagged this way, every address on it gets reported as an accept-all result. Each address receives the same label, real or not, because the verification method has hit its limit, not because the individual address has been assessed.
The Bounce and Spam-Trap Risk of Sending Anyway
Treating a catch-all result as good enough to send is where the risk shows up. Hunter’s testing found that emails sent to accept-all addresses are roughly 27 times more likely to bounce than emails sent to validated addresses, a 27% bounce rate for accept-all addresses against about 1% for addresses a verifier had confirmed. A bounce rate that high, even on a portion of a send, is enough to push a campaign’s total bounce rate past the thresholds mailbox providers watch.
The exposure isn’t limited to bounces. A spam trap that has gone dormant and been recycled by its mailbox provider behaves exactly like a catch-all address from the sender’s side: it accepts mail at the SMTP level and never bounces, so nothing in a bounce report flags it. Some catch-all domains contain exactly this mix, real inboxes, dead addresses, and recycled traps, all returning the identical 250 OK.
What to Do With Catch-All Addresses Before Sending
Most verification vendors converge on the same recommendation: don’t drop catch-all addresses automatically, but don’t mail them the same way as confirmed-valid addresses either.
Segment them into their own send. Keep catch-all addresses out of your primary campaign and send to them separately, at lower volume, so a bad outcome doesn’t touch deliverability for your verified contacts.
Watch bounce and complaint rates in real time. Sending platforms enforce their own limits regardless of what a verifier told you upfront. Postmark’s account requirements are explicit: “Postmark requires that you keep your bounce rate below 10%,” alongside a spam complaint rate below 0.1%, and sending gets suspended when either is crossed.
Protect the domain’s sender reputation first. A batch of catch-all sends that spikes bounces or complaints doesn’t just cost that campaign; it degrades the reputation your transactional and lifecycle email depend on too.
Re-verify before a second send. A catch-all classification today doesn’t guarantee the domain stays that way. Mail providers and configurations change, so re-running verification closer to send time catches those shifts.
Reading Catch-All Results During List Verification
A single catch-all result on an otherwise verified list is unremarkable. It becomes a signal worth investigating when the rate is unusually high: since roughly 38% of domains are catch-all-configured on average, a B2B list where catch-all results make up half or more of the total was more likely built from an old export, a scraped source, or a tool guessing at address formats rather than confirming them.
The practical rule: treat the catch-all percentage on a new list as a proxy for how the list was built, not just a per-address annoyance. A list built from confirmed opt-ins or manually collected addresses should land close to that domain-level average. A list assembled by guessing common name patterns at a company’s domain will run far above it, because the tool has no way to know which guess is correct and gets the same unverifiable result for every attempt against a catch-all-configured company.
Frequently Asked Questions
What does “catch-all” mean on an email verification report?
It means the receiving mail server accepted the address during the SMTP check, but the same server would accept literally any address at that domain, so the verifier can’t confirm the specific mailbox is real. Depending on the tool, you’ll see it labeled catch-all, accept-all, unknown, or risky. All four describe the same underlying limitation.
Is it safe to send to a catch-all email address?
It depends on volume and risk tolerance. A handful of catch-all addresses mixed into an otherwise verified list rarely causes problems. Sending a large batch of them as if they were confirmed valid is what drives up bounce rates. Hunter’s testing found accept-all addresses bounce about 27 times more often than validated ones, so segmenting them into a smaller, separate send is the safer approach.
How do I know if a domain is catch-all before sending?
Most email verification tools test this automatically by checking whether a deliberately invalid address at that domain also returns a 250 OK response. If it does, every address on the domain gets flagged as catch-all rather than valid, regardless of whether the specific address you’re checking is real.
Can a catch-all email address still bounce?
Yes. The SMTP-level “accept everything” behavior only means the server didn’t reject the address during the initial handshake. If the actual mailbox doesn’t exist behind that catch-all configuration, or the message is discarded after acceptance, it can still bounce or fail silently later in the delivery process.
Should I remove catch-all addresses from my list?
Not automatically. Removing every catch-all result can cut real, reachable contacts from your list, since roughly 38% of domains are configured this way. The better approach is to segment catch-all addresses into a separate, lower-volume send and monitor bounce and complaint rates closely rather than deleting them outright.
Why do some companies set up their domain as catch-all on purpose?
Two common reasons: making sure mail sent to a mistyped version of a real address still reaches someone, and making it harder for prospecting tools to guess valid addresses by brute force, since every guess returns the same accepted response. Neither reason means the domain is poorly maintained.
I’ve spent my career building software at scale with a soft spot for email: deliverability, lifecycle campaigns, and getting messages to actually land. I started Coldletter to fix what bugged me about transactional and marketing email tools. I’m based in Vancouver.