How Many Email Aliases Do I Need? A Practical Number, Not a Cap

You need fewer aliases than you think: for a typical product domain, five to eight well-chosen role addresses cover nearly everything the world will send you, and one or two personal names cover the humans. That is not a platform limit; every host we discuss allows dozens or unlimited aliases. The question is really which addresses earn their keep, because each one is a thing you check, filter, and eventually hand to a vendor. Fewer, purposeful aliases beat a long speculative list every time.

We make SuperMailOS, where aliases are free and unlimited on every plan, so we have no incentive to ration them and every incentive to tell you the boring truth: the working set is small.

The working set per product domain

Run a product and these are the addresses that consistently matter:

• hello@ or info@ - the front door. One of the two, not both.
• support@ - once you have users writing in. Before that, hello@ absorbs it.
• security@ - even for small products. Researchers and automated scanners look for it, and a missed disclosure is a bad day. Some registries and browsers check it exists.
• billing@ or invoices@ - the moment money changes hands, so vendor invoices stop landing in your personal mail.
• press@ - if anyone might ever write about you. Journalists do not hunt for alternatives.
• careers@ - only when you are actually hiring; a dead careers@ reads worse than none.
• A personal name@ - founder@ or your actual name, for the mail that should reach a human and not a role.

That is the honest seven. A second product domain needs its own front door and support address, shares your personal name's inbox, and skips the rest until reality demands them. The pattern, one inbox behind many addresses, is laid out in one inbox for multiple domains.

When the answer grows

Three situations legitimately expand the list. Vendor separation: signing up to a service with vendorname@yourdomain gives you a kill-switch for leaky senders; delete the alias, the spam dies with it. This is the one case where dozens of aliases is healthy, and it compounds with the spam-side arguments in catch-all email spam risk. Team functions: each new person brings their name@, and functions like sales@ graduate from an alias into a shared mailbox when two people answer it. Product surface area: a marketplace or API product eventually wants legal@, abuse@, and dmca@; add them when the obligation appears, not speculatively.

When to delete one

An alias is a liability the moment nobody reads it. Audit yearly: if an address has not received a message you needed in six months, or it exists only to receive spam, delete it. On hosts where aliases are metered, that is housekeeping; on hosts where they are free, like ours, it is hygiene: every live address is a place a password reset can go to die. The lifecycle mechanics (alias into mailbox, delete without data loss) are in domain alias vs mailbox.

The one number to remember

If you want the whole piece as a rule: start with four (hello, support, security, billing), add press when you launch, and never create an alias you cannot name the reader for. For the operators running several products, the portfolio-scale version of this discipline, one inbox and one bill behind all those small address sets, is in email for a product portfolio and on the SuperMailOS use cases page.

Frequently asked questions

Is there a limit on email aliases?

Depends on the host: suites often cap aliases per user, while specialist hosts allow unlimited. On SuperMailOS, aliases are free and unlimited on every plan; the bill counts people (mailboxes), never addresses.

Should I use a catch-all instead of creating aliases?

No. A catch-all accepts every guessed address, which is a spam invitation; chosen aliases with unknown-address bouncing give you the same coverage for names you use. The full trade-off is in our catch-all guides.

Do role aliases look unprofessional at small scale?

No, but dead ones do. A domain where support@ and careers@ auto-bounce reads worse than one with a single working hello@. Create roles when you can staff the promise, even if the staff is you.

Can aliases send mail, or only receive?

On full-featured hosts, aliases both receive and send: you reply as the alias address. That is the feature that makes a small alias set workable, and it is worth confirming on any host you evaluate.