Email headers: what is hidden behind every message
Every email message consists of two parts: headers and body. The body is the content you read, text, HTML, attachments. The headers are the metadata that controls how the message is routed, displayed, authenticated, and processed. Most email clients hide headers by default, showing only From, To, Date, and Subject. But the full header block typically contains 15 to 40 fields that record the entire lifecycle of a message from composition to delivery.
Header format
Email headers follow the syntax defined in RFC 5322. Each header is a single logical line:
Header-Name: header value
Long values continue on the next line by starting with whitespace (folding). Headers are separated from the body by a single blank line. Order matters for some fields: Received headers are read bottom to top, tracing the path the message traveled. Most other headers can appear in any order.
Address headers
The first group of headers identifies who sent the message and who should receive it.
- From. The sender address visible to the recipient. This is a message-level field, not an envelope address, so anyone can set it to anything. DMARC exists specifically to protect this field from spoofing.
- To. The recipient address. It can hold multiple comma-separated addresses and does not have to match the actual envelope recipient passed in the SMTP RCPT TO command.
- Reply-To. Where replies go. If absent, replies go to From. Mailing lists often set Reply-To to a support address so that responses do not go back to the original sender.
- Cc and Bcc. Carbon copy and blind carbon copy. Cc is visible to all recipients; Bcc is not. At the SMTP level, both are just additional RCPT TO commands.
Routing headers
This group records how the message got from sender to recipient.
- Received. Every server that handles the message prepends its own Received header. Reading them from bottom to top reconstructs the full delivery path. This is the primary tool for diagnosing delivery problems.
- Return-Path. Set by the receiving server based on the MAIL FROM in the SMTP session. Bounce notifications go to this address. SPF checks the domain found here, not the From header.
- Message-ID. A unique identifier assigned by the sending MTA. Used for deduplication, threading via In-Reply-To and References headers, and debugging in server logs.
Authentication headers
These headers emerged as a direct response to sender forgery.
- DKIM-Signature. A cryptographic signature covering selected headers and the message body. The receiving server verifies it against the public key published in the sender's DNS. A valid signature means the message was not altered in transit.
- Authentication-Results. Added by the receiving server. Contains the SPF, DKIM, and DMARC check results for the message. The format is standardized in RFC 8601.
- ARC-Authentication-Results. Part of the ARC (Authenticated Received Chain) protocol. When a message is forwarded, ARC preserves the original authentication results so the final recipient can see the checks that passed before forwarding occurred.
Content headers
This group describes the structure of the message body.
- Subject. The message subject line. The only content header that is always visible in the client interface.
- Content-Type. The MIME type of the body: text/plain, text/html, multipart/alternative. Messages with attachments use multipart/mixed.
- Content-Transfer-Encoding. How the body is encoded for transport: 7bit, quoted-printable, or base64. Defines how binary data is represented in SMTP's text-based protocol.
- MIME-Version. Almost always "1.0". Signals that the message uses the MIME standard.
Bulk sending headers
A separate category applies specifically to mass mailings.
- List-Unsubscribe. An unsubscribe link. Since 2024, Google and Yahoo require this header for bulk senders.
- List-Unsubscribe-Post. An extension to List-Unsubscribe that enables one-click unsubscription per RFC 8058.
- Precedence. Indicates message priority. The value "bulk" signals a mass mailing. Some servers use it to prioritize their queues.
- Feedback-ID. Used by Google to aggregate campaign statistics in Postmaster Tools.
Envelope vs. header addressing
This is the distinction people most often confuse. Email has two addressing layers. Envelope addresses (MAIL FROM and RCPT TO) travel in the SMTP session and control actual delivery. Header addresses (From, To) are written inside the message and displayed in the client.
The two do not have to match. A mailing from company.com might use the envelope sender bounce-12345@tracking.company.com to handle bounces, while showing newsletter@company.com in the From header. That is entirely normal, as long as SPF and DKIM are configured for both domains.
How to view headers
In Gmail: open the message, click the three dots on the right, and choose "Show original". In Outlook: open the message, go to File, then Properties, then Internet Headers. In Thunderbird: View, then Message Source. The full header block shows the delivery path, authentication results, and any service-level annotations.
uChecker operates at the DNS and SMTP level, the same infrastructure that generates your message headers. Validating addresses before you send means your Received headers will not accumulate records of rejected messages, and your bounce handler will have little to do.
