What Email Metadata Leaks (Even With End-to-End Encryption)

End-to-end encryption stops your provider from reading your messages. It does not stop your provider — or anyone with court-order access to your provider — from learning a substantial amount about you.

The phrase for this is “metadata,” and the gap between what people think it covers and what it actually leaks is the source of most encrypted-email mistakes.

The Envelope vs the Letter

Email has always had two layers. The body is the letter. The headers are the envelope. End-to-end encryption protects the letter. The envelope still has to be readable by every server that handles delivery.

Here is what is on every encrypted email’s envelope, in plaintext, regardless of provider:

• From address — the encrypted email account you sent from
• To address — the recipient’s address
• Cc and Bcc recipients — yes, even Bcc; the addresses are visible to your sending server
• Date and time — when the message was sent, accurate to the second
• Subject line — visible on Proton Mail (encrypted on Tutanota, alone among the major providers)
• Message size — exact byte count
• Routing path — Received headers showing every server that handled the message
• Reply-To, In-Reply-To, References — threading information that links messages into conversations

Anyone who can see your provider’s logs sees all of this. That includes your provider’s staff (governed by their internal access controls and audit logs), governments through lawful court orders, and any attacker who compromises your provider’s systems.

What That Actually Leaks

Metadata alone tells a lot:

Who you talk to. A list of every address you’ve sent mail to or received mail from is a social graph. If someone has metadata for both you and another person, they can verify communication between you without reading anything.

When you talk to them. Patterns of communication — daily, weekly, only at night, only on weekends — reveal habits, time zones, and life events.

The shape of your conversations. Reply chains, message sizes, attachment frequency. A long thread of small messages to one address looks different from a single large message with an attachment.

Subject lines (on most providers). “Wire transfer instructions,” “Settlement draft,” “Source for Tuesday’s piece” — subject lines often telegraph the content even when the body is encrypted.

Inferences from association. A message to a known journalist’s address, a message to an attorney’s address, a message to a competitor’s address — the recipient identity itself can be the sensitive fact.

For most everyday correspondence, this metadata leakage doesn’t matter. For source protection, legal work, dissident communication, or anything where the fact of a conversation is sensitive, it matters a great deal.

What Different Providers Do About It

Proton Mail encrypts message bodies and attachments. Subject lines are stored in plaintext on Proton’s servers because IMAP and search depend on them. Metadata about senders, recipients, and timestamps is stored in plaintext because mail delivery requires it.

Tutanota encrypts subject lines in addition to message bodies. Senders and recipients are still visible (delivery requires it), but the subject line is opaque to Tutanota itself.

ProtonMail-to-ProtonMail or Tuta-to-Tuta mail keeps metadata internal to a single provider, which limits exposure to that one party plus anyone with court access. Mail to outside addresses traverses the public internet and accumulates plaintext envelope information at every hop.

PGP over a regular provider encrypts only the body. Subject, sender, recipient, and timestamps are visible to your provider just like any normal mail. PGP does nothing for metadata.

No provider can fully solve metadata leakage in email — the protocol requires server-readable envelopes for delivery to work.

What You Can Do

A few patterns reduce metadata exposure:

Use email aliases for context separation. If your alias-to-real-address mapping is private (it’s stored at AnonAddy, SimpleLogin, or self-hosted), recipients only see the alias. Anyone analyzing the alias’s traffic doesn’t immediately see your real identity.

Use a different identity per context. Whistleblowing correspondence on one alias, legal correspondence on another, daily mail on a third. Reduces the value of any single metadata trove.

Run mail through a VPN or Tor. This hides your IP address and rough geographic location from the provider. It does not hide the addresses you send to.

Accept that subject lines can be content. If you’re using Proton Mail and the subject line itself is sensitive, leave it blank or use a meaningless placeholder. The body is encrypted; the subject is not.

Move the most sensitive conversations off email entirely. Signal or another end-to-end encrypted messenger leaks far less metadata than email. The metadata Signal does collect — phone numbers and last-connection time — is narrower than what every email provider must collect to deliver mail.

When This Matters Most

For an ordinary user, metadata leakage from encrypted email is academic. Your provider sees that you mail your sister and your bank and your dentist; nothing happens because of that.

For people whose threats include traffic analysis — sources, attorneys, dissidents, journalists, and anyone whose communications could be subpoenaed in litigation — the metadata is often the entire risk. End-to-end encryption is necessary but not sufficient for those threat models. The full stack is encrypted email plus alias services plus connection-level anonymity plus operational discipline about timing and identity reuse.

The encryption marketing pitch sometimes implies that “end-to-end encrypted” means “private.” It means “the body is private.” That is meaningfully different and worth understanding before you build a workflow that depends on it.