Why end-to-end email encryption never became the default
Email wasn’t built with privacy in mind. When you send a message, it passes through multiple servers that can see everything unless you add your own layer of protection. Over the years, several teams have tried to bolt real end-to-end encryption onto email. Each attempt pushed the industry forward, even if none became the default.
PEM: The early blueprint
Privacy Enhanced Mail (PEM) was one of the first serious attempts to add encryption to email. You can think of it as an early blueprint for how secure email could work if everyone agreed on the same rules for identity and trust.
PEM wrapped messages in a standardized format and used public-key cryptography to protect them. It was ambitious, but it made one big assumption: that a centralized certificate authority system would emerge for everyday email users. That never happened. PEM stayed mostly on paper and in research environments, but it planted ideas that later projects borrowed.
Further reading: The original PEM design lives in RFC 1421, RFC 1422, RFC 1423, and RFC 1424.
PGP: Empowering individuals
Pretty Good Privacy (PGP) arrived in the 1990s with a simpler idea: let people create and manage their own keys. Instead of depending on a central authority, PGP used a “web of trust” where users vouched for each other’s keys.
PGP proved that end-to-end encryption could work in the real world. Activists, journalists, and technically savvy communities used it heavily. But it also showed how hard encryption can be for the average person. Key management and trust decisions made PGP powerful but intimidating.
PGP also revealed something bigger about encrypted email: you can’t build a global solution around a single developer or a single company. PGP started as a personal project and later moved through commercial hands, which made it clear how fragile adoption becomes when the whole ecosystem depends on one person or one company.
GPG: The open source successor
GNU Privacy Guard (GPG) stepped in to reduce that dependence. It re-implemented the PGP approach in open source form so the community could own and maintain it. Most people now use “PGP” and “GPG” interchangeably, but GPG is the tool that’s actively maintained and widely integrated.
GPG kept the same strengths and weaknesses as PGP. It’s flexible, secure, and respected, yet still requires people to manage keys, signatures, revocation, and trust — all things most email users aren’t trained for. GPG became a standard tool for developers and security professionals, but it never crossed over into everyday email.
Newer efforts like “Autocrypt” and “Pretty Easy Privacy” build on OpenPGP and try to automate key exchange and trust decisions, but they haven’t changed adoption at Internet scale.
Further reading: Unlike PGP, GPG was built around OpenPGP, formalized in RFC 4880 and updated by RFC 9580.
S/MIME: Encryption for enterprises
Secure/Multipurpose Internet Mail Extensions (S/MIME) took a different path. Instead of asking users to manage their own trust relationships, S/MIME relied on certificate authorities (CAs), the same chain-of-trust model that powers HTTPS. That meant it could reuse a trust system the Internet already understood.
What S/MIME couldn’t reuse were the certificates themselves. By design, S/MIME tied encryption to individual people rather than domains, which meant it needed a new kind of certificate that wasn’t part of the free, automated ecosystem that later pushed HTTPS adoption. These personal certificates cost money and usually require manual setup, renewal, and installation on every device.
This is why S/MIME found its home in enterprises. Large organizations and governments could issue and maintain certificates centrally, making encryption feel seamless for employees. For everyone else, the cost and complexity of managing a personal certificate kept S/MIME from becoming a default for everyday email.
Further reading: S/MIME is formalized in RFC 8551 and its companion RFC 8550.
Secure email services: Controlling both ends
Rather than trying to change how the entire email ecosystem works, services like Proton, Tuta, and others built their own environment and control both sides of the conversation. Inside that environment, they can automate the hard parts: generating keys, exchanging them, rotating them, and keeping everything in sync across devices. It’s the same idea that makes end-to-end encrypted messengers like Signal work so smoothly.
They also publish users’ OpenPGP keys through modern discovery standards, which means messages between these services can be end-to-end encrypted when both sides support it. But the moment an email leaves that circle, e.g. when a Proton user writes to someone on Yahoo, it falls back to the normal email flow.
These services didn’t solve end-to-end encryption for email as a whole — only for the part they control. But they show that people will gladly use encrypted email when it feels effortless.
Where we are now
Email still doesn’t have a single, shared way to keep messages private from the moment you hit send to the moment they arrive. Most attempts either rely on complex choices most people won’t take on, or they work only inside a provider’s own environment. And while much of today’s email is protected in transit, it’s still readable to the providers and systems that move it along the way — which is very different from true end-to-end encryption.
What we’ve gained is a clearer view of what a real solution would require. It has to be automatic, built on shared foundations, and effortless for the person sending the message. Until those pieces align, encrypted email will continue to work well in isolated pockets, but not across the entire network.