Both let you invent addresses on the fly; they differ in blast radius. A catch-all on your bare domain accepts anything at @yourdomain.com — shortest, most credible addresses, and the whole domain absorbs any dictionary attack. A subdomain catch-all accepts anything at @alias.yourdomain.com, containing that attack surface to the subdomain while leaving your main domain clean. Longer addresses, tidier separation.
The two setups
| Bare-domain catch-all | Subdomain catch-all | |
|---|---|---|
| Address looks like | netflix@yourdomain.com | netflix@alias.yourdomain.com |
| Length | Shorter | Longer — matters when reading it aloud |
| Looks like a normal company address | Yes | Less so |
| Dictionary-attack surface | The whole domain | Contained to the subdomain |
| Can you also run real mailboxes on the domain? | Awkward — catch-all swallows typos | Yes, cleanly separated |
| Typos bounce? | No — silently accepted | On the bare domain, yes |
| DNS setup | One set of records | Records on the subdomain |
The case for a subdomain
You can keep your main domain for real mail. This is the strongest argument. If you@yourdomain.com is your actual personal address, a bare-domain catch-all means every typo of it silently succeeds instead of bouncing — so you never learn that someone has been mistyping your address for a year. Put the aliases on a subdomain and the bare domain behaves normally, bouncing what it should.
Containment. If the subdomain starts attracting dictionary attacks, it's contained there. Your primary address is unaffected and you could, in the extreme, abandon the subdomain without touching your main domain.
It's what Firefox Relay Premium does — you get a subdomain and any word before the @ works. That design choice isn't accidental. The comparison
The case for the bare domain
Shorter addresses. ikea@yourdomain.com versus ikea@alias.yourdomain.com. This matters more than it sounds when you're reading an address to someone at a returns desk, or typing it on a phone.
Credibility. A bare-domain address is indistinguishable from a small company's employee address. Subdomain addresses look slightly more like a masking service, which very occasionally invites the blocking that custom domains otherwise avoid. How often sites block aliases
Simplicity. One domain, one set of records, nothing to explain.
How to choose
| If… | Choose |
|---|---|
| The domain exists only for aliases | Bare-domain catch-all |
| You also use it for a real personal or work mailbox | Subdomain |
| You read addresses aloud often | Bare domain — shorter |
| You've had dictionary attacks already | Subdomain, to contain it |
| It's a business domain with role addresses | Subdomain, definitely |
For most personal setups — a cheap domain bought specifically for this — the bare-domain catch-all is the better default. The typo-bouncing argument only bites if the domain is also carrying real mailboxes.
The trade-off both share
Either way you're accepting mail for addresses you never created, which is exactly what makes the setup frictionless and exactly what a dictionary attack exploits. The mitigation is the same in both cases: junk arriving at an address you never issued gets that address disabled, and it stops. The full catch-all trade-off