Encrypted Email: What End-to-End Encryption Actually Protects, and What It Never Did
Disclosure: Some links on this page are affiliate links. If you purchase through them, we may earn a commission at no extra cost to you. Full affiliate disclosure.

Someone moves their mail to an encrypted provider, feels the specific relief of having done something concrete about privacy, and then discovers that every subject line they have written for the last six months is still sitting in a readable header. The body was never the only thing they were leaking. It was just the only thing they had thought about.
This is not an argument against encrypted email. It is an argument for knowing what you bought. Providers like Proton Mail, Tuta, StartMail and Mailfence all solve a real problem, and the marketing around them tends to blur the boundary between "our servers cannot read your messages" and "your email is private" — which are two very different claims.
Editor’s take: Three things this guide doesn't cover but you should know: (1) document your actual workflow before buying; (2) ask the vendor for a 30-day pilot, not a 14-day trial; (3) set a hard review date — six months is the magic window. Tackle those after you finish the steps above.
Editor's Take
The uncomfortable point in this piece is the right one: end-to-end encryption protects message content, not the metadata around it, and who you emailed and when is often the sensitive part. It also only works end to end — send mail to a Gmail address and the guarantee stops at the provider boundary. Encrypted email is a real improvement, just a narrower one than the name suggests.
Draw the line: what is encrypted, what is not
End-to-end encryption in email applies to the message body and its attachments. That is the payload, and it is genuinely protected. The rest of the envelope is not.
The subject line is normally outside the encrypted part. So are the sender address, the recipient address, the timestamps, the message size, the fact that an attachment exists, and the folder structure of your mailbox. None of that is a bug or a shortcut — it is how mail routing works. Every mail server between you and the recipient has to know where the message is going, and it cannot do that by reading an encrypted blob.
Practical consequence: if you would be uncomfortable with a stranger reading "re: the settlement offer — attached" in a list of your subject lines, put that detail in the body and make the subject something deliberately boring. This single habit closes the largest gap most people have.
Metadata is the part people underestimate
Content is what you said. Metadata is the shape of your life: who you write to, how often, at what hours, in what order, with whom you stopped corresponding in March.
For a great many threats, the shape is enough. An employer looking for a leak does not need to read the message; knowing which journalist you emailed four times in a week answers the question. An abusive ex does not need the text; knowing that you started receiving mail from a new address at a domestic violence service tells them plenty. A subpoena for records produces a communication graph whether or not the bodies are decryptable.
Encrypted email does not solve this, because no email system can. The transport has to carry routing information in the clear. If metadata is what you actually need to protect, the answer is a different communication channel, not a different mail provider — and you should be sceptical of any provider implying otherwise.
The other half of the conversation
Encryption only works when both ends hold a key. Most of your correspondents use Gmail or Outlook, and those providers have no key for your message, so the end-to-end guarantee simply does not apply to that thread.
Encrypted providers handle this in one of three ways, and which one a given service defaults to matters more than any feature list:
- Secure portal delivery. The recipient gets an email saying "you have a secure message," authenticates to a web page, and reads it there. This genuinely protects the content, and it asks the recipient to do something unfamiliar. For a lawyer or a clinician this is fine. For your mother, it is friction she will abandon.
- Fallback to plain email. Some configurations let you send the message unencrypted after warning you. Convenient, and it means the content is now sitting in the recipient's mailbox in the clear, forever, outside your control.
- Pre-arranged key exchange. PGP or S/MIME with keys exchanged in advance. Real end-to-end encryption that crosses providers, with the usability profile of a 1990s application.
The honest summary: encrypted email works best inside a group that all agreed to use it. It degrades the moment it touches the outside world, and the provider's default behaviour at that boundary is the single most important setting to look at.
Who holds the keys
There are two models and the trade is unavoidable.
Provider-managed keys. This is what hosted encrypted mail services do. Your keys are derived from your password and the provider handles the infrastructure, including decryption in the browser or app. You cannot lose your key, and mail works on every device with no setup. The dependency is that the provider delivers the code that decrypts your mail every time you log in, which means a provider that is compromised, coerced, or malicious has a theoretical path to one user's mail. Serious providers mitigate this with open-source clients and independent audits, and it remains a trust relationship rather than a purely mathematical guarantee.
User-held keys. PGP and similar schemes put the private key on your device and nowhere else. No provider can read your mail or be compelled to produce it. You also cannot read your own archive from a new laptop without moving that key, and losing it means losing years of mail permanently. For most people this trade is bad. For a small number of people it is the entire point.
The question to ask is not "which is more secure" but "who do I need to be unable to read this, and what happens if I lose access?" Our encryption tools comparison works through that decision for files and messages more broadly.
Account recovery is where it breaks
Here is the part that undoes everything above. The strongest mailbox encryption in the world is irrelevant if an attacker can reset your password with a recovery phone number and read your mail as you.
The attack path of choice is not breaking the cryptography. It is a SIM swap, a reused recovery email, or a support conversation with someone who sounds enough like you. Which means the security of an encrypted mailbox is mostly determined by the security of the account around it: a unique password in a real password manager, the strongest second factor your provider supports with app-based or hardware keys ahead of SMS, and a recovery path that is not itself the weak link.
Set that up before you migrate anything. It is worth more than the provider choice.
What migration actually costs you
- Your archive does not get encrypted retroactively. Mail that landed at your old provider was stored however that provider stored it. Importing it into an encrypted mailbox changes where it lives, not how readable it is. Export what you want and delete the originals, or accept that the old account remains what it was.
- Changing the address is the hard part. The address is the identifier on your bank, your tax account, your employer, your 2FA resets and every password reset you will ever do. Providers let you use a custom domain to soften this, which is worth doing up front because adding a domain later is far more awkward than starting with one.
- Search gets worse. Server-side search requires the server to read your mail, which is exactly what you turned off. Search happens on device after decryption, which is slower and usually cannot reach attachments the way you are used to.
- Third-party clients stop working normally. Standard IMAP and SMTP cannot carry end-to-end encrypted mail. Using a desktop client typically requires a provider-supplied bridge application running locally, which is another thing to install, update and troubleshoot.
- Everyone else has to deal with it. Some correspondents will hit the portal and give up. Some will reply in a way that breaks the thread.
None of that is a reason not to switch. It is a reason to switch once, deliberately, with a custom domain and a recovery flow you have tested — rather than twice.
Who this is for, honestly
Encrypted email is a good decision if you handle other people's confidential information as part of your job, if you are a journalist or activist whose contact list is itself sensitive, if you are leaving a situation where someone has access to your accounts, or if you simply object on principle to your correspondence being scanned to sell you things. That last one is not a small reason — it is the default state of free webmail, and opting out of it is legitimate on its own.
It is the wrong tool if what you actually want is anonymity, protection from a government with legal reach over your provider, or a way to send one sensitive file. For the second, look at what a provider can be compelled to do and read their transparency reporting. For the third, an encrypted file transfer solves it in a minute without moving your entire digital life.
If your real worry is that your credentials are already circulating, start with what to do after a data breach and our password security guide. Encryption on a mailbox whose password is already in a breach dump changes nothing.
For provider-level detail, see our encrypted email provider comparison, and read our phishing identification guide before you trust any message claiming to be from whichever provider you pick.
Test the Recovery Path Before You Move Anything
The most common way an encrypted mailbox is compromised is not broken encryption. It is a password reset through a recovery phone number or an old recovery address. Lock down the second factor and test the reset flow while you still have access.
Remove Your Data From Broker Sites
Deleting an account does not remove what brokers already collected. PrivacyHawk files opt-outs on your behalf and keeps monitoring for re-listing.
Get PrivacyHawk Read our PrivacyHawk review