Why Isn’t True Zero-Trust Encryption Used in Email Systems?

Most “secure email” platforms still rely on provider-managed keys:
either the provider generates the user’s key pair, or stores an encrypted copy for sync, or encrypts stored mail with server-side keys. In all cases, the provider retains theoretical decrypting capability.

A strict zero-trust model would require:

user-generated private keys

provider never storing or handling private keys

stored mail encrypted only with the user’s public key

no server-side key material that could decrypt data

provider cryptographically incapable of accessing message content

This model is common in password managers and zero-knowledge file storage, but rarely seen in email.

So the question is:

What stops email providers from adopting true zero-trust storage?

Is it:

key-management friction for users?

multi-device sync challenges?

server-side search/indexing requirements?

business reasons?

or just legacy expectations around email UX?

Curious how others in the dev/crypto community see this.

Comments

[Privacy.Fish]

The hard part is that email still has to interoperate with the outside world, so you can reduce provider access to stored mail, but you cannot make SMTP metadata/content magically zero-knowledge for every non-E2EE recipient. When the provider receives the email, it is unencrypted, unless the sender of the email encrypted it before with gpg or similar.

For us at Privacy.Fish, the practical answer is to remove the permanent hosted mailbox as much as possible: keys stay on the user's devices, email is of course encrypted the second we receive it, email is downloaded locally to the users devices, server copies are encrypted and auto-deleted after 14 days, and there is no webmail/password account for attackers to phish or brute-force.

That does not solve every E2EE-to-non-E2EE edge case, but it changes the risk model from “provider holds a forever mailbox” to “provider has only a short encrypted buffer.” Ready in 1–2 months. Feedback welcome!

At the end of the day, email is broken and it is not possible for the provider to end-to-end encrpyt it. We could end-to-end encrypt @privacy.fish to @privacy.fish, but this is the 0.001% of usecases. Mail from and to @gmail.com and others is still not encrypted.
The best way to deal with this is for the email provider to educate its users about it, which we do, instead of lie about it with grandiose marketing claims, which is what everyone else does.