What Is a Catch-All (Accept-All) Email Address?

Short answer: a catch-all (accept-all) email address sits on a domain configured to accept mail for *every* possible address at that domain, even ones that were never created. Because the receiving server never says "no such user", ordinary email verification loses the one signal it depends on — which is why nearly every verifier hands those contacts back to you as "risky", "unknown" or "accept-all" instead of valid or invalid.

That single quirk is responsible for a surprisingly large share of the contacts that sit untouched in B2B databases. This guide explains what a catch-all domain actually is, why companies run them, what the ambiguous statuses mean for your sending, and what a definitive answer looks like.

What is a catch-all email address?

Normally, a receiving mail server keeps a list of the recipients it knows about. When a sender offers mail for an address that is not on that list, the server refuses it. That refusal is the backbone of email verification: if the server rejects the recipient, the mailbox does not exist.

A catch-all domain removes that refusal. It is configured to accept anything addressed to the domain, then decide what to do with it afterwards — deliver it to a shared mailbox, forward it to an administrator, run it through filtering, or quietly discard it.

So on a catch-all domain:

• `jane.doe@company.com` is accepted.
• `sales@company.com` is accepted.
• `this-address-never-existed@company.com` is accepted.

All three look identical from the outside. That is the whole problem.

Catch-all vs accept-all vs "all-accept"

These are the same thing under different vendor vocabularies. "Catch-all" is the term mail administrators use, because the domain catches all incoming mail. "Accept-all" is the term verification vendors prefer, because it describes what the server does during a check. If a report gives you "accept-all", read it as "catch-all". There is no technical difference.

Why do companies configure catch-all domains?

Catch-all is not a misconfiguration or a sign of a low-quality domain. In most cases it is a deliberate, sensible choice made by a competent administrator. Common reasons:

• They do not want to lose mail to typos. `jhon@` instead of `john@` still arrives. For a sales or support domain, one recovered enquiry pays for the nuisance.
• Staff churn. When someone leaves, their address keeps accepting mail so that customers writing to an old contact are not bounced.
• Departmental aliases at scale. Organisations that generate many short-lived addresses — per campaign, per vendor, per project — find catch-all simpler than maintaining every alias.
• Privacy and anti-enumeration. Refusing unknown recipients tells an outsider exactly which mailboxes exist. Accepting everything denies attackers that free directory of your staff. This is now a mainstream security recommendation, which is precisely why catch-all has become *more* common, not less.
• It is the default on some hosted setups. Certain providers and small-business plans arrive with accept-all behaviour already switched on.

That last point matters for planning: catch-all is a growing share of business domains, not a shrinking one. Any list-hygiene strategy that treats catch-all contacts as an edge case is planning for the wrong decade.

Why verifiers return "risky", "unknown" or "accept-all"

Standard verification works through a sequence of checks:

1. Syntax — is the address even well-formed? 2. Domain and MX — does the domain exist and publish mail servers? 3. Disposable and role checks — is it a throwaway domain, or a shared `info@`-style box? 4. Mailbox check — will the receiving server accept this specific recipient?

Steps 1 to 3 work fine on a catch-all domain. Step 4 is where it collapses. The server accepts the recipient, but it accepts *every* recipient, so acceptance carries zero information. A verifier has two honest options: guess, or admit the ambiguity.

Reputable verifiers admit the ambiguity. That is why you see labels like:

• catch-all or accept-all — the domain accepts everything; no mailbox-level conclusion
• risky — a bucket that usually mixes catch-all, role-based and low-confidence results together
• unknown — the check could not reach a conclusion at all

If you want the full decode of those labels across the major vendors, we broke them down in Catch-All, Risky, Unknown, Accept-All: What Email Verification Statuses Actually Mean.

Labelling a catch-all "risky" is the correct behaviour for a verifier that cannot resolve it. The problem is not the honesty — it is that the honest answer leaves you with nothing to act on.

What "risky" actually costs you

Once a contact is stamped risky, one of three things happens, and none of them is good.

You delete it. Safe for deliverability, expensive commercially. Catch-all is concentrated at exactly the organisations B2B teams most want to reach — established companies with real mail administrators. Deleting the bucket often means deleting your best-fit accounts.

You send to it anyway. You find out whether the mailbox exists by bouncing off it, in public, in front of the mailbox providers who score your reputation. A small share of dead addresses in a large send is survivable; a concentrated batch is not. We work through the actual thresholds in Are Catch-All Emails Safe to Send?.

You leave it in limbo. The contacts sit in a "risky" segment nobody owns, forever. This is the most common outcome and the most quietly wasteful, because you paid to acquire those contacts and you are now storing them for free.

None of these is a decision. They are all ways of avoiding one.

How VeriMailX handles catch-all addresses

VeriMailX exists because of this specific gap. Rather than reporting the domain's behaviour and stopping there, VeriMailX resolves the individual mailbox on catch-all and accept-all domains to a definitive valid or invalid verdict.

The properties that matter to you:

• Definitive, not descriptive. You get a verdict about the address, not a label about the domain.
• Live. Resolution happens at check time against the current state of the mailbox, not against a stale cache of what was true last quarter.
• No email is sent to the recipient. The person behind the address is never contacted, never sees a test message, and never knows a check ran.
• Works across Microsoft 365, Google Workspace and self-hosted mail.
• Proprietary multi-signal resolution. The method is our own and we do not publish it — what we publish is the outcome and how to use it.

The accuracy discipline

We do not claim 100% accuracy, and you should distrust any verifier that does. Some addresses are genuinely ambiguous, and in those cases VeriMailX returns risky rather than an invented invalid.

That is a deliberate design choice. A false "invalid" on a real person is the most expensive error a verifier can make: you suppress a live prospect or a paying customer and never learn that you did. A "risky" you can route, review or hold. A wrong "invalid" is silent and permanent. The difference between VeriMailX and a generic verifier is not that we never say risky — it is that the risky bucket shrinks to the cases that genuinely deserve it, instead of swallowing every catch-all domain on the internet.

Practical rules for handling catch-all contacts

Until every address in your database has a definitive verdict, these rules keep you out of trouble:

• Never bulk-send to an unresolved catch-all segment. Especially not from a domain you rely on for revenue.
• Segment, do not delete. A catch-all contact is unresolved, not dead. Deleting it destroys information you already paid for.
• Verify at the point of capture. A form submission checked at signup is worth more than a database cleaned six months later.
• Re-verify before every major send. Catch-all status and mailbox status both change as staff move on.
• Keep the evidence. Store the verdict and its timestamp against the contact so you can audit why a send happened.

Approaches, in practice, are covered step by step in How to Verify Catch-All Emails Without Bouncing Your List. If most of your problem contacts sit on Microsoft or Google infrastructure — and statistically they will — Microsoft 365 and Google Workspace Catch-Alls explains why those two providers are the hardest case for ordinary verification.

Frequently asked questions

The answers below are the short versions of the questions we get most often; the FAQ section at the end of this page carries the full set.

Is a catch-all domain a red flag? No. It usually indicates a competently administered domain, often a larger or more security-conscious organisation.

Can I tell from the address itself? No. Catch-all is a property of the receiving domain's configuration, not of the address text. You cannot detect it by reading the address.

Do catch-all addresses bounce? Not at the gateway — they are accepted. If the mailbox does not exist, the mail may be silently discarded, filtered, or bounced later. Silent discard is the worst case, because you record a delivery that never reached a human.

Try it on a real catch-all address

The fastest way to understand the difference is to run one of your own stuck contacts through it. The free email checker gives you a verdict on a single address with no signup, and pricing starts with free credits when you create an account.

Take the address your current verifier has been calling "risky" for the last year, and see what it actually is.