In short. “Encrypted email” can mean four different things. Encryption in transit (TLS) protects a message on its way; encryption at rest protects the provider’s disks; zero-access encryption keeps stored mail unreadable to the provider; end-to-end encryption leaves a message readable only to its sender and recipients. The difference comes down to one question: who holds the keys.
Four kinds of email encryption
| Who holds the key | Protects against | Who can still read your mail | |
|---|---|---|---|
| In transit (TLS) | the servers at the two ends of each connection | someone listening on the network, for example on public Wi-Fi | every mail server on the way, your provider included |
| At rest | your provider | someone who steals a disk | your provider, and anyone who can make it hand mail over |
| Zero-access | you | your provider reading stored mail | your provider, when mail from another service arrives or leaves for another service without end-to-end encryption |
| End-to-end | the sender and the recipients | everyone on the way, providers included | the sender and the recipients |
In transit: TLS
- Between your app and your provider. Webmail works over HTTPS, and mail apps connect over IMAP, POP and SMTP with TLS. The IETF has recommended TLS for these connections since 2018 [1].
- Between mail servers. Servers encrypt connections to each other with STARTTLS [2]. It is opportunistic: if the other server does not offer TLS, or an attacker on the path strips the offer, mail can travel unencrypted. MTA-STS [3] and DANE [4] let a domain require TLS for the mail it receives.
- On each server the message is decrypted. TLS protects the road, not the stops: the servers themselves see the message [5].
At rest
The provider encrypts its disks or database with its own keys. That protects against a stolen disk or backup. But the provider can decrypt everything, and so can anyone who makes it hand mail over.
Zero-access
Stored mail is encrypted with a key the provider does not have, so the provider cannot read what it stores. Mail from other services still arrives unencrypted and is encrypted on arrival, and at that moment the provider sees it. The same happens when you send to another service without end-to-end encryption: the message leaves unencrypted. More in What is zero-access encryption?
End-to-end
A message is encrypted on the sender’s device and decrypted only on the recipients’ devices [5]. Within one service this can happen automatically; between different services it takes OpenPGP or S/MIME. In a web app the code comes from the server at every sign-in, so here too you have to trust the provider; in apps, less so. More in What is end-to-end encryption? and How to send an encrypted email.
What stays visible in every case
- Addresses and time. Mail cannot be delivered without them. More in Email metadata.
- Often the subject. Classic OpenPGP and S/MIME do not encrypt it. A standard for protecting headers was published in 2025 [6], but not every app supports it yet.
How to tell what a provider means by “encrypted”
Ask four questions:
- Encrypted where: in transit, at rest, with zero access or end-to-end?
- Who holds the keys: the provider or you?
- What happens to mail from other services when it arrives?
- Which parts are encrypted: the text only, or also the subject, the senders and the recipients?
A longer checklist is in How to check an email provider’s security yourself.
Encryption and Methmail
Emails between Methmail users will be end-to-end encrypted: only the sender and the recipients will be able to read them. Stored emails will be encrypted with keys we don’t have. At the moment it arrives, a message from another provider will pass through our server unencrypted: that is how regular email works. Mail to another provider without PGP will wait in the send queue until delivery (up to 48 hours), on a volume encrypted with our key. The limits of this protection are under What Methmail won’t be able to do.
Sources
- RFC 8314: Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access. IETF, January 2018. https://www.rfc-editor.org/rfc/rfc8314
- RFC 3207: SMTP Service Extension for Secure SMTP over Transport Layer Security. IETF, February 2002. https://www.rfc-editor.org/rfc/rfc3207
- RFC 8461: SMTP MTA Strict Transport Security (MTA-STS). IETF, September 2018. https://www.rfc-editor.org/rfc/rfc8461
- RFC 7672: SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS). IETF, October 2015. https://www.rfc-editor.org/rfc/rfc7672
- EFF, Surveillance Self-Defense: What Should I Know About Encryption? (last reviewed by EFF in January 2025). https://ssd.eff.org/module/what-should-i-know-about-encryption
- RFC 9788: Header Protection for Cryptographically Protected Email. IETF, August 2025. https://www.rfc-editor.org/rfc/rfc9788