SMTP is a postcard with a filing cabinet attached
If you have only ever used Gmail, it is easy to think email is private because login requires a password. Email was designed in an era of trusted universities and benign operators. TLS protects bytes in motion between hops much of the time, but the storage model for mainstream providers still assumes the service can read your mail to index it, train models, scan for ads, and power “smart” features.
I am not anti-cloud. I am anti-confusing “HTTPS on the login page” with “the provider cannot read my archive.” Gmail, Outlook, and Yahoo are excellent productivity products whose business models depend on deep visibility into your communications metadata — and often the content itself.
Attackers love email for the same reason product teams do: it is permanent, searchable, forwardable, and synchronized across every device you have ever owned. Phishing, OAuth token theft, auto-forwarding rules, and mis-typed recipients are not edge cases. They are the baseline threat model.
- Content indexing for search, fraud detection, and product features
- Long-lived OAuth grants to third-party apps
- Account recovery flows that attackers target before they touch your keys
- Forwarding rules that silently duplicate sensitive threads
What “secure email” means to someone who reads RFCs
Privacy-first email providers try to fix different parts of the stack:
Notice what is still hard: SMTP metadata. Who emailed whom, when, subject lines, routing hops — much of that remains visible to the network even when the body is locked. Encrypted email raises the floor dramatically. It does not turn email into a dead-drop system.
This is why I wrote that email is the worst place for secrets. Not because encryption is useless, but because email’s superpowers — permanence, universality, search — are exactly wrong for one-time credentials.
- Zero-access encryption at rest — the operator stores ciphertext, not a readable archive
- Optional true E2EE to other users (provider-native or PGP) so even a lawful request cannot turn up plaintext
- Jurisdiction and transparency reporting that match your threat model
- Open-source clients so researchers can verify what the app actually does
- Alias and hide-my-email features to reduce cross-site identity correlation
Proton Mail: the provider I recommend first
When friends ask for a Gmail replacement they can trust with real correspondence — doctor’s offices, lawyers, financial paperwork — I point them at Proton Mail first. Swiss jurisdiction is not a cartoon privacy shield, but Proton has spent years publishing transparency reports, open-sourcing clients, and building an ecosystem (VPN, Drive, Pass) that hangs together without an ad profile underneath.
Technically, the important bit is zero-access storage: Proton should not be able to hand over readable mail from disk because it should not possess the keys. Combine that with aliases, hardware-key login on paid tiers, and sensible mobile clients, and you have something I am comfortable recommending to non-technical family members.
Tuta (formerly Tutanota) is my second suggestion when someone wants EU hosting and a focused product without US big-tech adjacency. I have colleagues in Germany who prefer it precisely because the stack is narrower — mail, calendar, contacts — and the privacy posture is loud without being performative.
Proton Mail
Swiss privacy law · zero-access · Proton ecosystem
My default recommendation for people leaving Gmail. Zero-access encryption, audited cryptography, and an ecosystem that does not fund itself by reading your inbox.
- Zero-access encryption by default
- Swiss jurisdiction and transparency reports
- Aliases, custom domains, and hardware-key support
- Open-source web client
Tuta
German GDPR host · encrypted calendar & contacts
Strong EU-hosted alternative when you want encrypted mail, calendar, and contacts without a Silicon Valley conglomerate in the loop.
- Encrypted mailbox, calendar, and contacts
- Germany-based infrastructure
- No third-party ad trackers in the web app
- Affordable custom-domain plans
Habits that matter more than the logo on the login page
Provider choice is step one. Step two is using email like someone who has seen breach notifications for a decade. I use unique aliases per service so a leak in one place does not correlate my identities. I turn on hardware security keys anywhere they are supported. I audit OAuth connections quarterly because “Sign in with Google” ages badly.
Never put secrets in subject lines. Assume headers leak. Assume your recipient’s provider is worse than yours. Assume permanence: if you would not print it and mail it in an envelope labeled with both addresses, it does not belong in email.
Encrypted email protects stored bodies, not the fact that you emailed your accountant at 11:58 p.m. For high-stakes credentials, use a one-time link that dies after reading — that is the workflow PrivateNote exists to support.
When I still refuse to use email
Passwords, API tokens, wallet seed phrases, production database URLs, legal hold material I do not want archived forever — **email is out.** Not because I distrust Proton. Because email is the wrong abstraction: it copies, it indexes, it forwards, it litigates.
If you take one thing from this guide: upgrade your inbox, yes. But upgrade your instincts too. The channel should match the lifetime of the secret.