When a message is encrypted with PGP/MIME (RFC 3156) or S/MIME (RFC 8551), the body and attachments are wrapped in an encrypted container. The outer message headers are not encrypted. That includes the From, To, Cc, Date and Message-ID fields, and it includes Subject. Anyone who handles the message in transit, and the mail servers involved, can read the subject line even when the body is unreadable to them. For many people, the subject carries more information than the body does.
What protected headers change
Protected headers is an IETF draft, not a finished standard, and implementations vary. The idea is simple. The sending client places the real subject, and sometimes other header fields, inside the encrypted part of the message. The outer Subject is replaced with a neutral placeholder. A client that understands the mechanism shows the real subject after decrypting. A client that does not understand it shows the placeholder, which is why the outer subject is usually a generic value rather than the real one.
Because the mechanism lives inside the encrypted container, it protects the subject only from parties who cannot decrypt the message. Recipients who hold the key see the real subject as usual.
What stays visible
Protected headers do not make a message anonymous. The envelope sender and recipients are still needed for delivery, so servers see them. The outer From, To and Date fields remain visible, as does the Message-ID. Message size and timing are visible as well. A third party with access to the transport can still learn who corresponded with whom, when, and how often, even if neither the subject nor the body is readable. Protected headers reduce what is exposed; they do not remove the metadata.
Check client support first
Support for protected headers depends on the client and its version, and the implementation details differ. Before relying on it, verify behavior with a test message. The sending client's documentation should describe whether it places the subject inside the encrypted part, and the recipient's client should display it after decryption. If either side does not support it, expect the placeholder subject to appear in the recipient's list view, with the real subject visible only if the client can process it.
Do not assume support because the feature is described in general terms. Confirm it in the specific client you use. The PGP documentation on ITProMail, in the PGP guide, covers key management under Account > Encryption and the Web Key Directory, but the webmail client's behavior should be checked separately before depending on it for sensitive subjects.
Test the outer headers
A simple test confirms what a third party sees. Send an encrypted message to an address you control, with a distinctive subject. Then view the raw message source of the copy in your Sent folder and in the recipient's inbox. Check three things:
- The outer
Subjectheader contains a placeholder rather than your distinctive text. - The body is an encrypted block, not readable text.
- The outer
From,ToandDatefields are still present, which is expected.
If the distinctive subject appears in the outer headers, the client is not using protected headers, and the subject should be treated as visible.
Write subjects as if they will be read
Even with protected headers, the safest subject is one that reveals nothing sensitive. Use neutral wording such as "Contract follow-up" rather than the name of a party or a case number. Do not put passwords, account numbers or medical details in the subject under any circumstances, because the subject often appears in notifications, in logs of mail clients and in search results on devices that index mail. Subject lines are a poor place for anything that needs protection.
Where this fits
Protected headers are one part of reducing exposure in encrypted mail. Key discovery, verification and recovery matter just as much. For the key side of the picture, see PGP in practice, and for planning around lost keys, see key loss and recovery planning. The metadata that remains visible is discussed further in metadata is the leak.