Unlimited email aliases for your domain
Aliases versus mailboxes, where the distinction actually matters, and why per-seat pricing makes them expensive.
An alias is an address that delivers into a mailbox you already have. A mailbox is storage with its own credentials. The distinction sounds pedantic until you get billed for it.
Why the difference shows up on your invoice
On per-seat plans, a mailbox is a license. So the natural instinct — give
billing@ its own mailbox — costs the same as hiring someone. Teams learn to
route everything through aliases and groups instead, which works but means learning an
admin console to avoid a billing artifact.
When pricing is per domain, the question disappears. Make billing@ a mailbox
if it deserves storage of its own, or an alias if it doesn't. Neither choice changes the
bill.
Sensible defaults for a small team
| Address | Type | Why |
|---|---|---|
hello@ | Mailbox | The public front door; deserves its own history |
support@ | Mailbox | Shared by several people over time |
billing@ | Alias → hello@ | Low volume, no separate history needed |
press@, jobs@ | Alias → hello@ | Exist for the website, rarely used |
name@ | Mailbox | One per person who needs their own |
Aliases as a privacy tool
A per-vendor alias — shop-acme@yourbrand.com — tells you exactly who leaked
or sold your address when spam starts arriving, and lets you switch it off without
touching anything else. This only works if creating aliases is free, which is precisely
what per-seat pricing discourages.
The one thing to be careful with
A catch-all accepts every address at your domain. It sounds convenient and it is, right up until a spammer discovers it — at which point every random string becomes a valid target and your mailbox fills with noise you cannot unsubscribe from. Keep it off unless you have a specific reason, and prefer explicit aliases.