Your email address is your passport. And it's public.

A lawyer pays £600/year for an “encrypted and anonymous” email service. She uses the same address for LinkedIn, a healthcare booking platform, her building management company, and three M&A deal platforms. The encryption is real. The anonymity is theater.

The common trap

The conversation about email security gets dominated by two things: encryption and provider privacy policies. Both matter — but neither is the primary risk for most people.

Your email address is an identifier first. Its properties as a communication channel are secondary to its function as a universal key that links together your presence across dozens or hundreds of services. When a breach at a travel booking site exposes your email address, what the attacker gets is not just a way to send you phishing emails. They get a key that, combined with other data, helps map your broader digital identity.

The lawyer in the story above is paying for end-to-end encryption between herself and her encrypted email provider. That encryption is genuinely valuable against one specific threat: the email provider itself reading her messages. It offers zero protection against the following: a breach at the healthcare booking platform (which has her address in cleartext in their user database), her building management company’s insecure email server, a phishing attack that targets her LinkedIn-linked address, or a credential stuffing attack using credentials from any one of those services.

Choosing an encrypted email provider is a hygiene decision. Choosing how many contexts you link to a single address is a structural decision. The structural decision matters more.

Your email address as an identifier

Every service you register with using an email address creates an association: this email address is linked to a person who uses this service. That association persists in the service’s database, in any backups, in any breach dataset derived from those backups, and in any data broker who purchases breach data or user data from the service.

Over time, your primary email address accumulates associations: employer, healthcare providers, financial services, e-commerce accounts, newsletter subscriptions, old forum registrations, conference registrations, hotel loyalty programs, app accounts you’ve forgotten about. Each association is an entry point for:

• Credential stuffing (reused password from another breach)
• Phishing tailored to known associations
• Social engineering attacks using known account information
• Data broker profile enrichment

The email address itself becomes a meaningful data point, separate from any individual breach. “This email address is associated with these services, these geographic locations, these behavioral patterns” is a profile that emerges from the aggregate of associations — regardless of whether any individual service was breached.

Provider comparison: what actually matters

Proton Mail

Proton offers end-to-end encryption for messages between Proton accounts, and zero-access encryption for messages at rest. Their servers cannot read your email content. They’re incorporated in Switzerland under Swiss law, which offers meaningful privacy protections.

Proton’s published threat model is honest about what they protect and don’t protect: they protect against Proton itself being compelled to hand over email content. They do not protect against metadata (who you communicate with, when, from what IP if you’re not using Proton VPN), against messages sent to or received from non-Proton accounts (these are stored encrypted with the recipient’s key but pass through standard SMTP), or against device compromise.

Useful for: sensitive communications where content confidentiality against the provider matters. Legal matters. Journalism. Sensitive professional contexts.

Not a solution for: the identifier problem described above. Your Proton address used as a universal registration email is no better than Gmail for identity compartmentation purposes.

Tuta (formerly Tutanota)

Similar to Proton in principle: end-to-end encryption for Tuta-to-Tuta messages, German jurisdiction, zero-knowledge on their end. The implementation differs technically from Proton (Tuta uses their own encryption scheme rather than PGP), and the ecosystem is smaller.

Tuta is a strong option for users who want a European-jurisdiction, encrypted provider and find Proton’s price point high. The functionality is somewhat more limited (no PGP for external messages, fewer integrations), but for a dedicated sensitive email address it works well.

Fastmail

Australian company, no end-to-end encryption. They can read your email. They will comply with lawful requests from Australian authorities. Fastmail is not a privacy-first provider in the same sense as Proton or Tuta.

What Fastmail is excellent at: reliable, professional email with strong custom domain support, good deliverability, and good integration with alias systems. For a public professional identity where content encryption isn’t the priority, Fastmail is one of the best-run services available.

Migadu

Small Swiss provider. No end-to-end encryption by default, but supports PGP. Attractive for its custom domain model: one flat subscription for unlimited domains and mailboxes. Good choice for managing multiple professional identities under your own domains.

Mailbox.org

German provider, strong privacy stance, GDPR-native. Supports PGP and has good alias functionality. A reasonable middle ground between Proton’s security focus and Fastmail’s convenience.

Gmail and Outlook

Google and Microsoft read your email. They use it for advertising targeting (Google, openly) and service improvement (both). They will comply with US law enforcement requests. They are not appropriate for sensitive professional or sensitive personal use.

They are, however, extremely reliable, extremely well-resourced from a security standpoint (neither was breached in the same way smaller providers have been), and universally integrated. For a public-facing identity where the primary risk is credential compromise rather than content surveillance, Gmail is not obviously worse than many alternatives — but you should be clear-eyed about what you’re trading.

Email alias systems

Aliases solve the identifier aggregation problem in a practical, maintainable way. Instead of giving every service your real email address, you give them a unique alias that forwards to your real inbox. Each service gets a different address. If one address is breached, you disable it. The others are unaffected.

SimpleLogin (now owned by Proton, integrated into the Proton ecosystem): the most mature alias service. Create unlimited aliases on their domain or your own domain. When an alias starts receiving spam or breach-related emails, disable it. The most flexible option for power users.

addy.io (formerly AnonAddy): open source, self-hostable, strong privacy stance. Free tier supports a good number of aliases. Good alternative to SimpleLogin if you want the self-hosted option.

iCloud Hide My Email: Apple’s built-in alias system. Creates random addresses that forward to your Apple ID email. Limited features but zero friction for Apple users. Works well for service registrations that you don’t care deeply about.

DuckDuckGo Email Protection: creates a @duck.com forwarding address that strips tracking pixels from forwarded emails. Simple, free, limited — but removes email tracking as a secondary benefit.

The practical workflow: create a unique alias for every service you register with. Use a naming convention that makes the source identifiable when you receive email through it (e.g., your-tag+amazon@simplelogin.io). Review and disable aliases when they start receiving suspicious volume.

The three-identity email architecture

Translating the identity compartmentation model (see that article) into an email architecture:

Civil identity email: your legal identity. Banking, government, insurance, healthcare. Ideally on a custom domain you control (not a free provider you could lose access to). Not shared outside civil contexts. Proton, Tuta, or Fastmail on a custom domain. No aliases — this address is for real-name contexts only.

Public professional email: your visible work identity. LinkedIn, professional associations, conference registrations, clients who know you by name in a professional context. Can be your work email if that’s appropriate, or a dedicated professional address. The standard here is “comfortable having any employer, journalist, or client see this.”

Sensitive and operational email: everything else. Use an alias system here, not a fixed address. Each service gets its own alias. Your real inbox (the forwarding target) is a dedicated address that doesn’t appear anywhere publicly. When an alias is compromised, disable it without touching anything else.

Common mistakes

Same address for LinkedIn and sensitive work. LinkedIn is a public platform with a large data footprint. Any breach of LinkedIn-associated data traces back to that address — and if it’s also your address for confidential M&A work, you’ve created a direct link between your public professional profile and your most sensitive activities.

Using your employer’s email for personal services. Your employer email is controlled by your employer’s IT department. When you leave, the address is deactivated. Every account you registered with it is now disconnected from an address you can no longer access. And IT can read your email.

No alias system. Every service registration uses your real address. Every breach in any of those services exposes your real address and links it to that service. Within a few years, your address is in dozens of breach databases with well-mapped service associations.

Encrypted provider as a security blanket. “I use Proton, so I’m secure.” Content encryption is one layer of one threat. Your Proton address on your public LinkedIn profile, used to register for 50 services over 5 years, is exposed in exactly the same ways as a Gmail address would be.

No backup address. Your email account gets taken over, suspended, or you lose your 2FA device. If you have no backup access method and no recovery address, everything linked to that inbox is gone.

• N1 Count how many services are registered with your primary email address — if it's over 30, you have a concentration problem
• N2 Separate your civil identity email from your professional email if they're currently the same address
• N2 Set up an email alias service (SimpleLogin or addy.io) for new service registrations
• N2 Create a dedicated sensitive/operational email address on a provider you control, not linked to your public identity
• N2 Audit your most sensitive accounts and confirm each uses an address that can't easily be linked to your public professional identity
• N2 Set up proper 2FA and a recovery method for each of your real email inboxes
• N3 Migrate the highest-risk services from your exposed primary address to dedicated aliases