If your threat model includes a state, a well-resourced adversary, or anyone who might compel a company to hand over records, an email alias service is the wrong tool and you should not rely on it. Aliases are built to stop marketing lists and to attribute leaks. They do not provide anonymity, they don't protect metadata, and the service operating them can be compelled. This article exists to talk you out of a mistake, not to sell you something.
What an alias service actually does
It routes mail from one address to another and lets you switch individual addresses off. That's genuinely useful against commercial data trading. Against a serious adversary it offers close to nothing:
- The service knows the mapping. Which alias belongs to which real inbox is in their database, and that database can be compelled, breached or subpoenaed.
- Metadata isn't protected. Who mailed you, when, and often the subject line pass through in the clear.
- A custom domain is worse, not better, here. A domain used by one person is a stable identifier linking every account it touches, and it's registered to somebody. WHOIS privacy hides that from casual lookup, not from legal process. The boundary
- Payment links back to you if you bought the domain with a card.
None of that is a flaw in the tools. It's a mismatch between what they're for and what a high-risk threat model requires.
Where the real risks are
Even with encrypted contents, email leaks the social graph: who corresponds with whom, how often, and when. For source protection that pattern is frequently more revealing than the messages, and standard email offers no way to hide it.
This is why serious guidance in this area tends toward purpose-built tools โ end-to-end encrypted messengers with minimal metadata retention, or dedicated secure-drop systems for source contact โ rather than toward better email hygiene.
Where to get guidance that fits
We're not the right source for this and it would be irresponsible to pretend otherwise. Organisations that specialise in it, and whose guidance is maintained by people who do threat modelling professionally:
- Committee to Protect Journalists โ digital safety resources aimed specifically at reporters.
- Freedom of the Press Foundation โ practical tooling and training, including secure source-contact systems.
- Electronic Frontier Foundation โ Surveillance Self-Defense, which starts from threat modelling rather than from a tool list.
- Access Now Digital Security Helpline โ direct support for civil society and at-risk individuals.
- Your organisation's own security team, if you have one, and your legal counsel on what can be compelled where you operate.
The common first step in all of them is threat modelling: who specifically are you protecting against, what can they do, and what happens if they succeed. Tool choices follow from that, and they differ enormously depending on the answers.
Where aliases do have a place
A narrow, real one: separating your ordinary life from your work. Per-service addresses for shopping, subscriptions and admin keep that surface tidy and attributable, and reduce the volume of noise you're wading through.
That's housekeeping, not protection. Keep it firmly separate in your head from source contact and sensitive correspondence, and don't let a tidy inbox create a feeling of security that the tooling doesn't support.
The one thing to take from this
The dangerous failure mode isn't using the wrong tool โ it's using a mild tool and believing it's a strong one. An alias feels like protection, which is exactly what makes it risky if your actual threat model needs more. If any of this describes your situation, start with the organisations above rather than with us.