Unlimited email addresses on your own domain: one address per purpose

The right number of email addresses is one per purpose. The number your provider allows is usually between one and fifteen, and that gap is a pricing artefact rather than a technical limit: a mail server that can route ten addresses can route ten thousand.

How many addresses does one person actually need?

More than any plan allowance, once you count purposes instead of people. Personal correspondence and work. The role addresses your domain is expected to answer. One per project or environment, so alerts and receipts and deploy notifications route themselves. One per service you sign up for, which is where the count explodes; a decade of accounts is hundreds of addresses. One for the vendor relationship you already suspect will end badly.

Anyone who has run a domain for ten years has more addresses in flight than a mid-tier plan permits. People with a fifteen-address allowance do not need fewer addresses; they reuse addresses and call it fine.

Why do providers cap addresses and aliases?

Because their price is per mailbox and a free alias looks like a mailbox that didn’t pay. An alias costs a routing entry and no storage at all, so the cap is never about capacity. It is about keeping the seat count meaningful, which is why allowances sit in the single digits to the low tens and climb with the plan tier.

Gmail’s +tag and dot tricks are the free workaround, and they demonstrate the failure mode: the base address is visible inside the tagged one, so a list broker strips the tag with one regular expression and you are left with no address to burn. Apple’s Hide My Email answered that properly by generating unrelated random addresses on Apple’s domain, which solves the tagging problem by handing the naming back to a provider.

When the storage is yours and the meter is gigabytes, the cap has nothing left to charge for. Nisdos Mail keeps addresses, aliases and domains unlimited under fair-use terms, all delivering into one storage you nominate per domain or per mailbox. Fair use is the honest asterisk on any “unlimited”; the substantive point is that no address you invent costs a seat.

What is a per-sender address good for?

Leak tracing, and it works better than any promise in a privacy policy. Give each company its own address — airline@, hardwarestore@, thatconference@ — and the first piece of unsolicited mail arrives carrying the answer in its own headers. I have found out about two list leaks this way years before either company said a word.

The repair is also cheap. A burned address gets deleted, and the only party inconvenienced is the one that lost it. Compare that with changing a shared address everywhere, which nobody finishes.

What per-sender addresses are not: anonymity. Every one of them announces the same domain, and a domain is an identity with registration history attached. This pattern tells you where a leak came from. It does not hide who you are, and I would rather say so than let anyone find out the hard way.

Isn’t a catch-all simpler?

A catch-all does the same job for about a week, then becomes a liability. Because it accepts every local part, dictionary attacks against your domain succeed by definition: admin@, info@, sales@, thousands of guesses an hour, all accepted, all now your problem to sort. Spam addressed to names you never used is indistinguishable from mail you asked for.

You also lose the ability to retire anything. The burned address keeps being accepted forever, because acceptance is the default. And accepting mail you immediately discard is how a domain builds a reputation for accepting mail nobody reads.

Explicit addresses let the MX reject unknown recipients during the SMTP transaction — a refusal the sender owns, before the message becomes an object in your storage. The reasonable use for a catch-all is temporary: switch it on while migrating a domain to find the forgotten addresses still receiving mail, then switch it off.

Which addresses should exist on every domain?

The set I create before anything else, on every domain I run:

• postmaster@ and abuse@ — RFC 2142 has specified these since 1997. Receivers check them, and blocklist operators and other postmasters use them to reach you when something is wrong with your mail. A domain that bounces abuse@ looks abandoned.
• hostmaster@ — DNS administration and some certificate validation flows still send there.
• security@, matching the address you publish in /.well-known/security.txt (RFC 9116), so a researcher has somewhere to send a report that isn’t your personal inbox.
• dmarc@ — the destination in your DMARC record’s rua= tag. Aggregate reports arrive daily as XML attachments and deserve their own address, not your morning.
• One per service, generated at signup rather than curated later. Curating never happens.
• One per project or environment: alerts@, deploy@, receipts@, invoices@, each routed to whichever mailbox should actually see it.
• Role addresses that outlive the humans holding them — hello@, sales@, support@ — so somebody leaving does not take a channel with them.

That list is roughly a dozen addresses before you have signed up for anything. On a per-seat plan it is most of an allowance. On an unlimited domain it is a Tuesday afternoon.

What breaks when addresses are free?

Four things, all manageable, none of them dramatic.

Sending as the right one. Receiving on 300 addresses is free; replying from the correct one is a habit, and getting it wrong leaks the mapping you built. Authentication is not the problem: SPF, DKIM and DMARC are set per domain, so every address inherits the domain’s standing. The problem is the from-field you clicked past.

Remembering the map. An address per vendor is a small database. Either search is your index (the address itself is the query) or you store the address next to the login in your password manager. The second habit is the one that survives four years.

Reputation is per domain. All those addresses share one domain’s standing, so one compromised account sending spam damages every address at once. That is the flip side of consolidating your identity onto a name you own.

The archive only grows, because the entire pattern depends on never throwing anything away. Which is a storage problem, and storage is the one part of this you can point at a bucket you already own.