Everything You Need to Know About Email Encryption in 2026

If you think about emails as if they’re anything but the digital equivalent of a postcard–that is to say, they provide zero confidentiality–then someone lied to you and I’m sorry you had to find out from a furry blog that sometimes talks about applied cryptography.

CMYKat

At the end of 2025, at the 39th Chaos Communications Congress in Hamburg, Germany, a team of security researchers posted some devastating vulnerabilities in PGP software (with a focus on GnuPG), and published them at gpg.fail.

Note: They also discussed a minisign vulnerability and another attacking age’s plugin system, but these were much less severe than some of the GnuPG vulns.

This disclosure reignited message board debates about GnuPG, OpenPGP, and related topics. I’m not going to reiterate the many problems with PGP or what you should use instead.

Instead, I want to explain why cryptographers and security engineers that work on cryptography have largely abandoned any efforts to make “encrypted email” happen.

Why People Want to Encrypt Email

Email is not simple. Even before you get into protocol discussions, email is actually several things bundled into one software package:

The most basic mental model for email is an asynchronous “store-and-forward” message sent from you to other parties.
- Not to mention the notion of Cc: and Bcc: fields.
Email addresses are an identity anchor for most of the Internet.
- Forgot your password? Don’t worry, we’ll just… send you an email. Wow.
Mailing lists allow members of a group to send an email once and have everyone else receive an identical copy.

The way society uses email (at least in the United States, anyway) has conditioned everyone to treat email as more reliable than it actually is.

So it’s really no wonder that email is how most medical, legal, and financial workers operate in their day-to-day (assuming they aren’t using certified mail or fax machines).

But then the security nerds point out that:

SMTP, the protocol for sending email, rarely enforces TLS (if it’s even supported at all)
STARTLS, an opportunistic attempt to increase TLS usage for email protocols, is trivially stripped by active attackers
Emails are not end-to-end encrypted between inboxes

…it’s tempting to rush to PGP or S/MIME to reclaim a bit of privacy for your communications.

If that doesn’t make you feel all warm and fuzzy, remember that many industries still use FTP to transfer encrypted ZIP files back and forth in 2026.

Then, when even more security nerds point out how bad PGP and S/MIME are (EFAIL, gpg.fail, Why Johnny Can’t Encrypt, etc.), everyone gets frustrated.

How Email Encryption Fails

Let’s set aside all the security vulnerabilities for a moment and explore an extremely common failure mode.

Suppose you send some of your friends an encrypted email.

First, your friends need to have their own private/public key pairs and exchange public keys with each other.

In PGP land, this sometimes meant setting up a “key signing party” to attest to each other’s identities, so that others could see these vouches from the “Web of Trust”. (This was a really big thing right after the Snowden leaks.)

But for simplicity, let’s ignore PGP entirely.

Let’s say you do all this, and successfully begin sending encrypted emails. Hooray!

How long until one of them, in a hurry, hits “Reply All” without encrypting first?

This exact kind of failure happens all the time with encrypted email solutions.

And since email responses, by default, quote the thing they’re replying to, this kind of mistake can leak the entire message chain leading up to the mistake too.

One of the main reasons I recommend Signal is because there is no plaintext mode to accidentally use.

But you can forward/screenshot Signal…

Sure, you can go out of your way to bypass the encryption if you want to. No one disputes that.

But what you cannot do with Signal is accidentally emit plaintext to the Internet by using the Reply feature.

With encrypted emails, the “accidentally disclose a bunch of plaintext” footgun is in the hot path of the user experience.

These are very different propositions of misuse and anyone that conflates them is being dishonest because they want to mislead you.

CMYKat

It Gets Worse, Of Course

One of the limitations of encrypting the message body of emails is that there is still a ton of metadata that gets transmitted in the clear (i.e., often without even transport-layer encryption).

If nothing else, a passive adversary learns the following:

The To: and Cc: fields (and, practically, always the Bcc: field)
The subject line for the email
Timestamps
Attachment metadata (file names, types)
DKIM signatures (more on that in a minute)
IP addresses (this one is included for completeness, since people forget about it)

But the subject line is the most critical. Users and software alike use the subject line to file replies into neat “threads”.

Unfortunately, knowing the subject line and which person replied to whom at what point in time can tell you a lot even if you can’t read the message contents.

So now you’re forced to choose between perfect operational security discipline 100% of the time and using software in a totally normal way.

But that’s just metadata!

Nation-state spy agencies use metadata to decide who to kill.

If you care about privacy, you should never send this kind of extremely sensitive metadata in the clear.

Even if you take nation states off the table, private intelligence companies like Palantir and their international competitors are almost certainly up to no good.

CMYKat

Enter, Non-Repudiation

DKIM (RFC 4871), published in 2007, is an Internet Standard with near-universal adoption among email providers.

Without getting too technical, DKIM publishes a digital signature of every message sent from an email server. This signature was intended as an anti-spam measure, since the original email protocols were extremely permissive about senders.

In practice, this means that every email you send (even if it’s encrypted) has an additional layer of non-repudiation baked into it.

This means that, for example, every email you’ve ever sent through Gmail can be cryptographically proven to have been sent through Gmail’s servers. Even worse, this proof can be verified without Google’s involvement.

Non-repudiation is not a desirable property for private communications, as Ryan Castellucci explains in their blog post, DKIM: Show Your Privates.

This is the worst of all possible worlds

You have virtually no email privacy. They’re like postcards, not envelopes.
Anyone that sees your email can effectively prove you sent it (modulo your account or provider getting hacked).
Even if you try to staple encryption onto your message contents, enough metadata gets leaked to still harm you.

At this point you might be wondering (especially if you work in tech), “Why hasn’t anyone tried to fix this?”

Email Cannot Be Salvaged

The main blockers for any proposal to fix email (updated RFCs, better use of encryption) have nothing to do with technology and everything to do with politics.

Repeat after me: all technical problems of sufficient scope or impact are actually political problems first.

Eleanor Saitta

Despite being an open protocol, email is (in practice) an oligopoly.

You cannot code your way out of social or political problems. Not directly, anyway.

CMYKat

Protocol Upgrades Have Been Proposed Before

At the very first year of the Crypto & Privacy Village at DEFCON (the year following the Snowden leaks), Adam Caudill proposed SMIMP as a way to make email secure and leak less metadata.

Neither SMIMP nor any other proposal to make emails private and secure have gained traction with the oligopoly that controls email, nor the governments that regulate them.

I need to emphasize, this isn’t due to a lack of awareness or effort. The big players have no incentive to change.

Setting aside that the “anti-regulation” party controls the United States right now, governments love to surveil their citizens..

Don’t believe me? Look no further than the EU’s recent Chat Control debacle for evidence of this. Just because a government launders their large-scale surveillance laws through the language of “keeping children safe” or “stopping terrorism” doesn’t mean that wasn’t their actual goal all along. The purpose of a system is what it does.

When you ask most people about privacy laws, they’ll blurt out something akin to “I have nothing to hide” and stop thinking about it entirely. You can draw a neat line between citizen apathy towards online privacy and the inertia on fixing email security by the big tech players.

Until the political climate changes, don’t count on email ever being fixed.

Privacy Tech Companies Are Not Silver Bullets

Please resist the temptation to think if you use a VPN service or a service like ProtonMail (which uses PGP) that you can magically be more secure than everyone else. It doesn’t work like that.

Here are some questions to ask yourself:

How are secret keys managed?
How are public keys managed? (Trust on first use, web of trust, etc.?)
Where does the encryption take place, and where does that code come from?
What doesn’t get encrypted? (Subject lines, etc.)
How does this work for people not using the same service? Does everything silently downgrade to plaintext?

If you stare at any of these vendors for long enough, you’ll find that they provide at best a homeopathic level of privacy against any sophisticated adversaries.

TL;DR

Just don’t bother with email encryption. It’s a doomed effort.

I know that sounds rude or dismissive, but the situation is completely terrible and there’s no real political will to fix it. And you need political will to fix it.