The anatomy of email headers

SendStreak Academy

As defined in RFC 5322, every email is split into two primary segments: the header and the body. The header contains essential metadata required for the transmission, verification, and rendering of the message, while the body contains the actual content intended for the recipient. These segments are strictly separated by a single blank line. For engineers, headers serve as the primary diagnostic tool, providing an interface for programmatically interacting with and validating email traffic.

Standard headers are mandatory or highly conventional fields that dictate basic message properties. These include From (the sender’s address), To (the recipient), Subject, and Date. Additionally, the Message-ID provides a globally unique identifier for the message, while Content-Type specifies the MIME format, such as text/plain or text/html. These fields ensure that mail clients can correctly attribute messages, thread conversations and render multi-part content.

Security and deliverability rely heavily on extended headers that facilitate authentication. For example the DKIM-Signature header contains a cryptographic hash of the message content, ensuring it was not altered in transit. Simultaneously, receiving servers append Authentication-Results headers to summarize whether the message passed SPF, DKIM, and DMARC checks. Engineers also frequently inspect proprietary headers (often prefixed with X-), such as X-Spam-Status or X-Report-Abuse, which include internal metadata provided by mail service providers to explain why a message was filtered or flagged.

A representative example of a technical email header follows:

From: SendStreak Support <[email protected]>
Date: Wed, 07 Jan 2026 18:00:00 +0000
Subject: Your Password Reset Request
Message-ID: <[email protected]>
Content-Type: text/html; charset=UTF-8

An interesting technical fact is that while most headers are generated by the sender or the sender infrastructure, the Received headers are appended by every Mail Transfer Agent (MTA) the email passes through. This creates a chronological audit trail of IP addresses and timestamps, allowing developers to trace the exact routing path of a message across the internet. By analyzing these entries, it is possible to identify exactly where a relay delay occurred or which specific server initiated the transmission.

Header reference

The following table lists the most commonly encountered headers in transactional email, grouped by function:

Routing and identification

Header	Purpose
`From`	The sender’s display name and email address. This is what the recipient sees.
`To`	The intended recipient address.
`Reply-To`	Optional. Directs replies to a different address than `From`.
`Message-ID`	A globally unique identifier assigned by the sending server (e.g., `<[email protected]>`). Used for threading and deduplication.
`In-Reply-To`	References the `Message-ID` of the message being replied to. Used by clients to build conversation threads.
`Date`	The timestamp when the message was composed.
`Subject`	The subject line.

Content and encoding

Header	Purpose
`Content-Type`	MIME type of the body. Common values: `text/plain`, `text/html`, `multipart/alternative`.
`Content-Transfer-Encoding`	How the body is encoded for transport. Typically `7bit`, `quoted-printable`, or `base64`.
`MIME-Version`	Always `1.0`. Declares that the message uses MIME formatting.

Authentication and security

Header	Purpose
`DKIM-Signature`	A DKIM cryptographic signature over the message content and selected headers. Proves the message was not altered in transit.
`Authentication-Results`	Added by the receiving server. Summarizes the results of SPF, DKIM, and DMARC checks.
`Received-SPF`	Older format for SPF check results. Largely superseded by `Authentication-Results`.
`ARC-Authentication-Results`	Part of the Authenticated Received Chain (ARC) protocol. Preserves authentication results across forwarding hops.

Routing trace

Header	Purpose
`Received`	Appended by each MTA in the relay chain. Contains the server hostname, IP address, protocol (ESMTPS, SMTP), and timestamp. Read bottom-to-top to trace the message’s path.
`Delivered-To`	The final recipient address. Added by the destination mail server.
`Return-Path`	The envelope sender address (from SMTP `MAIL FROM`). Bounce notifications are sent here.

Proprietary headers

Header	Purpose
`X-Spam-Status`	SpamAssassin verdict and score (e.g., `No, score=-2.1`).
`X-Google-DKIM-Signature`	Google’s internal DKIM signature, separate from the sender’s.
`X-Mailer`	Identifies the software that generated the message.

Debugging with headers

When a transactional email fails to arrive or lands in spam, headers are the first place to investigate:

Check Authentication-Results - Look for spf=pass, dkim=pass, and dmarc=pass. Any fail result points to a DNS misconfiguration.
Read the Received chain - Work from bottom to top. Large time gaps between Received entries indicate relay delays. Unexpected IP addresses may indicate routing through an unintended server.
Inspect Return-Path - If this does not match your sending domain, SPF checks will likely fail because SPF validates the envelope sender, not the From header.
Look for X-Spam-Status - If present, the score and triggered rules explain why the message was flagged.

What is SPF? - How SPF records authorize sending servers and appear in Authentication-Results.
What is DKIM? - How DKIM signatures are verified and recorded in headers.
What is DMARC? - The policy layer that ties SPF and DKIM results together.
What is SMTP? - The protocol that generates many of the headers covered here.
What is TLS/STARTTLS in email? - How TLS encryption status is recorded in Received headers.