Encrypted email and why it never took off
The promise was simple, the plumbing wasn’t
Phil Zimmermann released PGP in 1991 with a straightforward pitch: encrypt your email so that only the intended recipient can read it. Three decades later, most people still send email in the clear, and the ones who don’t are usually a small, self-selecting group of journalists, activists, sysadmins, and privacy hobbyists. That gap is worth explaining, because it’s not a story about weak encryption. The math behind PGP and S/MIME has held up fine. It’s a story about what happens when you bolt strong cryptography onto a protocol and a user habit that were never designed for it.
What “encrypted” actually covers
“Encrypted email” gets used loosely, and the loose usage hides an important distinction. There are two separate things happening:
Transport encryption (TLS, usually via STARTTLS) protects your message while it’s moving between mail servers. Most major providers support this now, so a message hopping from your provider to Gmail or Outlook is typically encrypted in transit. But STARTTLS is opportunistic in a lot of configurations, meaning if the receiving server doesn’t offer TLS, the connection can silently fall back to plaintext. Neither sender nor recipient usually sees that downgrade happen.
End-to-end encryption (PGP, S/MIME, or a provider’s proprietary scheme) protects the message body itself, so that even the mail servers handling it in between can’t read the content. This is what people usually mean when they say “encrypted email,” and it’s the part that never got broad adoption.
At-rest encryption protects stored mail on the provider’s servers. Many providers encrypt mailboxes at rest, but if the provider holds the decryption keys, that protects you from someone stealing a hard drive, not from the provider itself reading your mail or being compelled to hand it over in decrypted form.
Providers marketed as “encrypted email providers” usually mean some combination of these, and the marketing rarely spells out which one applies to a given message.
The key exchange problem
End-to-end encryption requires both people to have it set up before the conversation starts. With PGP, that means generating a keypair, publishing your public key somewhere the other person can find it, and ideally verifying that the key actually belongs to them rather than an impersonator, usually by comparing a fingerprint over a separate channel. Almost nobody does the verification step. Most people who do use PGP skip straight to “does this key have the right name on it” and hope for the best.
This isn’t a minor inconvenience, it’s the whole reason adoption stalled. Encryption that depends on two people coordinating a setup step before they can talk defeats the purpose of email, which is that you can message someone you’ve never contacted before. Compare that to TLS on the web, which happens automatically without either party doing anything. Email encryption never got that kind of invisible default.
Webmail wasn’t built for this
PGP was designed back when mail lived in a local client, where your private key sat on your own machine and the software that read your mail was the same software doing the decryption. Then webmail broke that model. Completely. So what happens if your mail lives in a browser tab? You get one of two arrangements. Either the provider holds your private key on their servers, which changes the trust model entirely, since you’re now trusting them not to read your mail rather than trusting math. Or you run a browser extension like Mailvelope that manages keys client-side. That works, and it adds friction most people won’t accept for a day-to-day inbox.
Providers that built encryption in from the start, rather than bolting it onto existing webmail, generally handle the key management themselves and encrypt on the client side before anything reaches their servers. That’s a real architectural difference from a standard webmail provider, but it comes with its own tradeoff described below.
The walled garden problem
Providers like Proton Mail and Tutanota encrypt messages end-to-end automatically when you’re emailing another user on the same service, because both ends already speak the same encryption scheme and the provider handles key exchange invisibly. Email someone on Gmail or Outlook, though, and that automatic end-to-end layer generally doesn’t apply, because the recipient’s mail server has no way to participate in it. Depending on the provider, that outbound message either travels as a normal message secured only by transport encryption, or requires the sender to set up a manual password-protected message as a workaround. Either way, the “encrypted” guarantee people associate with these services is often strongest inside the provider’s own walls and weaker the moment the conversation crosses onto ordinary email infrastructure.
Metadata never went away
Even with a fully encrypted message body, the envelope around it is still exposed: sender address, recipient address, subject line in many configurations, timestamps, message size, and the IP information involved in routing the message. That’s enough for a lot of analysis without ever touching the content. Encrypting a message hides what you said, not that you said something, to whom, and roughly when. Some providers minimize what they log server-side, which reduces what could be exposed in a breach or handed over on request, but that’s a separate design choice from body encryption and shouldn’t be assumed to come bundled with it.
Enterprise didn’t bite either
Businesses had their own reasons to stay away. Legal holds, e-discovery, and compliance scanning all depend on someone, whether IT, legal, or an automated data-loss-prevention tool, being able to read mail content. End-to-end encryption breaks that by design, since the whole point is that intermediaries can’t read the payload. S/MIME, the enterprise-oriented standard, also requires a public key infrastructure to issue and manage certificates. That’s real ongoing overhead. Somebody in IT owns it. And it’s hard to justify when most internal risk conversations are about phishing and credential theft rather than mail server eavesdropping.
Key loss has no graceful failure
Ordinary webmail has a familiar safety net: forget your password, verify your identity another way, get back in. End-to-end encrypted mail doesn’t have an equivalent for lost private keys, because the entire security model depends on the provider not being able to reconstruct that key for you. Lose it without a backup and your old messages are gone, full stop. That’s a reasonable tradeoff for someone who understands it going in, and a nasty surprise for someone who doesn’t. It’s part of why encrypted email services generally warn users heavily about backing up recovery keys or phrases, and why average users, who are used to “forgot password” flows working, find that friction jarring.
What it’s actually good for
Encrypted email is genuinely useful for a specific and fairly narrow slice of a broader threat model: it limits what a breached mail server can expose in bulk, and it limits what a provider can hand over as readable content if compelled to disclose data it holds. If a provider architecturally cannot decrypt your messages, that’s a real, verifiable constraint on what they can produce, distinct from a policy promise. That’s worth something if your concern is server-side exposure of your correspondence’s content.
What it doesn’t fix
It doesn’t hide who you’re emailing, when, or how often. It doesn’t protect a message once it’s decrypted and displayed on a screen that’s already compromised by malware or accessible to someone with physical access to the device. It doesn’t stop a person from being asked, or legally required in some contexts, to produce their own messages after they’ve decrypted them, and nothing here should be read as guidance on how to avoid that kind of obligation. And no single provider, protocol, or app makes someone private end to end. Encrypted email closes one gap in a threat model, it doesn’t close the model.
Choosing a provider without the hype
If you’re evaluating encrypted email providers, the useful questions are boring ones: does the provider publish its encryption implementation for outside review, is encryption automatic between its own users or something you have to configure manually, what happens to a message the moment it leaves the provider’s ecosystem, what does the provider actually log about sender and recipient metadata, and what’s the account recovery story if you lose access. Names like Proton Mail, Tutanota and Mailfence come up often here, because they build end-to-end encryption into their core design rather than adding it as an extension. The right fit depends on who you’re actually emailing. And on whether they’ll move to the same platform. That’s still the main lever deciding whether a conversation gets end-to-end protection or just the transport-level kind.
Encrypted email didn’t fail because the cryptography was bad. It stayed a niche tool because it demanded coordination and tolerance for friction that ordinary email never required, and because the parts of the problem it solves well, server-side content exposure, are only one piece of what people actually worry about when they say they want private email.
Want more breakdowns like this one that separate what a privacy tool actually does from what it’s marketed as doing? Head back to The Privacy Wire for more explainers.