In short. End-to-end encryption (E2EE) scrambles a message on the sender’s device and unscrambles it only on the recipient’s device. Everyone who carries or stores the message along the way, email servers included, sees only ciphertext where the content should be. Only the people in the conversation have the keys to read it.
Picture a locked box
You put a letter in a box and lock it. Only the recipient has the key. A courier carries the box across town, through depots, from hand to hand. None of them can open it.
The address, though, is written on the outside of the box. Otherwise the courier would not know where to take it. Email works the same way: you can hide what is inside, but not where it is going. We will come back to that.
How it works
End-to-end encryption almost always relies on a pair of keys.
- A public key can be shared with anyone. It is used to encrypt messages for its owner.
- A private key stays on the owner’s device. Only it can decrypt what the public key encrypted [10].
When you send an encrypted email, your app takes three steps:
- it creates a random one-time key and encrypts the text and attachments with it;
- it encrypts that one-time key with the recipient’s public key;
- it sends both together.
The recipient’s private key unlocks the one-time key, and the one-time key unlocks the message. This is how standards such as OpenPGP and S/MIME work [1, 2].
Messages often carry a digital signature as well. The sender signs with their private key, and anyone can check it with the matching public key. A valid signature shows that the key’s owner wrote the message and that nobody changed it on the way.
“Encrypted” does not always mean end-to-end
When an email service says “encrypted”, it can mean three different things. Each time, the question that matters is the same: who holds the keys?
| Type of encryption | What it protects | Who holds the keys | Who can read the email |
|---|---|---|---|
| In transit (TLS) | the path from your device to the server, and between servers | the servers on each hop | every server along the way |
| At rest | the provider’s disks, against theft and outsiders | the provider | the provider |
| End-to-end | the content (text and attachments), from device to device | only the sender and the recipients | only the sender and the recipients |
There is also a fourth option: zero-access storage. Stored mail is encrypted with the user’s keys, so the provider cannot read what it keeps. It still sees a message from another service at the moment it arrives.
The first two types in the table are useful, and you want them. But with only those two, the provider that stores your mail is technically able to read it. End-to-end encryption removes exactly that ability.
Why regular email is not end-to-end encrypted
Email is older than widespread encryption, and its design shows it.
- Servers pass mail to each other over SMTP [3]. Encryption between servers (STARTTLS) was added later, as an extension [4]. It is “opportunistic”: if the server on the other side does not support it, or an attacker on the network strips it out, the message may travel unencrypted [5]. MTA-STS lets a domain require encryption for delivery, but only if the recipient’s domain has set it up and the sending server supports it [6].
- Mail is stored on the server. Search, spam filtering and webmail at regular providers work on messages held on the server, and for that the server needs their content.
- Most recipients have no keys. End-to-end encryption only works when the recipient also has a key and an app that speaks the same standard.
That is why large providers usually encrypt mail in transit and at rest, but not end to end. Apple, for example, states plainly that iCloud Mail does not use end-to-end encryption because it has to interoperate with the global email system (per Apple, as of September 2026) [7].
How email gets end-to-end encrypted
There are two open standards.
- OpenPGP [1]. Users create and keep their own keys. A public key can be published or sent to a contact. The latest version of the standard came out in 2024.
- S/MIME [2]. Keys are tied to certificates, usually issued by a certificate authority. It is more common inside companies.
An email encrypted with OpenPGP or S/MIME can be sent from any email service. Only a recipient with the right key and app can read it, though.
Some email services build end-to-end encryption into their own apps, so mail between their users is encrypted automatically. For recipients on other services they usually offer separate options. How to check that a service really does what it says is covered at the end of this article.
What an encrypted email still reveals
End-to-end encryption hides the content. But email cannot deliver a message without knowing where it comes from and where it goes. Even the NIST glossary definition notes that with end-to-end encryption the data is protected while routing information remains visible [8].
Usually visible:
- the sender and recipient addresses, because delivery needs them;
- when the message was sent, and its size;
- the servers it passed through, recorded in its technical headers;
- the subject line. Classic OpenPGP and S/MIME do not encrypt it. A standard for protecting headers was published in 2025 [9], but not every app supports it yet.
This is called metadata: who, to whom, when. Sometimes it says as much about a person as the message itself.
What end-to-end encryption does not protect against
End-to-end encryption solves one problem: nobody reads the message on its way or on the servers. It does not solve the rest.
- Malware on a device. If a device is compromised, malware sees the message after it is decrypted.
- The recipient. A message can be forwarded, printed or photographed on screen.
- A lost key. If the private key is lost and there is no backup, old messages cannot be decrypted. By anyone.
- Webmail. Email in a browser loads its code from the server every time you sign in. Unless the service offers a way to verify that code, you have to trust it has not been swapped.
- Metadata. It stays visible, as described above.
How to check that a service really uses end-to-end encryption
If a service talks about encryption, ask it five questions.
- Where are the keys created and stored? If the provider holds your private key in readable form, or encrypted with a key the provider also has, it is not end-to-end encryption.
- What exactly is encrypted? Only the text and attachments, or also subjects, contacts and drafts?
- Is the app code open, and is there a published independent audit? Without them, you are taking the provider’s word for it. More in Open-source email: what you can check, and what you can’t.
- Can you verify a contact’s key? For example, by comparing key fingerprints in person or over another channel, or through a public, verifiable log of keys, known as key transparency.
- What happens to mail from other services? It arrives as regular email, so the service sees it as it comes in.
Glossary
- End-to-end encryption (E2EE): encryption from the sender’s device to the recipient’s device; only the people in the conversation have the keys.
- TLS: encryption of the connection between two points, such as your device and a server.
- Public and private key: a key pair; the public key encrypts, the private key decrypts.
- OpenPGP and S/MIME: open standards for end-to-end encrypted email.
- Metadata: information about a message rather than its content: who, to whom, when, how large.
Sources
- RFC 9580: OpenPGP. IETF, July 2024. https://www.rfc-editor.org/rfc/rfc9580
- RFC 8551: S/MIME Version 4.0 Message Specification. IETF, April 2019. https://www.rfc-editor.org/rfc/rfc8551
- RFC 5321: Simple Mail Transfer Protocol. IETF, October 2008. https://www.rfc-editor.org/rfc/rfc5321
- RFC 3207: SMTP Service Extension for Secure SMTP over Transport Layer Security. IETF, February 2002. https://www.rfc-editor.org/rfc/rfc3207
- RFC 7435: Opportunistic Security: Some Protection Most of the Time. IETF, December 2014. https://www.rfc-editor.org/rfc/rfc7435
- RFC 8461: SMTP MTA Strict Transport Security (MTA-STS). IETF, September 2018. https://www.rfc-editor.org/rfc/rfc8461
- Apple: iCloud data security overview. https://support.apple.com/en-us/102651
- NIST SP 800-12 Rev. 1, CSRC glossary: end-to-end encryption. https://csrc.nist.gov/glossary/term/end_to_end_encryption
- RFC 9788: Header Protection for Cryptographically Protected Email. IETF, August 2025. https://www.rfc-editor.org/rfc/rfc9788
- EFF, Surveillance Self-Defense: A Deep Dive on End-to-End Encryption. https://ssd.eff.org/module/deep-dive-end-end-encryption-how-do-public-key-encryption-systems-work