How Email Encryption Actually Works

When people say “encrypted email,” they usually mean one of two things that are quite different in terms of what protection they provide. Understanding the distinction matters a lot when choosing tools and forming realistic expectations.

TLS: Encryption in Transit

Every modern email service uses TLS (Transport Layer Security) by default. TLS encrypts your email while it’s moving from your device to your email provider’s servers, and between servers when routing the message.

What TLS protects: anyone eavesdropping on the network connection — your ISP, someone on a public Wi-Fi network, a router you’re passing through — can’t read the content of your email.

What TLS doesn’t protect: the email service itself. Once the message arrives at Gmail’s servers, or Yahoo’s servers, or wherever, the provider can read it. Their software can read it to build ad profiles, train spam filters, or comply with a legal order. TLS is transport-layer encryption — it’s about protecting the pipe, not the contents from the destination.

This is the baseline for all reputable email services. It’s necessary but not sufficient for strong privacy.

End-to-End Encryption

End-to-end encryption (E2EE) goes further. With proper E2EE, the message is encrypted before it leaves your device, and can only be decrypted by the intended recipient. The email provider in the middle never has access to the plaintext — they see encrypted data that they can’t read.

The “ends” in end-to-end are your device and the recipient’s device. Everything in between — servers, network hops, the provider’s infrastructure — holds data it cannot read.

For email, this is typically implemented with PGP (Pretty Good Privacy) or a similar public-key encryption scheme.

How PGP Works

PGP is the dominant encryption standard for email, and it’s worth understanding the basic mechanism.

Key pairs: PGP uses asymmetric cryptography. You generate a key pair — a public key and a private key. They’re mathematically linked: data encrypted with the public key can only be decrypted with the corresponding private key.

Distribution: You publish your public key. Anyone who wants to send you an encrypted message downloads your public key and uses it to encrypt the message. You use your private key to decrypt it. You never share your private key.

Verification: PGP also handles signatures. When you send a message, you can sign it with your private key. Recipients who have your public key can verify the signature, confirming the message came from you and wasn’t tampered with.

The trust problem: The hard part of PGP is knowing whether a public key actually belongs to the person you think it does. This is the “web of trust” problem. If someone publishes a fake public key claiming to be your colleague, and you encrypt a message to that fake key, they can read it. ProtonMail and Tuta sidestep this partly by managing key distribution internally — their servers vouch for key ownership.

What Encrypted Email Providers Do

Services like ProtonMail and Tuta automate PGP (or a similar scheme) so users don’t have to manage keys manually. When you sign up, they generate a key pair for you. When you email another ProtonMail user, your client encrypts the message with their public key. The ProtonMail servers relay the encrypted blob but cannot read the content.

This is genuine end-to-end encryption with a usability wrapper. The trade-off: you’re trusting the provider to correctly implement the key management and not to silently substitute your keys. For most users, this trade-off is acceptable — it’s substantially better than giving Google or Microsoft access to all your email.

What’s Still Exposed

Even with proper E2EE, some metadata is always exposed:

Sender and recipient addresses: Email routing requires knowing where to deliver the message. The provider knows you sent email to a specific address at a specific time, even if they can’t read the content.

Subject line: Most PGP implementations — including ProtonMail’s — don’t encrypt the subject line by default. Tuta is an exception: they encrypt subjects too. This is a meaningful difference if the subject line reveals sensitive information.

Message timing and frequency: Metadata analysis can be revealing even without content. Knowing that you regularly email a lawyer, a therapist, or a political organization says something even without the content of those emails.

Your contact’s security: If you send an encrypted email from ProtonMail to a Gmail address, Gmail receives regular unencrypted email. Your side of the exchange is protected; the other side isn’t.

PGP for Advanced Users

If you want to go beyond what encrypted email providers automate, you can use PGP directly with a standard email client.

Tools like GPG (GNU Privacy Guard) let you manage your own key pair, encrypt messages manually, and use any email client. Thunderbird has built-in OpenPGP support. This approach gives you control over your keys and doesn’t require trusting a third party to manage them.

The downsides: significant setup friction, ongoing key management, and the requirement that your correspondents also use PGP. For most people, an automated service like ProtonMail is a better trade-off than manual PGP.

The Honest Bottom Line

Encrypted email with a provider like ProtonMail or Tuta protects message content from the provider and from most surveillance. What it doesn’t do: protect metadata, solve the problem of communicating with people who don’t use encrypted email, or protect against endpoint compromise (if your device is compromised, the attacker can read your decrypted email).

Knowing what’s protected — and what isn’t — lets you make realistic decisions about when encrypted email is sufficient and when you need additional tools.