Metadata vs. Content
Think of a sealed letter.
Nobody can read what’s inside without opening it. Great. But the envelope still says who it’s for, where it’s going and, if you put your address on the back, who sent it. The postal service knows when it was posted. Your neighbor knows you got three letters from the same law firm this month.
Encryption is the seal. It’s not the envelope.
The short answer: encryption protects the content of a message, but usually not its metadata. With encrypted email, servers and providers can typically still see who sent the message, who received it, when it was sent, how big it was and, in many cases, the subject line and the IP addresses involved. That metadata alone can reveal a surprising amount about you.
This article goes through what that actually means in practice: what stays visible with TLS, with PGP and S/MIME, and with encrypted messengers. And what you can realistically do about it.
What is the difference between metadata and content?
Content is what you say. The body of an email, the text of a message, the file you attach.
Metadata is data about that communication. Who, when, where, how often, how much. For an email, that typically includes:
- sender and recipient addresses (including Cc)
- date and time
- the subject line
- message size
- the servers the message passed through, often with IP addresses
- the email software used to write it
- message IDs that link replies into threads
A lot of this lives in the email header, which travels with every message. I took a closer look at what’s in there in what your email headers reveal about you.
The important part: metadata is often not just visible, it’s necessary. A server can’t deliver an email without knowing where it goes. That’s why it’s so hard to encrypt away.
Why does metadata matter if the content is encrypted?
Because patterns tell stories.
One email to a doctor’s office means nothing. Weekly emails to an oncology clinic, a health insurer and a patient support group mean something. You don’t need to read a single one of them to draw conclusions.
This isn’t just a thought experiment. In a 2016 study published in PNAS, Stanford researchers analyzed phone metadata (only who called whom and when) from more than 800 volunteers. From that alone, they could infer things like a likely heart condition, from calls to a cardiologist, a pharmacy and a hotline for a cardiac arrhythmia monitoring device, or that someone probably owned a specific type of rifle.
Or take Michael Hayden, former director of both the NSA and the CIA, at a debate at Johns Hopkins University in 2014:
“We kill people based on metadata.”
Blunt, but it makes the point better than any privacy advocate could. Intelligence services don’t treat metadata as harmless. You shouldn’t either.
What does TLS encryption hide in email, and what doesn’t it?
Most email today is encrypted in transit with TLS: between your app and your provider, and usually between providers too. That’s good. It stops someone on the network, like a public Wi-Fi operator, from reading your mail as it passes by.
But TLS only protects the connection. Each server along the way decrypts the message, handles it, stores it and passes it on. So with TLS alone, your provider and the recipient’s provider can see everything: content and metadata. I explained that difference in more detail in encryption at rest vs. in transit.
And even on the network itself, TLS doesn’t hide everything. An observer can still see which IP addresses are talking to each other, when, and how much data flows. Until recently, the server name you were connecting to was also sent in plain text during the TLS handshake (the so-called SNI). The new Encrypted Client Hello standard, published as RFC 9849 in March 2026, encrypts that part. But by its own account, the target can still leak through IP addresses or unencrypted DNS lookups. Encryption keeps chipping away at metadata. It hasn’t made it disappear.
What email metadata is visible with PGP or S/MIME?
End-to-end encryption with OpenPGP or S/MIME goes further than TLS. The message is encrypted on your device and only decrypted on the recipient’s. Your provider stores a blob it can’t read.
But only the body gets that protection by default. What stays readable to every server along the way:
- From, To and Cc: who’s talking to whom
- Date: when
- Subject: in most setups, yes, still in plain text (more on that below)
- Received headers: the servers the message passed through, often including IP addresses
- Message size: a 4 MB message probably isn’t just a quick “thanks”
- Message-ID, In-Reply-To and References: how messages connect into conversations
- The fact that it’s encrypted: which can be interesting in itself
Attachments depend on the format. With PGP/MIME and S/MIME, they’re part of the encrypted payload, file names included. With older inline PGP, attachments are often encrypted one by one, and their file names can remain visible.
Does PGP encrypt the email subject line?
Traditionally, no. And this surprises a lot of people.
The subject is part of the email header, and classic OpenPGP and S/MIME only encrypt the body. Proton Mail, for example, states in its own documentation that subject lines are not end-to-end encrypted, to stay compliant with the OpenPGP standard and interoperable with other email systems.
There is a fix, at least on paper. RFC 9788 (“Header Protection for Cryptographically Protected Email”, August 2025) standardizes how email clients can move headers like the subject into the encrypted part and put a placeholder in the visible header. Thunderbird already encrypts the subject of OpenPGP messages. Recipients using clients that don’t understand this just see “…” as the subject.
Which shows the real problem: header protection only works well when both sides support it. Until then, the safest habit is boring but effective. Write subject lines that don’t say anything sensitive.
Why can’t encrypted email hide who you’re writing to?
Because the servers need to know.
Email is delivered with SMTP, and SMTP works like the postal service: every server along the way has to read the address to know where to send the message next. The recipient’s server has to know which mailbox to put it in. You can’t encrypt that away without breaking delivery.
RFC 9788 says it plainly: encrypted messages “cannot shield all of their Header Fields from visibility” and still be delivered reliably.
Bcc is a partial exception. Bcc recipients don’t appear in the header other recipients see. But the sending server still knows them, because it has to deliver to them.
This is a structural limit of email, not a bug in any one tool. Anyone who promises “fully anonymous encrypted email” is either redefining “fully” or using a system that isn’t really email anymore.
What can your email provider see?
It depends on how you encrypt.
Without end-to-end encryption (which is most email): your provider can technically access everything. Content, attachments, contacts, timestamps. Whether it actually looks is a question of policy and trust, not technology.
With end-to-end encryption: your provider can’t read the body, but it still handles the metadata. It knows who you email, when, how often, from which IP address you log in, and usually the subject line. Providers may also keep logs, and those can be requested by authorities under the laws that apply to them.
That’s why “encrypted email provider” doesn’t automatically mean “private”. It means the content is protected. The rest depends on what the provider stores and for how long.
What do end-to-end encrypted messengers still reveal?
Messengers have more freedom than email, because they don’t need to stay compatible with a 40-year-old protocol. Some use that freedom to reduce metadata, and the difference shows.
Signal is the usual example. It publishes its responses to government data requests, and in those responses it has said that the only data it could provide was when an account was created and when it last connected to the service. No contact lists, no message history, no group memberships.
Not every messenger works like that. Many store who you talk to and when, even if they can’t read the messages. “End-to-end encrypted” on the app store page tells you about the content. It tells you nothing about metadata.
What metadata hides inside your attachments?
This is the one people forget. Even if the message is encrypted, the files inside it carry their own metadata, and the recipient gets all of it.
- Photos often contain EXIF data: camera model, date and time, sometimes exact GPS coordinates of where the photo was taken.
- Office documents and PDFs can contain author names, company names, editing time, earlier versions and comments you thought you’d deleted.
Encryption doesn’t remove any of that. It just makes sure only the recipient sees it. Which might be exactly the person you didn’t want to send your home coordinates to.
How can you reduce email metadata exposure?
You can’t eliminate email metadata. But you can reduce what it gives away:
- Keep subject lines generic. “Documents” instead of “Divorce papers, final version”.
- Use header protection if your client supports it, and know that recipients with other clients may see a placeholder subject.
- Strip metadata from attachments before sending: remove EXIF data from photos, check document properties, export PDFs cleanly.
- Use Bcc for group emails where recipients shouldn’t see each other.
- Check whether your provider adds your IP address to outgoing mail. Send yourself an email and look at the headers.
- Use email aliases for sign-ups, so one address doesn’t connect all your accounts.
- Pick the right channel. For really sensitive conversations, a messenger designed to minimize metadata can be a better fit than email.
- Think about where your mail is stored. Every copy on a server is a copy whose metadata someone else holds. Keeping your archive locally limits how much sits around elsewhere for years.
Metadata vs. content at a glance
| What | TLS only | PGP / S/MIME | PGP / S/MIME with header protection |
|---|---|---|---|
| Message body | Visible to providers | Encrypted | Encrypted |
| Attachments (PGP/MIME, S/MIME) | Visible to providers | Encrypted | Encrypted |
| Subject line | Visible to providers | Usually visible | Encrypted (placeholder visible) |
| Sender and recipients | Visible to providers | Visible | Largely visible (needed for delivery) |
| Date and time | Visible to providers | Visible | Visible |
| Message size | Visible to providers | Visible | Visible |
| Servers and IP addresses | Visible to providers | Visible | Visible |
Look at the right-hand column. Even with the best email encryption available today, most of the rows still say “visible”. That’s not a reason to skip encryption. It’s a reason to know what it does.
Frequently asked questions
Is email metadata encrypted?
Mostly not. TLS encrypts metadata on the network between servers, but every server that handles the message can read it. End-to-end encryption with PGP or S/MIME protects the body, while sender, recipients, date, size and usually the subject line stay visible.
Does PGP encrypt the subject line?
Not by default in traditional OpenPGP. The subject is part of the email header, which stays unencrypted. Some clients, such as Thunderbird, support protected headers that move the subject into the encrypted part, standardized in RFC 9788. Recipients without support see a placeholder subject.
Can my email provider see who I email?
Yes. Even with end-to-end encryption, your provider needs sender and recipient addresses to deliver your mail, so it can see who you communicate with and when. Without end-to-end encryption, it can technically access the content too.
Does a VPN hide my email metadata?
Only partly. A VPN hides your IP address from your email provider and hides your email traffic from your local network. It doesn’t hide sender, recipients, subject or timestamps from the email servers that handle your messages.
Is metadata less sensitive than content?
Not necessarily. Metadata is structured, easy to analyze at scale and hard to hide. Research on phone metadata has shown that call patterns alone can reveal health conditions and other sensitive details, without reading a single message.