Give each service its own address and unattributable spam becomes a named source. If only one company was ever told about hardware-store@yourdomain.com, then casino offers arriving there identify their own origin with no investigation. You switch that one address off and everything else you own is untouched. The practical version of this takes about ten seconds per signup and no ongoing admin.
Why one address for everything fails
Using a single address for several hundred accounts creates two problems that compound.
First, you lose all attribution. Every sender knows the same address, so spam arriving there could have come from any of them, via any of the parties they shared it with. There is no way to reason about it. The only remaining moves are guessing and unsubscribing.
Second, every leak is a total leak. One breached retailer exposes the same address that your bank, your employer and your doctor use. It also becomes a join key: anyone holding two leaked databases can match your records across them because the address is identical in both.
Per-service addresses remove both properties. Attribution becomes automatic and a leak is contained to one relationship.
The naming convention question
Do this once and never think about it again. The convention only needs to satisfy one requirement: seeing the address should immediately tell you which company it belongs to.
- Company name.
netflix@,ikea@,britishgas@. Simple, instantly readable, and the one most people should use. - Company plus year for services you expect to re-register with:
netflix2026@. - Category where you don't care about per-company granularity:
newsletters@,receipts@. Cheaper to manage, but you lose attribution within the category — a newsletter address that starts getting spam won't tell you which newsletter sold you.
Avoid random strings if you have the choice. x7fq2k@yourdomain.com is unguessable, but you will not recognise it in a list of two hundred, and you'll be reluctant to disable it in case it's something important.
Predictable names have a downside worth naming: someone who learns netflix@yourdomain.com can guess amazon@yourdomain.com. On a catch-all domain those guesses will be accepted until you disable them.
For most people this is a fair trade — the spam that results is trivially attributable and switchable off, and the benefit of readable addresses is realised every single day. If you're specifically worried about a targeted adversary rather than about marketing lists, add a short fixed suffix you reuse: netflix-k2@, amazon-k2@. Readable to you, not guessable from one sample.
The setup, in the order that works
- Leave your real address alone. It stays as your personal address for people who know you. It stops going into web forms. Don't try to clean it up first — that's a project that never finishes and it isn't necessary.
- Choose where the aliases live. A provider domain is free and instant; your own domain costs a few dollars a year and survives you changing provider. The trade-off is worked through in what happens if the service shuts down.
- Pick your convention and write it down somewhere.
- Use it for every new signup from today. This is the only step that must be consistent.
- Migrate old accounts opportunistically. Never in a batch.
Why not migrate everything at once
Because you won't. Two hundred accounts, each with a settings page, each sending a confirmation email to the new address — that's a weekend, and most people abandon it around account thirty with the job half done, which is worse than not starting.
The opportunistic version costs nothing: when a service emails you anyway — a receipt, a password reset, a policy update — that's your reminder to spend sixty seconds changing the address on that account. Within a year the accounts that actually matter have moved, because the accounts that matter are the ones that email you.
Living with it
The whole maintenance routine:
- Spam arrives at an alias.
- The address names the company.
- If you don't need that company any more, disable the alias. Mail stops.
- If you do still need them, change the address on your account first, confirm the new one works, then disable the old one.
That's it. No triage, no guessing, no unsubscribe chains. What disabling does and doesn't achieve is covered in what actually happens when you disable an email alias.
Common objections, answered
"Isn't this a lot of admin?"
Less than the spam it prevents. With a catch-all setup there is no creation step at all — you type a new address into the signup form and it starts working when the first message arrives. The admin is typing a different word before the @.
"What if I forget which address I used?"
If the address is the company's name, you haven't forgotten it. This is the real argument for a readable convention over random strings.
"Will sites reject them?"
Occasionally. Some services blocklist well-known shared alias domains. Your own domain looks like any other company domain and is rarely blocked. If a site does refuse, use your real address for that one and move on — a system that works for 95% of signups is still worth having.
"Does this hide my identity?"
No, and it isn't meant to. You typed your real name and card details into the form. Aliases control which addresses have a working route to your inbox and tell you who leaked them. That is a spam and attribution tool, not an anonymity tool.
What this actually buys you
After a year of doing this, a specific thing becomes possible that isn't otherwise: when spam arrives, you know who is responsible. Not a suspicion — the address is the evidence. You can decide whether to keep dealing with that company, and you can cut off the mail without asking anyone's permission.
For where this sits among the other options — filtering, unsubscribing, data removal — see how to stop spam emails.