Catch-All vs Accept-All vs Unknown: What Email Verifiers Actually Mean
By Aria Pramesi, founder of InboxPolicy · Updated July 9, 2026
Every verification vendor reports the same handful of unresolved outcomes under different names, catch-all, accept-all, unknown, risky, unverifiable. They are not all synonyms. This page defines each term precisely, shows what vendors actually call it, and explains why the label matters less than the evidence behind it.
The core definitions
- Catch-all domain
- A catch-all domain is a mail domain configured to accept messages for any address, whether or not a real mailbox exists behind it. Because the receiving server won't reject an unknown address at the SMTP level, a verifier can confirm the domain accepts mail but cannot confirm any single mailbox on it actually exists.
- Accept-all domain
- An accept-all domain is the exact same thing as a catch-all domain, described with a different vendor's word choice. ZeroBounce and NeverBounce both use "accept-all" as a status label for this behavior; catch-all is the more common general-purpose term, used by Apollo and across most of the industry, including InboxPolicy. If you see either term, read it as: this domain accepts mail for any address.
- Unknown result
- An unknown result means the SMTP check got no conclusive accept or reject response, for a reason other than the domain being catch-all. The most common cause is greylisting, but a temporary server timeout or a protective mail gateway can also produce it. Unknown and catch-all are different causes that happen to land in the same unresolved bucket.
- Risky result
- Risky is an umbrella label, not a technical cause. Kickbox and MillionVerifier both group catch-all, unknown, and role-address results (like
info@orsupport@) under "risky" to signal send-with-care. The label tells you to be cautious; it doesn't tell you which of those three very different situations you're actually looking at. - Greylisting-caused unknown
- Greylisting is an anti-spam technique where a receiving server temporarily rejects mail from an unfamiliar sender with a 4xx response and expects a retry after a delay. A verification attempt that lands mid-greylist comes back unknown, not because the domain is catch-all, but because the server asked to be tried again later. InboxPolicy tags this evidence distinctly and can return
retry_laterinstead of treating it like a catch-all domain.
Vendor vocabulary: what each tool actually calls it
Verified against each vendor's public documentation where available. Where documentation doesn't specify a detail, that's noted rather than guessed.
| Vendor | What they call it | What it technically is |
|---|---|---|
| ZeroBounce | catch-all status, or valid with an accept_all sub-status | Domain accepts all mail; mailbox unconfirmed |
| NeverBounce | accept_all (labeled "unverifiable") | Domain-wide setting; no way to confirm the specific mailbox |
| MillionVerifier | catch-all, grouped under "risky" alongside unknown | Server accepts mail for non-existent accounts too |
| Kickbox | accept-all: true flag, categorized as "risky" rather than "deliverable" | Email accepted, but domain appears to accept all mail |
| Apollo | "catch-all" email status, filterable in prospecting | Domain accepts all mail; Apollo layers other signals on top to try to resolve individual mailboxes |
| InboxPolicy | catch_all evidence tag → action review (or send_with_caution under an aggressive policy) | Domain accepts all mail; SMTP alone can't confirm the mailbox, so the evidence is surfaced rather than resolved into a guess |
The pattern across vendors: everyone detects the same server behavior, and everyone hedges on what to do about it. Some fold it into "risky," some call it "unverifiable," some try to resolve it with extra signals. None of that changes the underlying fact, SMTP cannot confirm the mailbox.
Why the label matters less than the evidence
A status field tells you what a verifier saw. It doesn't tell you what to do next, and treating "catch-all," "accept-all," or "risky" as interchangeable can lead to sending decisions that don't match the actual risk. A catch-all result and a greylisting-caused unknown look identical if all you get back is one word, but one is a permanent domain configuration and the other might resolve cleanly on a retry.
InboxPolicy separates the label from the decision. Instead of returning a status you have to interpret, it returns one of five explicit actions, send, send_with_caution, review, retry_later, or avoid, along with the underlying evidence tag (catch_all, greylisted, and so on) and a confidence score. A catch-all domain gets review, never a silent send. A greylisting-caused unknown gets retry_later, because that's what actually resolves it. It's $0.01 per fresh decision via x402, no API key or account required, and a cache hit inside 72 hours costs nothing.
Frequently asked questions
What is a catch-all email address?
A catch-all email address sits on a domain configured to accept mail sent to any address, real or not, so the receiving server never rejects an unknown mailbox at the SMTP level. That means a verifier can confirm the domain accepts mail but cannot confirm any single mailbox on it actually exists.
Is accept-all the same as catch-all?
Yes. Catch-all and accept-all describe the identical server behavior, a domain that accepts mail for any address. Different verification vendors just picked different words for it: ZeroBounce and NeverBounce favor accept-all as a status label, while catch-all is the more common general term used across the industry, including by Apollo and InboxPolicy.
What does unknown mean in email verification?
Unknown means the verifier's SMTP check could not get a conclusive accept or reject response, for reasons other than the domain being catch-all, most often greylisting, a receiving server that temporarily defers unfamiliar senders and would need a retry to resolve. It's a distinct cause from catch-all, though both land in an unresolved state that shouldn't be treated as verified-safe.
What is a risky email verification result?
Risky is an umbrella label some vendors, including Kickbox and MillionVerifier, use to group several unresolved outcomes together, typically catch-all and unknown results, plus role addresses like info@ or support@. It signals send-with-care rather than a specific technical cause, which is why the underlying evidence matters more than the label.