The Envelope Versus the Letter: How Email Transports Data
To understand why email leaks information, it helps to look at the physical mail system. When you drop a sealed envelope into a mailbox, the postal service must read the recipient address, the return address, and the postmark to route the letter. The postal carrier does not need to read the personal letter inside, but they must see the envelope to do their job.
Email operates on a similar separation between the message body (the letter) and the headers (the envelope). The foundational protocol governing email routing, the Simple Mail Transfer Protocol (SMTP), was designed in the early 1980s without strong confidentiality protections in mind. SMTP servers, known as Mail Transfer Agents (MTAs), rely on headers to deliver messages across multiple intermediary servers until they reach the recipient's inbox.
Even when you use modern security extensions such as end-to-end encryption, this structural division remains. End-to-end encryption tools typically secure only the message body and file attachments. The routing envelope—the email metadata—must remain largely readable to the machines handling delivery.
Anatomy of an Email Header
Every email you send or receive carries a block of structured data placed before the body of the message. These lines of text tell mail software how, when, and by whom the message was handled. A standard header set contains several revealing fields:
From:andTo:: The displayed sender and recipient addresses. While these can be spoofed in transit, they are recorded by mail servers during processing.Date:: The exact timestamp indicating when the email was composed or dispatched by the client.Received:: A record appended by each intermediary server that processed the email. This field often documents the server domain, timestamp, and sometimes the originating client IP address.Message-ID:: A unique identifier generated by the sending system, which can reveal system time, process IDs, or domain naming conventions.User-Agent:orX-Mailer:: The specific email client and operating system version used to compose the message (for instance, Thunderbird on Linux or Outlook on Windows).Authentication-Results:: Cryptographic signatures such as SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) used to verify that the sender domain is authentic.
Each of these fields provides external observers and service providers with context about your communication habits, your physical location, your device configuration, and your social graph.
Why Subject Lines Remain in Plaintext
A frequent surprise for privacy-conscious users is discovering that the Subject: line of an encrypted email is often completely visible. If an adversary intercepts an OpenPGP-encrypted message, they cannot read the paragraphs inside, but they can usually read the subject line in cleartext.
The explanation lies in the technical specification for email formatting, known as RFC 5322. Under this standard, the subject is defined as a header field rather than part of the message body. Because email clients historically relied on headers to organize mailboxes, display notification snippets, and construct search indexes without opening individual payloads, encrypting the subject broke interoperability.
Consider what happens when an email arrives at a traditional email client like Microsoft Outlook, Apple Mail, or a webmail interface:
- The client downloads the header list via IMAP or POP3 to populate the inbox view.
- The user scans down a list of subjects to decide which message to read.
- The client fetches the full message payload only after the message is selected, decrypting it using the user's private key.
If the subject were encrypted inside the message payload, the email client could not display a readable inbox without first downloading and decrypting every single email in advance. For low-powered devices or accounts with thousands of messages, this requirement historically created severe performance bottlenecks.
The Mechanics of Metadata Leaks
Email delivery is rarely a direct peer-to-peer exchange. Instead, it is a hop-by-hop relay system. When you click send, your email client hands the message to your provider's outgoing MTA. That server looks up the Domain Name System (DNS) records of the recipient domain, locates their incoming MTA, and forwards the message across the public internet.
While transport layer encryption (STARTTLS) is widely adopted by major providers like Google, Microsoft, and Proton Mail to encrypt the connection between servers, TLS only protects data in transit between two specific points. It functions like an armored transport truck traveling between distribution centers:
STARTTLS encrypts the connection between servers, not the data stored on them. At every hop, the receiving server unloads the truck, inspects the headers to verify where the parcel goes next, and records the interaction in its internal log files.
Consequently, network eavesdroppers capable of observing traffic flows, or any compromised server along the path, can log the timing, size, sender, recipient, and subject line of the email. Even without the body text, this transactional metadata allows third parties to infer sensitive relationships, such as contact with medical specialists, legal counsel, whistleblowing platforms, or debt collectors.
Approaches to Mitigating Header Leakage
Developers and privacy advocates have implemented several techniques to reduce the amount of information exposed by email headers, though each carries practical trade-offs.
Protected Headers and Memory Hole
Standardization groups developed an OpenPGP convention often called "Protected Headers" (originating from the Memory Hole project). Under this approach, the real subject line is copied inside the encrypted message body, while the outer, public header is replaced with a generic placeholder such as Subject: Encrypted Message. Email clients that support the standard, such as Mozilla Thunderbird with Enigmail or native PGP support, decrypt the body and dynamically overwrite the displayed placeholder with the real subject.
Proprietary Encrypted Ecosystems
Services like Tuta (formerly Tutanota) take a different architectural route. Instead of relying on traditional OpenPGP and standard SMTP for internal communications, Tuta uses a custom encryption protocol. When two Tuta users email each other, the entire message structure—including subject lines and sender details stored on the server—is encrypted end-to-end. However, when communicating with outside users on traditional providers like Gmail, Tuta must fall back to standard SMTP mechanisms or use password-protected symmetric links.
Header Stripping
Privacy-oriented providers such as Proton Mail, Mailbox.org, and Mullvad Luta automatically strip sensitive client metadata before forwarding mail to external destinations. These services remove the originating client's residential IP address and the specific User-Agent string from outgoing headers, replacing them with the mail server's own generic parameters. This prevents the recipient or intermediate relays from discovering the sender's physical location or operating system.
The Trade-Offs of Strict Metadata Protection
Eliminating email metadata entirely is technically incompatible with the open, federated architecture of SMTP. Every attempt to hide metadata introduces friction into the user experience:
- Loss of Native Search: If subject lines and headers are fully encrypted at rest on zero-knowledge servers, the server cannot build a search index. Search queries must run client-side within the browser or app, requiring substantial local storage and processing power.
- Broken Push Notifications: Mobile devices often rely on push notification servers (operated by Apple or Google) to alert users to incoming mail. Generating notification previews that show the sender and subject requires either exposing that data to third-party notification services or draining battery life by waking the local client to decrypt each message in the background.
- Defeated Spam and Fraud Filtering: Modern spam filters rely on analyzing header patterns, IP reputation, and DKIM signatures across billions of messages. Encrypting or stripping headers makes it difficult for receiving servers to distinguish legitimate correspondence from malicious phishing campaigns.
Understanding these constraints allows users to choose the right tool for their threat model. Email remains an open and durable tool for federated global communication, but it was not engineered for absolute anonymity. For conversations where the mere existence of contact must remain hidden, dedicated metadata-minimizing protocols like Signal or Briar provide structural guarantees that standard email cannot match.