Encrypted email keeps the words inside your message private. It does not keep private who you emailed, when, how often, from which device, or — in most setups — even the subject line. That gap between "encrypted" and "untraceable" is where most of the real privacy risk in email actually lives.
This matters most for anyone who has assumed that switching to an end-to-end encrypted provider closes the loop on privacy. It narrows the loop; it doesn't close it. The message body becomes unreadable to outsiders, but routing information, timestamps, and account activity are still generated by the simple act of sending mail, and that information can be logged, requested, or compelled independently of the encrypted content itself.
Key takeaways
- End-to-end email encryption (OpenPGP/PGP, S/MIME, or a provider's built-in scheme) protects the message body and attachments — not the envelope carrying them.
- Sender and recipient addresses, timestamps, message size, and IP-based routing headers travel largely in the clear, because mail servers need to read them to deliver the message.
- Subject lines are unencrypted by default in standard PGP/MIME; only some clients support "protected headers" to close that gap.
- A widely reported 2021 case showed an encrypted mail provider handing over a login IP address under a valid legal order, while message content stayed unreadable.
- Cutting metadata exposure usually means pairing an encrypted provider with other habits — not treating encryption alone as the finish line.
How end-to-end email encryption actually works
With OpenPGP (PGP/GPG), the sender encrypts the message body with the recipient's public key. Only the matching private key can decrypt it, and in principle nobody in between — not the mail servers, not an attacker on the network — can read the contents.
S/MIME works on a similar principle but relies on certificate-based trust, which is why it shows up more in corporate mail systems than personal ones.
Providers built around "zero-access" encryption, such as Proton Mail, encrypt stored messages with keys derived from the account password, so the provider itself can't read message content at rest. In all three models, what's protected is the ciphertext blob. The envelope that carries it to its destination is a separate layer, governed by a much older protocol.
What still travels in the clear
Standard internet email (SMTP) was not designed with privacy in mind, and encrypting the payload doesn't rewrite that history. A few things stay visible regardless of how strong the message encryption is:
- To/From addresses — mail servers must read these to route the message.
- Subject lines — unencrypted by default in PGP/MIME; a "protected headers" (memory hole) extension exists but isn't universally supported.
- Timestamps — when a message was sent and received.
- Message size and attachment count — enough on its own to distinguish a one-line reply from a document transfer.
- Received headers — each mail hop appends its own header, often including the IP address of the relaying server.
There's also a transport-layer catch. Connections between mail servers typically use STARTTLS, which is opportunistic: if a receiving server doesn't support TLS, the message can still go out over an unencrypted hop unless the sending domain enforces stricter policies. That means metadata-carrying headers can, in some configurations, cross the internet in the clear even when the payload inside is unreadable ciphertext.
Encryption method vs. what it actually covers
| Method | Message body | Subject line | To/From addresses | IP & timing metadata |
|---|---|---|---|---|
| Standard, unencrypted email | Readable | Readable | Readable | Logged |
| OpenPGP/PGP (standard PGP/MIME) | Encrypted | Usually not encrypted | Not encrypted | Not encrypted |
| OpenPGP with protected headers (client-dependent) | Encrypted | Encrypted | Not encrypted | Not encrypted |
| S/MIME (certificate-based) | Encrypted | Not encrypted | Not encrypted | Not encrypted |
| Zero-access provider, same-service mail | Encrypted at rest & in transit | Encrypted | Not encrypted | Still logged per provider policy |
The pattern across every row is the same: the payload gets stronger protection with each step, but the envelope fields needed for delivery and account operation stay legible.
Why the exposed pieces matter more than they look
Metadata alone can reconstruct a lot. Who you email, how often, at what hours, and in what volume can sketch out relationships and routines without a single word of content ever being read. This is why traffic analysis is treated as a serious discipline in surveillance and security research, not an afterthought.
The legal angle sharpens this further. A provider can only refuse to hand over what it genuinely cannot access. In the widely reported 2021 case involving an encrypted mail service, message content stayed encrypted and unreadable, but account metadata — including a login IP address — was disclosed after a legally binding order from the provider's home jurisdiction. That outcome wasn't a flaw in the encryption; it was a demonstration that metadata retention and message encryption are two separate questions with two separate answers.
What actually reduces metadata exposure
Encryption alone won't close this gap, but a few adjustments narrow it:
- Use protected-headers-capable clients if the subject line itself is sensitive, rather than assuming PGP handles it by default.
- Layer a VPN to reduce the IP-based metadata a provider logs or could be compelled to hand over — see how Mullvad and Proton VPN stack up in our Mullvad vs. Proton VPN comparison.
- Move time-sensitive or highly sensitive conversations off email to a messaging app designed around metadata minimization from the start, such as Signal; our Signal vs. Telegram comparison breaks down how its metadata practices differ from those of Telegram.
- Compare encrypted mail providers side by side before committing to one, since retention policies vary — our Proton Mail alternatives guide is a reasonable starting point.
- Keep the account itself hard to compromise. Metadata exposure gets worse fast if an attacker gains account access outright, so basic account hygiene still matters here.
None of these steps make email metadata disappear. Email as a protocol needs some of it to function. The goal is reducing what's collected and who can compel its release, not eliminating it entirely.
Choosing based on your actual threat model
If your concern is a nosy network operator or having message content readable after a data breach, reputable encrypted email already addresses that directly.
If your concern is that the existence, timing, or frequency of a specific conversation must stay hidden from a well-resourced adversary or legal process, email metadata is a structural weak point no matter which provider you pick. That calls for a different tool, or a layered setup — encrypted mail plus a VPN, or a metadata-conscious messenger for the parts of the conversation that can't move to a mailbox at all.
We describe apps by what's independently verifiable rather than by marketing claims; see our methodology for how that works, or browse the full app directory to compare options against your own threat model.
Encrypted email is a meaningful upgrade over plaintext — it just isn't the same thing as untraceable email. Match the tool to what you're actually trying to protect: the message content, the fact that a conversation happened, or both. Features and pricing change — always check the official site before deciding.
Frequently asked questions
Does encrypting an email hide who I'm emailing?
No. Sender and recipient addresses generally stay visible, because mail servers must read them to route the message. Even providers offering full zero-access encryption for content typically retain some metadata trail of account activity.
Can a legal request expose metadata even when the message body stays encrypted?
Yes. A provider can only withhold what it can't access. If it retains logs of IP addresses, login times, or header data, a valid legal order in that provider's jurisdiction can compel disclosure of that portion, while properly implemented end-to-end encrypted content remains unreadable.
Is a messaging app more metadata-safe than encrypted email?
Often, though it depends on the specific app and its retention policy. Apps built around minimizing metadata from the ground up tend to log less about who's talking to whom, and for how long, than encryption bolted onto a decades-old mail protocol.
Does encrypted email protect the subject line?
Not by default. In standard PGP/MIME the subject line travels unencrypted, and only clients that support the "protected headers" extension close that gap. If the subject itself is sensitive, choose a client that supports protected headers rather than assuming PGP covers it.