Catch-All vs Email Aliases: Which to Use on Your Domain (2026)
Catch-all vs email aliases, decided: a catch-all accepts every address at your domain, aliases accept only what you define. The mechanics, the spam math, and a layered setup that beats both.
A catch-all delivers mail addressed to anything@yourdomain.com into one inbox, including addresses that don't exist. An email alias is one named address you define — hello@, billing@, support@ — that forwards into a real mailbox. Aliases are the safer default for most domains: unknown addresses bounce at the SMTP edge, so dictionary spam never lands, and a leaked alias can be switched off individually. A catch-all trades that control for zero-setup coverage of every typo and guess, which is why its spam volume compounds over time.
Disclosure up front: we make SuperMailOS, an email host where every alias is free — so we sit on the alias side of this table. The mechanics below apply no matter who hosts your mail.
Catch-all vs email aliases: what each one actually does
What a catch-all actually does
A catch-all — sometimes called a wildcard address — is a rule on your mail server, not a DNS record. Your MX records already route all inbound mail to your host; the catch-all rule decides what happens to addresses that match no mailbox or alias. Instead of rejecting unknown recipients with a 550 5.1.1 SMTP error during the mail conversation, the server returns 250 OK and drops the message into a designated inbox.
That one behavior change creates every downstream trade-off. The typo'd slaes@ reaches you. So does every address a spam script invents.
What an email alias actually does
An alias is an explicit address you create that delivers into a real mailbox. hello@acme.app isn't a separate inbox with its own login — it's a route into the inbox a person actually reads. On most providers you can create as many as you need, on demand, and disable any one of them without touching the rest.
Under the hood, an alias domain is fail-closed: the server answers only for addresses you defined and rejects everything else at the SMTP edge, before the message body is even transferred. Nothing is accepted that you didn't ask for.
Catch-all vs aliases, side by side
Catch-all (*@domain) |
Explicit aliases (hello@, billing@) |
|
|---|---|---|
| Accepts | Every address, existing or not | Only the addresses you define |
| Unknown mail | Delivered to one inbox | Rejected at SMTP (550 5.1.1) |
| Spam exposure | High — accepts every guess | Normal — guesses bounce |
| Turn off one bad address | No — all or nothing | Yes — each alias is independent |
| Leak tracing | Detect leaks, can't revoke | Detect and revoke per alias |
| Setup cost | Zero | A few minutes, per address |
| Best for | Time-boxed migrations, typo safety net | Steady-state domains, per-service addressing |
The spam math nobody prices in on day one
A new domain with a catch-all feels like a free win: nothing knows the domain yet, the wildcard sweeps up only your real mail. The bill arrives later. Spammers run directory harvest attacks — scripted guesses at common prefixes like admin@, info@, billing@, noreply@ — to map which addresses exist. Against a fail-closed domain, most guesses bounce and the script moves on. Against a catch-all, every guess returns 250 OK and delivers. Once a domain is known to accept everything, it gets traded around as a live target, and volume grows rather than settles.
Two second-order costs show up in operator experience:
- No per-address off switch. If
shop@yourdomain.comgets sold to a spam list, a catch-all cannot refuse just that address — your options are a client-side filter or killing the catch-all entirely. - Backscatter risk. A server that accepts mail and then bounces it internally after the fact generates backscatter, which is a common path onto blocklists like ips.backscatterer.org. The fix is rejecting unknown recipients during the SMTP conversation — alias behavior — not after.
There's also an outbound wrinkle: verification services flag catch-all domains as "accept-all," and some bulk senders treat that as risky, so your addresses may get scrubbed from other people's lists. For a fuller treatment of the sender side of this, see our SPF, DKIM, and DMARC explained guide.
Why operators running several domains lean alias
If you run one domain, the choice is a preference. If you run several — an agency with client domains, a portfolio of products — aliases win on structure:
- Predictable naming. hello@, support@, billing@ on every domain, same pattern everywhere. Consistency makes triage mechanical instead of investigative.
- Per-domain revocation. A leaked address on one product's domain gets disabled without touching any other domain.
- One reader, many routes. Aliases deliver into a mailbox a person actually reads, so customer mail doesn't rot in a wildcard bucket nobody sweeps.
That's the same architecture we built into SuperMailOS: when you add a domain, you tap the addresses you want on it, and every one delivers into one inbox — while unknown addresses still bounce. Aliases are free and unlimited on every plan; you pay per person, not addresses. For the broader picture on running mail across many domains, see our guide to email hosting for multiple domains.
A setup that beats both extremes
Most guides stop at "catch-all vs aliases" as a binary. In practice the strongest setup layers them, deny-by-default:
- Define the functions customers use. hello@, support@, billing@ as explicit aliases into a monitored mailbox.
- Add predictable variants. Common misspellings of your public addresses as aliases too — customers guessing
info@when you publishhello@is more common than any random typo. - Retire with aliases, not silence. Former staff addresses and old product names forward for a season, then get removed.
- Reserve catch-all for a window. During a migration or domain acquisition, route the catch-all into a quarantine sink, watch what real mail still arrives, promote those addresses to aliases, then close the wildcard.
If you're triaging what each domain actually needs, our use cases overview walks through the common patterns for multi-domain operators.
This is the setup we run across the products we build — a vector conversion tool (how to convert PNG to SVG) and a group expense splitter (best Splitwise alternatives) — each with its own domain and addresses feeding one inbox.
Frequently asked questions
Is a catch-all the same as an alias?
No. An alias is one address you explicitly create that delivers into a real mailbox. A catch-all is a domain-wide rule that accepts mail to every address, including ones that don't exist. Aliases are auditable and revocable one at a time; a catch-all is all-or-nothing.
Will a catch-all increase my spam?
Usually, and it compounds. Catch-all domains accept every guessed address instead of bouncing it, so dictionary spam lands in one inbox. Domains known to accept everything get added to target lists, and volume grows over months rather than spiking on day one.
Can I turn off one address on a catch-all domain?
Not per-address. A catch-all accepts everything by definition; if one guessed address starts receiving abuse, your options are a filter in the mail client or disabling the catch-all for the whole domain. Explicit aliases don't have this problem — each one has its own off switch.
Which is better for catching typos?
A catch-all catches every typo by construction. Aliases catch the typos you anticipated: create the two or three plausible misspellings of your public addresses as aliases, and the long tail of random guesses still bounces. For most domains that covers real-world typos without the spam intake.
Do aliases cost extra?
Depends on the host. Many providers meter aliases or bundle a small number per plan. On SuperMailOS, aliases are unlimited and free on every plan — the billing unit is people, not addresses.
Running several products and want every domain's addresses in one inbox, with unknown mail still bouncing? SuperMailOS gives you unlimited free aliases across every domain you connect, one inbox, and one bill per person. 14 days free, no credit card.