How Email Encryption Actually Works (And Why Most of It Isn't Enough)
You've probably seen the little lock icon in your browser and assumed your emails are safe. They're encrypted, right? Technically yes. But that word covers a lot of ground. And most of the time, it covers a lot less than you think.
Here's how email encryption actually works. No jargon soup. No vendor pitches. Just the facts.
Layer 1: TLS (The Bare Minimum)
TLS stands for Transport Layer Security. It encrypts your email while it's moving between servers. Think of it like an armored truck transporting cash.
The problem? Once the truck arrives, the cash gets unloaded and sits in an unlocked vault. TLS protects the journey, not the destination. Your email sits in plaintext on the server. Anyone with access to that server can read it. That includes the provider, any employee with the right permissions, and anyone who breaches their systems.
Almost every major email provider uses TLS. It's better than nothing. But it's the bare minimum, and calling it "encrypted email" is like calling a screen door a security system.
Layer 2: End-to-End Encryption (Better, But Look Closer)
End-to-end encryption (E2EE) is a real upgrade. Your email gets encrypted on your device and only decrypted on the recipient's device. The server in between just moves ciphertext around. It never sees the actual message.
This is what most people picture when they hear "encrypted email." And when done right, it's solid.
But here's where it gets interesting. Not all E2EE is built the same.
Some implementations encrypt your private keys with your password and store them on the server. The keys are encrypted, sure. But they're sitting on someone else's infrastructure. The decryption happens inside a web app that the provider controls and updates. A bad update could extract your key. A compromised server could do the same.
The keys existing on the server at all is the weak point. Even encrypted, they create a trust dependency. You're trusting that the provider won't mess up. Or be compelled to mess up.
Layer 3: Zero-Knowledge Encryption (The Real Deal)
Zero-knowledge takes the concept further and closes the gaps.
Your private keys are generated on your device. They stay on your device. The server never sees them. Not encrypted, not hashed, not in any form. The provider is mathematically locked out of your data.
If someone serves the provider with a court order, all they can hand over is ciphertext. No keys to decrypt it. No mechanism to access it. Not because of a policy. Because of architecture.
This is the difference between "we choose not to read your emails" and "we literally cannot read your emails." One is a promise. The other is math.
So What About the Algorithms?
The encryption is only as strong as the math behind it. Most email encryption today uses RSA or elliptic curve cryptography (ECC). Both work great right now. But both are vulnerable to quantum computers.
A sufficiently powerful quantum computer could break RSA-2048 in hours using Shor's algorithm. ECC falls even faster. This isn't theoretical fear. NIST finalized post-quantum cryptography standards in 2024 because the threat is real enough to act on.
Post-quantum algorithms like ML-KEM and ML-DSA use different mathematical foundations. Lattice-based problems that stay hard even against quantum hardware. If you care about emails staying private five or ten years from now, the algorithm matters just as much as the architecture.
The Metadata Problem
Even perfect encryption has a blind spot. Metadata.
Traditional email exposes who you're talking to, when, how often, and from where. Subject lines are often unencrypted. Headers are always visible to servers along the route.
Metadata doesn't reveal what you said, but it reveals patterns. And patterns are often enough. Who your lawyer is. When you talk to your doctor. How often you email a journalist. That information has value, and standard email encryption does nothing to protect it.
Any serious encrypted email service should be working to minimize metadata exposure, not just encrypting the body and calling it a day.
What to Actually Look For
If you're evaluating how well your email is protected, here's what matters:
Where do your keys live? If they're on the server in any form, that's a trust dependency you might not want.
Is encryption on by default? If you have to toggle it or install something, most of your emails will go out unencrypted.
What algorithms are being used? RSA and ECC work today but have an expiration date. Post-quantum algorithms are the ones built to last.
Who controls the code? Web apps serve fresh code on every load. A compromised update can steal your keys silently. Native apps are harder to tamper with.
What about metadata? Encrypting message bodies but leaving subject lines, timestamps, and sender info exposed is only half the job.
The Bottom Line
Email encryption isn't one thing. It's a spectrum. TLS is the floor. End-to-end encryption is a real step up. Zero-knowledge with post-quantum algorithms is where you actually want to be.
Most people don't need to understand the math. But everyone should understand the tradeoffs. Because "encrypted" on its own doesn't mean your emails are private. It just means someone, somewhere, added a lock. The question is who holds the key.
Secria uses zero-knowledge architecture with post-quantum encryption. Your keys never leave your device. Try it for free.