Is Proton Mail private? Email encryption boundaries explained
A threat-model checklist for Proton Mail and ordinary email, separating TLS, mailbox encryption and end-to-end encryption.
A blunt archived warning about Proton Mail compressed several different kinds of encryption into one claim. The more useful question is: who should be unable to read which part of your message? Email protection depends on the recipient, the way you send and the provider that receives it.

Protects a connection in transit; receiving mail systems may still read the content.
Protects stored copies according to a provider's key design; it does not control another provider.
Only the intended endpoints hold the keys needed to read message content.
Check the recipient path
Proton states that mail between Proton users is end-to-end encrypted. It also supports OpenPGP with outside recipients who have a compatible public key, and password-protected messages for recipients outside Proton. A normal message to an ordinary external mailbox does not magically become end-to-end encrypted just because the sender used Proton. The receiving service's security and retention practices matter.
That does not mean an ordinary external email is necessarily sent in cleartext across the internet. Transport TLS and end-to-end encryption are different protections. Inspect the actual sending mode before describing a message as private.
Look beyond message content
Email addresses, timing, subject lines and routing information can still expose sensitive context depending on the system and mode. A password-protected link also creates a password-sharing problem: send the secret through a separate channel. For a high-risk conversation, decide whether email is the right medium at all.
Use a four-question threat model
- Who is the recipient and what mail system do they use?
- Is the message protected only in transit, stored encrypted, or end-to-end encrypted?
- Which metadata do the sender and receiving providers see?
- What happens if an account or device is compromised, and how are keys recovered?
Open-source client code and third-party audits can improve transparency, but they do not alone prove every server-side operation or every claim about a live service. Read the provider's current technical documentation and make a decision against your own threat model.
For routine mail, choose a trustworthy provider, strong authentication and current software. For a sensitive exchange, confirm end-to-end protection with the recipient before sending the material.
Sources & scope
These sources support the technical principles above. Commands and compatibility can change; verify the current version before changing a machine.
This is a new, independent edition. Its articles are original editorial work inspired by the domain's technical history; we are not the former author. Meet the earlier author in the archive.