What Is a Catch-All Email Address? Uses, Risks, Alternatives

So what is a catch-all email address? It is a rule you set on your mail domain that accepts every message sent to that domain, no matter what local part appears before the @. Mail to [email protected], [email protected], and [email protected] — even though only one of those was ever meant to exist — all end up in the same catch-all mailbox. The alternative, and the default on most modern providers, is an explicit-alias domain that answers only for the addresses you defined and rejects everything else at the SMTP level with a 550 5.1.1 'No such user here' response, defined in RFC 5321.

This roundup ranks eight approaches to handling mail addressed to your domain and says which one to use when. There is a real case for a catch-all — usually during a migration off a legacy address book nobody has written down — and several cases where it is exactly the wrong choice, because a catch-all quietly amplifies dictionary attacks, spam volume, and backscatter risk. We ranked the options by how well they handle those three failure modes without losing legitimate mail.

We build AI Emaily, and we are a mail client — not a catch-all option. That is why entry eight is the honest carve-out at the bottom of the list rather than the top pick most site-authored roundups would fake. The other seven entries are the real decision, ranked by what most domain owners should actually do.

The short answer: what should most domains do?#

For most established domains, the top pick is not a catch-all at all. It is an explicit-alias domain: you create the aliases you actually use — sales@, support@, jordan@ — and configure the mail server to reject anything else with an SMTP 550 5.1.1 response, the standard 'mailbox does not exist' reply defined in RFC 5321 §3.3. That single change removes almost every downside a catch-all suffers from, because a rejection at the SMTP conversation never becomes a message in a mailbox, never generates a bounce your server has to send, and never trains a spammer that your domain is worth guessing.

The one narrow place a catch-all earns its keep is a live migration. When you are moving off a decade-old provider and nobody kept the alias list, turning on a catch-all for the transition window means you do not lose the invoice sent to an obscure address once printed on a business card in 2014. That is a real problem, and for a working migration on a well-run provider, a time-boxed catch-all genuinely beats a bounce storm. It becomes a liability the moment you leave it on past the migration.

Everything below is the case for that top pick and the honest exceptions. If you are already convinced, skip to the tools section for the eight options ranked, or to how to choose for the decision framework at the end.

How we compared the eight approaches#

Every option here does the same top-level job: decide what to do with a message the sender addressed to your domain. What separates them is what they do with the messages nobody intended to send to a real address, and what that decision costs later. We scored on five axes.

• Reject fidelity — does the approach cleanly refuse mail to non-existent local parts at the SMTP conversation, or does it accept-then-file, generating bounces and giving spammers a positive signal?
• Dictionary-attack surface — how easy does the setup make it for a spammer running a name list against your domain to learn which addresses reach a real mailbox?
• Backscatter risk — if the message turns out to be forged spam, does the approach send a bounce to the innocent third party the spammer put in the From line?
• Migration usefulness — how well does the approach handle the specific case of a domain switch where the alias list is incomplete or unknown?
• Operator effort — what does the domain owner have to maintain: a static alias list, per-user tags, external services, or nothing at all?

The five axes point in the same direction almost every time. A setup that rejects cleanly at the SMTP level tends to be worse for a chaotic migration and better for everything after, because you have to know your addresses to define them. A permissive catch-all is the opposite: painless during a switchover and quietly ruinous once your domain shows up on a spammer's list of hosts that accept every guess. The ranking is what falls out of weighing those against each other for a normal working domain in 2026, not a domain being resurrected from a backup tape.

Eight approaches at a glance#

The table below is the ranked shortlist. It is not exhaustive — there are always more esoteric setups — but the eight options cover the choices a domain owner actually faces at the mailbox provider they are on. Every table cell is verified against the vendor's own published documentation as of August 2026; capabilities move quickly on this axis, so confirm the specifics on the provider's live page before you configure a mailbox around them.

The pattern the table shows is the honest one: reject fidelity and migration usefulness pull in opposite directions, and the right answer depends on which problem you have this week. The rest of the roundup takes the eight rows one at a time.

1. Explicit aliases plus a reject-unknowns policy — the safer default#

The safer default for almost every working domain is to define the aliases you actually use and configure the mail server to refuse everything else at the SMTP conversation with a 550 5.1.1 response. That is the standard 'No such user here' reply from RFC 5321 §3.3, and it means a spammer running a dictionary attack against your domain learns nothing useful — every guess is rejected identically, whether the local part is close to real or wildly off. You keep one live mailbox per person or function, and the mail server does the sorting decision for you before a message ever becomes your problem.

The trade-off is honest: an explicit-alias setup only works if you know your aliases. If a customer emails an address you retired three years ago, it bounces, and you find out only when they follow up on a different channel. For a domain with a stable address book that is not an issue. For a domain still shedding history, it is a real cost you should weigh against the security win of every unknown local part getting the same clean rejection.

2. Provider catch-all mailbox — the classic risky default#

The classic catch-all is a single mailbox at your provider. Google Workspace supports it as a routing rule in the Admin console; Fastmail and Zoho expose it as a first-class setting; Microsoft 365 supports it via an Exchange transport rule or a shared mailbox rather than a native toggle. However you configure it, any message to any local part on the domain lands there. Nothing gets lost. Everything is one search away. On paper it looks like insurance against forgotten addresses.

In practice it inverts three things you want. It tells a spammer that yourdomain.com accepts every guess, so your domain moves onto the dictionary-attack list and stays there. It removes your reject signal so the volume of spam that reaches a real mailbox jumps sharply once the domain is discovered. And when the messages turn out to be spoofed spam with a real innocent third party in the From line, your server generating a bounce to that third party is textbook backscatter — the exact anti-pattern the M3AAWG bounce-handling guidance warns against. As a permanent setup on a domain the outside world knows about, it is worse than doing nothing.

3. Time-boxed migration catch-all — the one legitimate use#

The one place a catch-all is genuinely the right answer is a live migration onto a new domain or a new provider where nobody has the complete alias list. You do not want to lose a real customer's mail because it was sent to an address printed on a 2016 conference badge that never made it into the current inbox map. Turn on the catch-all for the migration window, log every recipient it accepts, review the log weekly, and add the real ones as explicit aliases as they surface.

The discipline that separates a working migration catch-all from a slow disaster is that it is time-boxed and monitored. Pick a window — thirty, sixty, ninety days — set a calendar reminder, and turn the catch-all off at the end, whether you feel ready or not. Every legitimate address the migration surfaced is now an explicit alias, and the domain reverts to the safer default. Skipping the calendar reminder is how a temporary catch-all becomes the permanent risky default from entry two.

4. Plus addressing (subaddressing) — a filter tool, not a routing one#

Plus addressing lets you add a plus sign and a tag to your existing address — [email protected] — so mail lands in your real inbox carrying a tag you can filter on. It is formalised for the Sieve filtering language in RFC 5233 and supported without setup on Gmail, Microsoft 365, Proton Mail, and Fastmail. The tag survives into the message headers, so an inbox rule can act on 'sent to jordan+shop' after delivery.

It is genuinely useful and it is also frequently confused with a catch-all. It is not one. A plus address is one real mailbox wearing a label; a catch-all is a rule that accepts mail for local parts that do not exist. Plus addressing does not help you receive mail sent to a completely different local part, and it does not solve a migration problem. It is the right tool when your job is filtering the mail one identity receives — see our post on plus addressing for the full behaviour and the corner cases where a form rejects the plus sign.

5. Masked email or alias services — for outgoing signups, not incoming domain routing#

Alias services like Fastmail's masked email, SimpleLogin, AnonAddy, and Apple Hide My Email mint a disposable address on demand — a fresh unique local part on a service-controlled domain that forwards to your real mailbox. Each address is a discrete alias you can disable at any time. Handed to a signup form, it lets you cut off a sender the moment they start selling your address without any effect on the other addresses you use.

Fastmail has built more thoughtful masked-email and subdomain-addressing primitives than we have, and if minting per-signup addresses on a domain you control is the job, Fastmail or a dedicated alias service is the right answer — not us and not a catch-all. What this row is not is a solution to the catch-all question. A masked-email service does not receive mail for arbitrary local parts on your own working domain; it gives you unlimited addresses on a service domain, one at a time. Different job, different tool.

6. Group aliases and distribution lists — shared functional addresses#

For shared functional addresses like sales@, support@, or hr@, most providers offer a group or distribution list that delivers to a defined set of members rather than a single mailbox. Google Workspace calls them Groups, Microsoft 365 calls them distribution groups or shared mailboxes, and every serious IMAP host supports the same idea. The address itself is explicit and defined — a group named sales@ does not accept mail to sale@ or salez@ unless you separately configure those spellings.

This is the right way to handle role addresses on an established domain, and it is complementary to the explicit-alias default rather than an alternative to it. Where it does not help is unknown local parts; a distribution list is still an explicit alias, and mail to something the group does not cover still rejects with the usual SMTP response. If your problem is 'my team keeps missing mail on sales@ because it is one person's inbox', this fixes it. If your problem is 'I might lose mail to old addresses I forgot', this does not.

7. Subdomain addressing — wildcards, contained#

A few providers, Fastmail most notably, support subdomain addressing: [email protected] routes to a real inbox on you.com, with the subdomain acting as a per-signup or per-purpose namespace. It gives you the unlimited-address feel of a catch-all, but confined to a subdomain you set aside for it — so your main working addresses on the base domain still enforce explicit aliases and reject unknowns. It is a genuine middle ground that few providers ship.

The exposure to weigh is the same as with any wildcard: once the subdomain is discovered, mail to it accepts every guess, so the subdomain itself becomes a dictionary-attack surface even while the base domain stays safe. Use a distinct, uninteresting subdomain, keep the base domain on the safer default, and do not point marketing or signup forms at the subdomain unless you are prepared for the volume. As a bulk-address tool for someone who wants that shape, it is defensible; as a catch-all for the real business domain, it is the classic risky default under a different name.

8. AI Emaily — the client-side layer, once the mail arrives#

We build AI Emaily, and this entry is the honest scope: we are a mail client, not a domain-routing option. The catch-all decision happens at your provider — Google Workspace, Microsoft 365, Fastmail, Zoho, or your own mail server — and no client can undo an accept-all rule set at the server. If your problem is 'what should my domain do with unknown local parts', the answer is one of entries one through seven, not us.

Where AI Emaily fits is the mail that does reach an inbox once your provider has decided to accept it. The problem a catch-all setup creates for a person is that a real mailbox now receives the ten legitimate messages a week to defined aliases plus the dictionary-attack noise the catch-all invited in. AI Emaily's spam and cold-email protection filter on sender behaviour and domain, not only on the local part the sender used, so a rotating attacker hitting a catch-all does not reset the filter each time it changes recipients. The Rules and Context Brain can hold standing instructions like 'mail to invoices@ files here, anything to a role address routes to triage'. It works the same on Gmail, Outlook, Fastmail, or standard IMAP — see aiemaily.com. What it does not do is decide whether your provider should accept the message in the first place. That is a domain-configuration choice, and the earlier entries are the honest answer to it.

How to choose for your situation#

The decision is smaller than the catch-all discourse makes it look. Answer four questions in order and one of the eight entries is your answer.

1. 1

   1. Are you actively migrating onto or off a domain?

   If yes and you do not have the complete alias list, use entry three — a time-boxed migration catch-all on a well-run provider, with a calendar reminder to turn it off and a weekly review of what it accepted. If you have the full alias list already, skip to step two.

2. 2

   2. Is the domain established and outward-facing?

   If yes, entry one is the default: explicit aliases and a reject-unknowns policy at the SMTP level. Add group aliases from entry six for role addresses like sales@ or support@, and consider subdomain addressing from entry seven only if you have a specific bulk-address use case on a distinct subdomain.

3. 3

   3. What do you actually need — filtering or new outward identities?

   For filtering one mailbox's incoming stream, plus addressing from entry four is the built-in answer. For unlimited disposable outward addresses, masked-email services from entry five are the right tool; Fastmail and SimpleLogin are the strong picks here, and we do not compete on that axis.

4. 4

   4. What happens to the mail after your provider accepts it?

   Whichever provider policy you land on, mail still lands in an inbox that needs triaging. Entry eight — AI Emaily — is the client-side layer for that job. It is not a substitute for the provider decision above, and we will not pretend otherwise.

Frequently asked questions#

The questions people ask most about catch-all email addresses — how they work, whether they are a bad idea, how they compare to aliases, and what modern providers actually support.