Table of Contents
- The three things "encrypted email" can mean
- Transport encryption: necessary, not sufficient
- End-to-end: PGP vs S/MIME
- Provider zero-access encryption
- The metadata problem everyone skips
- Where the major providers actually sit
- A decision framework
The three things "encrypted email" can mean
"Encrypted email" is one of the most abused phrases in the privacy market. Almost every provider can claim it and be telling the truth — yet each can mean a different thing. There are three layers of encryption in email. Each one guards against a different threat:
- Transport encryption (TLS / STARTTLS) — the link between two mail servers is encrypted. This stops a passive listener on the wire. It is now near-universal. It is the bare minimum, not a feature.
- End-to-end encryption (PGP or S/MIME) — the message body is locked on the sender's device with the recipient's public key. Only the recipient's private key can open it. No server in the path can read it.
- Provider zero-access encryption — the provider stores your mailbox locked with keys made from your password. Even the provider cannot read the mail in your account.
When a mainstream provider says "your email is encrypted," they almost always mean layer 1. A privacy-focused engineer who asks for encrypted email almost always means layer 2 or 3. That gap is the whole subject of this guide.
Transport encryption: necessary, not sufficient
TLS — set up over SMTP with STARTTLS — locks the hop between two mail servers. It is useful. It stops someone tapping the network from reading your mail in flight, and modern mail systems use it almost everywhere.
But TLS is hop-by-hop, not end-to-end. A message often crosses several servers between sender and recipient. At each hop it is unlocked, handled, then locked again for the next leg. So every server in the chain — your provider, the recipient's provider, and any relay between them — sees the message in plain text. Transport encryption guards the message from outsiders on the wire. It does nothing to guard it from the providers themselves.
There is a second catch. STARTTLS is opportunistic by default. If the receiving server does not offer TLS, many senders quietly fall back to plain-text delivery rather than fail. So "we use TLS" does not even prove that a given message was locked the whole way. This is why transport encryption is the floor, not the ceiling.
End-to-end: PGP vs S/MIME
End-to-end encryption (E2EE) moves the locking to the two ends. The sender locks the message with the recipient's public key. Only the recipient's private key can open it. The servers between them never hold the private key, so none of them can read the body — not your provider, not a relay, not the recipient's provider. It is the same public-key model behind the CLI password managers and key handling we cover for engineers. What differs is who hands out the keys.
Two standards lead the field. The split between them is all about trust and how keys are shared:
PGP (OpenPGP). A "web of trust" with no central body. Users make their own key pairs and trade public keys directly. They check each key by hand — a fingerprint read over a call, or a key signed by a shared contact. It is very flexible and needs no authority, but sharing keys is manual. That is why PGP has a name for friction. It is the standard among private users, reporters, and open-source groups.
S/MIME. Public keys are tied to people by certificates from a central certificate authority (CA). This makes rollout across a managed company much simpler — the IT team hands out certificates from one place. But it ties your trust to that CA. S/MIME is the usual pick in firms and government, where a managed key system already runs.
Both give the same core promise: a message no server in the middle can read, plus a digital signature that proves the sender and that nothing was changed. The cost, both times, is that the recipient has to take part too. You cannot just send an E2EE message to someone with no key.
Provider zero-access encryption
There is a third model that sidesteps the key-distribution pain for the common case of a private mailbox: zero-access encryption at the provider.
Here the provider encrypts your stored mailbox with keys derived from your password, on your device, so the server only ever stores ciphertext for your account. Even the provider cannot read mail at rest. Proton Mail is the best-known implementation: messages between Proton users are end-to-end encrypted by default, and the whole mailbox is held under zero-access encryption so Proton itself cannot read it.
The honest limit is the nature of email. When a Proton user emails a Gmail user, the message cannot be end-to-end encrypted unless the Gmail user also has PGP, because the other end has no key. Proton handles this by letting you send a password-protected message to a non-user: the recipient opens it via a link and a password you share separately. That is a genuine bridge, but it requires sharing the password through another channel — the same fundamental constraint as PGP, packaged more conveniently.
Zero-access encryption is attractive because it gives you a readable, searchable-on-device, no-setup mailbox that the provider still cannot read — without forcing every correspondent to manage keys.
The metadata problem everyone skips
This is the most important and most ignored point in any honest discussion of encrypted email: encryption protects the contents, not the metadata.
Even with flawless end-to-end encryption, the following typically still travels in the clear and can be logged by your provider, the recipient's provider, and the network:
- who sent the message and who received it,
- the timestamp,
- the message size,
- and, in many implementations, the subject line.
So encryption answers "what did the message say," but not "who is talking to whom, when, and how often." For a threat model where concealing your contacts matters — not just your words — content encryption alone is insufficient. Providers that minimize metadata retention, and network-layer tools, address a different part of the problem. Treat the metadata limit as a design fact of email, not a flaw of any one provider, and plan around it.
Where the major providers actually sit
| Provider | In transit | At rest | End-to-end by default | Provider can read your mail |
|---|---|---|---|---|
| Gmail (consumer) | TLS | Yes (Google holds keys) | No | Yes |
| Outlook / Microsoft 365 (consumer) | TLS | Yes (Microsoft holds keys) | No | Yes |
| Gmail Workspace + CSE / S/MIME | TLS | Yes | Only if configured | Reduced with CSE |
| Proton Mail | TLS | Zero-access (you hold keys) | Yes, between Proton users | No |
The pattern is consistent: the mainstream consumer services encrypt in transit and at rest but hold the keys, so they can — and for features and legal requests, do — read content. Achieving end-to-end on Gmail or Outlook is possible but requires deliberate configuration (S/MIME, or client-side encryption on specific paid tiers). Proton Mail is built E2EE-and-zero-access by default, which is why it is the provider most often cited when "encrypted email" means layer 2 or 3 rather than layer 1.
A note on verification, in the spirit of data sovereignty: an encryption claim you cannot inspect is an assertion, not a guarantee. Open-source clients — Proton publishes theirs — let independent reviewers confirm that keys are generated on your device and that plaintext never reaches the server. Prefer providers whose claims are auditable over those that simply assert them.
A decision framework
Stop asking "which email is the most encrypted" and start asking "who must not be able to read this, and is the recipient willing to participate?"
Transport encryption is enough when the content is routine and your only concern is a network eavesdropper. Every serious provider already gives you this; there is nothing to set up.
Use end-to-end (PGP or S/MIME) when specific messages must be unreadable to every server in the path and the recipient can hold a key — a colleague, a journalist's source, an organization with managed S/MIME. Accept the key-exchange step as the price of the guarantee.
Use a zero-access provider like Proton Mail when you want your whole mailbox unreadable to the provider without forcing every correspondent to run PGP, with a password-protected fallback for the occasional encrypted message to an outsider.
Whatever you choose, remember two things. First, metadata is not encrypted — encryption hides the words, not the relationship. Second, verify the claim: prefer open-source clients and a privacy-respecting jurisdiction so "we can't read your mail" is something you can check rather than something you have to trust.
For the storage side of the same privacy stack, see our guide to encrypted cloud storage for developers, and for the broader question of keeping data out of US-jurisdiction services, the pillar on data sovereignty.
