OpenPGP and Email: The Hype, the Truth, and the Falsehoods

For twenty-five years, "encrypt your email with PGP" has been the reflexive advice handed to anyone worried about privacy. It shows up in security checklists, journalism-safety guides, and every "how to protect yourself online" listicle. And yet, by any honest measure, end-to-end encrypted email never became a mainstream habit — and it isn't on a trajectory to become one. PGP-encrypted messages are a rounding error against total global email volume. The one place OpenPGP genuinely won is signing software packages, not sending mail.

That gap between reputation and reality is worth explaining properly, because the usual explanation — "the tooling is bad" — is wrong, or at least incomplete. The problems with OpenPGP for email are structural. Better UX doesn't fix them. Here's why, and here's what actually improved email privacy while nobody was looking.

The network effect works against you from message one

Encrypted email only functions if everyone in the thread participates. Not the sender, not the sender and the primary recipient — everyone who might ever be CC'd, forwarded to, or looped in later. The moment one person in a chain doesn't have PGP configured, the thread either drops back to plaintext or simply doesn't happen. Unlike a messaging app, where the network effect can bootstrap because the app itself is the identity system, email's openness is precisely what defeats it: anyone can email anyone, but not everyone has agreed to run the same cryptographic layer on top.

Key discovery was never actually solved

Before you can encrypt to someone, you need their public key, and you need to trust that it's really theirs. This is the part PGP has spent decades failing to solve cleanly. The original solution — public keyservers — had no authentication model at all. Anyone could upload a key claiming to belong to anyone else, and the servers had no way to verify it and, by design, no way to delete or correct it either.

That weakness stopped being theoretical in 2019, when specific well-known keys in the ecosystem were flooded with thousands of bogus signatures. The keyservers' append-only design meant those keys became unparseable by GnuPG clients that tried to fetch them, effectively breaking encryption for the people who owned them. Web Key Directory (WKD) is a real improvement — it ties key lookup to a domain you control instead of an unauthenticated third party — but it's opt-in and far from universally deployed. A discovery mechanism that only some senders and some domains support isn't a solved problem; it's a partial one.

No forward secrecy means old mail is never really safe

Modern secure messaging protocols rotate keys constantly, so that compromising today's key doesn't expose yesterday's conversations. PGP doesn't do this. A single long-lived key encrypts everything sent to you, potentially for years. If that key is ever compromised — a stolen laptop, a weak passphrase, a bug in the client — every message anyone has ever sent you, going back as far as your archive does, is retroactively exposed. For a mechanism sold as "privacy," that's a significant asterisk.

The metadata was never protected

People adopt PGP thinking they're hiding who they're talking to and what they're talking about. In practice, classic PGP/MIME leaves the subject line in cleartext — only the body is encrypted. And even with the body sealed, the envelope metadata (sender, recipient, timestamps, routing) is visible to every mail server the message transits. For journalists, activists, or anyone whose risk model centers on association rather than content, that's often the part that actually matters, and PGP does nothing for it.

Lose the key, lose the mail — permanently

There's no recovery mechanism. If a private key is lost — a failed disk, a forgotten passphrase, a departed employee who didn't hand off their keyring — the encrypted mail tied to that key is gone. Not "hard to get back." Gone. That's an acceptable tradeoff for some threat models and a completely unacceptable one for ordinary users and organizations that need business continuity.

It breaks the client experience

Encrypting mail end-to-end means the server can no longer read it, which sounds like the point — until you notice everything that depended on the server being able to read it. Server-side search stops working on encrypted bodies. Spam and phishing filtering, which relies heavily on content inspection, degrades. Webmail becomes awkward or unusable — having built one, I can say the awkwardness is not a UI problem you can design your way out of; the server genuinely cannot help you any more. Mobile clients, where most email is now read, have historically had the worst PGP support of all. Users didn't reject PGP because they're lazy about security; they rejected a workflow that made email measurably worse to use.

And the clients weren't even safe doing it. EFAIL, disclosed in 2018, showed that PGP and S/MIME implementations could be tricked into exfiltrating plaintext through HTML rendering and malformed MIME structures — the encryption held, but the surrounding client code didn't. It was a reminder that "encrypted" and "secure" aren't the same claim.

So why S/MIME instead — and why not urgently either

If an organization has a real requirement for signed or encrypted mail, S/MIME is generally the more sensible choice over OpenPGP, for reasons that are mostly organizational rather than cryptographic. S/MIME rides on X.509 certificates issued by a CA, which means key discovery and identity verification are handled by infrastructure that already exists in most enterprises — the same PKI used for TLS, VPN auth, and code signing. It integrates natively into Outlook and most enterprise mail clients without a plugin. Certificate revocation is a solved, standard process, unlike the ambiguity of an OpenPGP key with a compromised or lost private key. None of that fixes the network-effect problem or the metadata leakage — both protocols share those — but it does remove the DIY key-management burden that makes PGP painful to operate at scale.

That said, neither protocol is something most people or organizations should treat as urgent. The threat model that end-to-end encrypted email actually addresses — a hostile mail provider or network operator reading message content — is narrower than people assume, and it's one that transport-layer improvements have already substantially closed for the vast majority of traffic. Deploying org-wide S/MIME or PGP is a meaningful undertaking in key management, user training, and workflow disruption, and it's worth reserving for cases with a specific compliance requirement or a genuinely high-value threat model, not adopting reflexively because encryption sounds like the responsible default.

The actual privacy win arrived quietly, and nobody had to opt in

While PGP adoption stayed flat for two decades, the transport layer got dramatically better without requiring a single end user to generate a keypair. STARTTLS became close to universal between mail servers, encrypting the hop-to-hop connection. MTA-STS gave domains a way to enforce that TLS and reject silent downgrade attacks, closing off the strip-the-encryption attacks that plagued opportunistic STARTTLS for years. DANE, where deployed, ties TLS certificate validation to DNSSEC instead of the CA system, removing another class of interception risk.

None of this delivers end-to-end confidentiality — a compromised or subpoenaed mail server can still read the message. But it protects against the threat model that actually accounts for the overwhelming majority of real-world email interception: someone snooping the connection between servers. It did this invisibly, with no user action, no key exchange, and no broken workflow. That's the part of the email privacy story that actually succeeded, and it's telling that it's also the part nobody talks about at conferences.

The takeaway

OpenPGP for email isn't broken tooling waiting for a better UI. It's a protocol whose core assumptions — universal participation, unauthenticated key discovery, static long-lived keys, no metadata protection — were the wrong fit for how people actually use email, and no amount of client polish changes that math. S/MIME sidesteps some of the operational pain for organizations that need it, but it inherits the same structural limits. For almost everyone else, the honest answer is that the mail transport itself already got a lot more private, and that improvement didn't need anyone's participation to work.