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…

http://soatok.blog/2026/01/04/everything-you-need-to-know-about-email-encryption-in-2026/

@soatok great article thank you :)

Here is a typo I think: " (tthe year following the Snowden leaks)" "tthe".

Sincerely

@nemo Thanks!

@soatok I'm running a few mail servers, and I had to set up explicit TLS for some destinations (basically, refuse unencrypted connections when delivering to specific domains; apparently that's deemed secure enough in some circles).
Had a funny anecdote, too – Let's Encrypt switched to ec certificates, which caused postfix to automatically disable some older encryption types, and suddenly one of those servers couldn't deliver to my client any more, because they were still running Exchange 2016 which does not support TLS 1.3…

@jernej__s Everyone I know that deals with email professionally has horror stories associated with "trying to improve things somewhat" lol

@soatok

That is a good article to bookmark and send to others as a reference.

Whenever I talk with someone about Email, my standard sentence is always: "It's broken. No, I cannot fix it. No one can"

@soatok @jrenken i agree with the message to treat email like a postcard from the DDR, but my understand is that most serious email providers like Gmail and ProtonMail offer end-to-end encryption by default within their service without the footguns of PGP plugins (Google can read the emails once they are at rest, Proton claims not)

@arbutus @jrenken If Google can read the emails once they are at rest, then it isn't really end-to-end encrypted. That's just transport-layer encryption. Words mean things.

Take a look at the previous articles I linked (especially the Latacora one) and ask yourself, "Do I really want PGP?"

Proton uses PGP.

The primary motivation to use PGP is backwards compatibility. PGP has been around since the 1990s, and it shows in its design.

If you want to use PGP "safely" (i.e., with modern AEADs, like Sequoia and presumably Proton? use), you sacrifice backwards compatibility... at which point, you're better off using something better like age instead.

@arbutus @jrenken But even if it's true that Proton uses PGP "without the footguns", the metadata problem is still endemic to email.

How are subject lines encrypted?

How does this encryption work with non-Proton customers?

How are secret keys managed? Does Proton pass the Mud Puddle Test?

There's a lot to dislike about Proton.

@soatok The main issue I'm now seeing with email encryption is *not* the GPG flaws, but people thinking that because Outlook pushes you to use the proprietary Microsoft encryption "solutions" (in which you hand them over your private keys) this is what we have to use now. And they won't listen to anything else.

@renard Yeah, there's going to be a Part 2 to this blog post later this year when I talk about what to replace email with that gets the same User Experience :P

It won't be compatible with email

It won't even have a plaintext mode

Should be a fun time :3

@soatok @arbutus @jrenken
I would change of idea if for example you decrypt this short&simple message:
-----BEGIN PGP MESSAGE-----

wV4D+1vtTHzye40SAQdATbtx45MvPKrzZ63HxwLxrvx5YAx4LJvsVxCIbhJYql8w
0aynKgQ9xbPDGW2oou1PXDV91QIAl7UQbF035HUmeSZdwIrlxzk23PXt9GEHssBR
0kcBkpyBcWkvfZato5yHuXO9DRIIgGN8LafOxIjtzJdI0STYDNyVnijRRAgcT60R
mWzvhRMz2SBR2X8evBV/KWvKFtdCIXm+Sg==
=IeO+
-----END PGP MESSAGE-----
Even with all concerns the previous text isnt gonna be decrypted and/or scraped by ai.Plain text will

@antoniovr @arbutus @jrenken No, I'm not interested in this conversation.

Read https://www.cryptofails.com/post/70546720222/telegrams-cryptanalysis-contest if you're curious why I'm disengaging from this.

@soatok I think the CSS kinda broke on this one?

@spud @soatok Daw, he looks so sad about it, too :c

@soatok I really wish that this story was different, that after years of effort by so many, that we could be celebrating a major improvement - it’s where we should have been by now. Instead, we’re looking at a burning wreck that’s no longer worth the effort to fix.

Really is sad, it could have been so different.

@soatok Typo: “Why Johnny Can’ Encrypt” is missing a t

@mischif Thanks

@soatok the main things I disagree with are "append-only directories with Merkle trees" and "users should start with more than zero trust."

The HKP network is append-only, and people have started spamming it. Adding a cryptographic layer on top to enforce the append-only aspect looks like an additional security measure now, but becomes a roadblock once the spam starts.

And new users starting with more than zero trust is an incentive to create more spam identities -- interestingly, spam in the HKP network mostly consists of UIDs added to existing keys, not newly created keys, because these keys cannot be connected to the web of trust easily, so they have no useful purpose.

@GyrosGeier You picked an interesting (read: unrelated) blog post to reply to with criticisms of key transparency.

@soatok oof, I seem to have followed a link and not noticed it was not part of the same post. I'm fairly sure I started reading with this post though.

My apologies.

@GyrosGeier It happens to the best of us! I just get a lot of replies like this and sometimes I can't tell if they're making a legitimate mistake or if they're being trolls. I've found a dash of sarcasm usually susses out their motives :P

@GyrosGeier Anyway, this kind of spam isn't really a massive problem for my design.

Getting an Ed25519 key registered for a spam identity only helps you as long as the instance admin hasn't blocked you (and/or the instance hasn't been defederated). Once you have one, all the key transparency stuff lets you do is have client-side signing of MLS keyPackage bundles (which is the direction ActivityPub-E2EE is heading). But this is still an encryption for messages going over ActivityPub, which implies ongoing access to your instance. It doesn't, for example, let you spam thousands of users after your access has been revoked by the moderators.

You seem to have a different understanding of what I mean by "more than zero trust".

I don't mean, like, PGP trust policy bullshit. I just mean you know you're seeing the same public key as everyone else will see.

@vvelox

It is not a question of political will, but available dev time.

Who allocates dev time?

@vvelox Like, if your rebuttal to "this is a political problem" is "no it's only solvable by organizing stakeholders and labor to build and utilize the tools needed to solve the desired problem while benefiting in their own ways" and don't realize you just described politics, I'm not sure how to do better at explaining myself.

@soatok Like anything thing opensource... corp, gov, or self. It is a question getting enough parties interested that they can can through the dev time needed at something.

But you are missing the point of my post. Some one throwing out a idea and fucking off is basically the same as doing nothing. It requires a willingness to build on that idea as well.

@vvelox Are you implying that @adam_caudill wasn't willing to build on his idea with SMIMP in 2014?

@soatok Also true but honestly with how you meandered into totally unreleated stuff in your blog post it was not clear if you actually understood that or not.

If that is what you mean by political, then sure, but it was not the fucky gov/corp stuff you mentioned. Telling that group to fuck off is totally doable and has happened before in this realm.

You never touched on this in that post and this frankly is the biggest stumbling block, be it changing anything with email or writing a replacement.

@vvelox You're absolutely right.

That's why I write open source software in languages that are accessible to a large number of developers (JavaScript, PHP) rather than the ones cryptographers traditionally considered good (C, C++, C#, and recently Rust and Go).

If you don't meet people where they are, there's a 0% chance anyone will want to build on it.

Email became, for lack of a better word, gentrified by corporations. If you want adoption by the same players, you have to play their game. If you want them to fuck off, you have to outplay them.

Both are tall orders. But not impossible.

@soatok S-tier first paragraph

@soatok the subject field is primarily used by humans and some email clients might put them in the encrypted body but the whole threading info (what message replies to what other message) is entirely in plaintext and might leak other identifiers such as system hostnames

email sucks

@charlotte @soatok Yeah though it is sad how for some of the things we use it for there still isn't a good alternative. That said with things like signal, wormhole, etc for most of what email was used for better alternatives are already here

@charlotte @soatok

So when it comes to metadata that servers need, subject would actually be one of those.

If writing a replacement for email, you are going to either need Sieve or a replacement for it if you choose data storage format that differs. Trying to avoid this you quickly run into scaling issues in terms of data that need moved between the client and server. That said this may be unavoidable given something like this will require a chunk of spam processing be done on the client side already.

If one seeks to avoid that, one is basically looking at avoiding IMAP+Sieve and limiting it to SMTP+POP3 only, which quickly becomes a bit limiting in terms of what email is commonly expected to be these days.

At this point I think the big question is if writing a replacement do you want something that you can write light weight clients such as with IMAP+Sieve do you want to basically forsake the idea of storing anything server side and rely on nearly all sorting, anti-spam, and storage to be done client side like in the bad old days of email when it was basically SMTP+POP3 for people?

@vvelox @charlotte @deetwenty This is all very much "curse of knowledge" territory.

The reason servers need that metadata isn't inherent to the problem they're trying to solve, it's a result of technical decisions made by fallible mortals once upon a time and reinforced over decades.

@soatok @charlotte

Only true if you limit your understanding of email to like POP3 and believe all spam filtering should be done client side.

Also keep in mind stuff like sender/receiver is metadata and there is no way to avoid the server knowing that.

@vvelox @charlotte @deetwenty No, you're missing what I was saying.

@soatok Then I think you need to work on explaining it better as you seem to be missing what I am saying.

@soatok @vvelox @deetwenty effective filtering and indexing needs access to the message contents as well.

imo email inbox sizes are also quite managable to have on device as well, I have most emails i received for 5 years and the email content alone is less than 1GB. a big chunk of that is just down do the inherent inefficiencies of specifically email (like probably 300 or so megabytes are just to support systems that have 7 bits in a byte).

I also don’t think email inboxes would be as large if they weren’t used for everything from authentication over push notifications to public forums

@vvelox @deetwenty @charlotte You're so zeroed in on the what that you're missing the fact that I'm focused on the why.

You'll spin yarns about email-specific protocols for lengthy threads because you're taking the specific decisions for granted.

The curse of knowledge is what's causing your confusion.

@charlotte

This actually depends on the message in question. For lots of plain text stuff it is not bad. Sure throwing a file in there will definitely increase size and inefficient thanks to base64 encoding.

@vvelox @soatok @deetwenty even text only messages have the content sent multiple times and potentially base64 encoded. just standard settings in typical email clients. but despite that it’s still reasonable to have on a computer and also is fast to index

@soatok

You said you want to write a replacement for email so that is on you.

So this natually moves discussion in what do you want to achieve and what do you want replacements for various parts of the stack to look like to solve issues that part of the stack is meant to solve.

So let me ask you this...

When you say email, do you mean something for just flinging messages in a decentralized manner or do you mean what the complex message passing systems that is meant to cover a whole host of different use cases like email currently?

Because for lots of the email related uses cases what I am curious about how you want to solve it is sort of important. You are just hand waving it away and saying it is not important.

Your talking to some one who has done lots of coding for various messaging systems, including email, as well as lots of sys admin work related to it.

Basically what you've done is the equivalent me going up to you and saying I have an idea of how to fix X problem in cryptography and then say it will work via magic and refuse to talk about X problem.

@vvelox @deetwenty @charlotte My notion of an email replacement has nothing to do with my latest blog post.

When I talk about replacong email, that is a proposal I will write later in 2026.

@soatok

So a chunk of this thread honestly had little to nothing to do with your blog post at the start.

I was just kicking around various ideas of how one may make chunks of it work as a mental exercise and curiosity. It really raises some interesting questions about making it work and I was engaging with that.

That and a random dive into a some other stuff in regards to email.

@soatok This post is 100% spot on and probably a little too kind.

Shameless plug, but I hope you guys don't mind... dealing with this exact set of problems has become my life's goal. I've been working on an open source E2EE replacement for not just email, but email and Exchange.

Not quite ready for a demo, but hoping for a first alpha release later this year.

https://mensago.org

@jonyoder I am intrigued and wish to learn more

Once upon a time, there was some article with an interview with Robert Morris (former NSA and Bell Labs d00d, author of UNIX crypt among other things, also: the guy who fathered Robert Tappan Morris, of Morris worm infamy) where he said something like: "email can never be secured" alas, I can't remember the quote verbatim and trying to search for anything in 2026 is a fool's errand because A"I" bros broke web crawling with slop.

Similarly, I remember the feelings of cringe I had in Berlin circa 2014 where they had key signing parties, and seemed oblivious that Phil Zimmermann gave up on PGP (also used to be easier to cite, no longer).

There were the "Why Johnny Can't Encrypt" (2005, PDF: https://people.eecs.berkeley.edu/~tygar/papers/Why_Johnny_Cant_Encrypt/OReilly.pdf) and "Why Johnny Still Can't Encrypt" (2011, PDF: https://cups.cs.cmu.edu/soups/2006/posters/sheng-poster_abstract.pdf) papers.

There were the private, HILARIOUS conversations I had with coworkers at iSEC Partners circa 2011 particularly after we got acquired by NCC Group (which used PGP Keyserver, which AMAZINGLY sometimes would only function to decrypt messages after I ... sigh "did things" to reuse old keys, because as their IT Admin: I needed to make things function more than I needed to pretend that their overpaid bullshit was anything more than bullshit).

Alas, that kind of humor, is reserved for a very limited audience. Such lulz though!

Anyway, folks still need reminders I guess!

I wouldn't mention Signal in such reminders, it is its own can of worms and not in good standing.

That said, I miss the days when the S in SMTP was acknowledged as Simple.

The oligopoly of spam havens (e.g. Gmail, Hotmail, Yahoo!, etc.), keeps fucking things up and over-complicating it. SPF, DKIM, DMARC, etc. are just making it worse (if you want an eyeful: https://www.jwz.org/blog/2025/12/today-in-google-broke-email-2/#comments)