Spam starts arriving at an address you have used for a decade. You have no idea which of the several hundred services holding it leaked or sold it, no way to find out, and no way to stop it without changing an address that everything depends on.
The alternative is to give every service its own address. Then spam identifies its own source, and turning it off is a single action affecting nothing else.
What changed in 2026
- Alias services became mainstream features. Email masking arrived built into browsers, password managers, and platform privacy settings rather than requiring a separate tool.
- Breach frequency kept the case strong. The steady stream of large breaches made per-service attribution more valuable, not less.
- Data broker matching stayed email-centric. Email address remains a primary key for linking profiles across sources, which is what unique addresses defeat.
- Provider lock-in became the main criticism. Aliases tied to one service are difficult to migrate away from, which pushed privacy-focused users toward custom domains.
What it actually buys you
Attribution. When spam arrives at shop-name@yourdomain.com, you know precisely which company leaked, sold, or was breached. That is information you can act on and information you otherwise never have.
A clean off switch. Disable the alias and the mail stops. No changing your real address, no updating anything else, no notifying hundreds of services. Compare that to the alternative, which is migrating a decade of accounts.
Breaking the identifier. Data brokers correlate records across sources using email as a key. A unique address per service means those records do not join up as easily, which limits profile-building materially — see data broker opt-out for removing what already exists.
Phishing detection. A message claiming to be from your bank, arriving at the alias you gave a shopping site, is unambiguously fraudulent. The address itself is the tell, with no need to inspect headers.
Three approaches
|
Plus addressing |
Alias service |
Custom domain |
| Cost |
Free |
Free to modest |
Domain registration |
| Setup effort |
None |
Minimal |
Some |
| Stripping risk |
High — trivially removed |
Low |
Low |
| Provider lock-in |
Yes |
Yes |
No |
| Portability |
None |
Limited |
Full |
| Reply from alias |
No |
Usually |
Yes |
Plus addressing appends a tag to your existing address. Free and instant, and the significant weakness is that the real address is visible in it — anyone can strip the tag, and some sites reject the format outright. Useful for filtering, weak for privacy.
Alias services generate genuinely unrelated addresses that forward to you. Effective, easy, and your aliases live on someone else's domain. If that service shuts down or changes terms, every alias goes with it.
Your own domain with catch-all or explicitly created aliases gives full control and portability. If your email provider changes, you take the domain with you and nothing breaks. It costs a domain registration and a little setup, and it is the option that does not become someone else's decision later.
Where not to use them
Aliases add an indirection layer, and indirection can fail at the worst moment.
Accounts you cannot afford to lose access to — your primary bank, government services, your password manager — are arguably better on your real address. If an alias service has an outage, or you lose the domain, or a forwarding rule breaks, you have lost the recovery channel for the account that matters most.
Anywhere you need to send as well as receive. Some alias services support replying from the alias; some do not. If a service expects mail from the registered address, check that yours can.
Services that reject them. Some sites block known alias domains. Frustrating, and worth having a fallback.
The practical middle ground most people land on: real address for a small number of critical accounts, aliases for everything else. That preserves recovery reliability where it matters and gets the benefit across the long tail where breaches actually happen.
Keep a record of which alias went to which service, ideally in your password manager alongside the credentials — see the best password managers.
Common mistakes
- Aliases on critical recovery accounts. Adds a failure point to the thing you most need working.
- Plus addressing for privacy. The real address is right there and trivially stripped.
- No record of which alias is which. Attribution requires knowing what you assigned.
- Depending on a service you cannot leave. Provider shutdown means every alias dies.
- Not testing that you can reply. Discovered when a service needs a response from the registered address.
- Forgetting domain renewal. An expired domain takes every alias with it — set it to auto-renew.
FAQ
Do I need my own domain?
Not to start. An alias service gets most of the benefit with none of the setup. The domain matters when you want the arrangement to survive changing providers.
What happens if the alias service disappears?
Every alias stops forwarding, and you would need to update your address at every service using one. That is the lock-in risk, and it is the main argument for a domain you control.
Will this reduce spam I already receive?
Not at your existing address; that is already out there. It prevents the problem going forward, and gives you a clean address for anything new.
Does it help with phishing?
Substantially, because mail arriving at the wrong alias is immediately identifiable as fraudulent without any judgement about content or sender formatting.
Where to go next
For removing profiles built from your existing address, read data broker opt-out. For storing aliases alongside credentials, the best password managers, and for the account-recovery planning that determines which addresses need to stay reliable, account recovery planning.