← RFC Reference

Anatomy of Email Headers

Every important header field in an email message explained — what it means, who sets it, and why it matters. Includes a fully annotated real-world example.

A Complete Example

Here is a real email's headers, top to bottom, as they appear in a recipient's mailbox. We will dissect each one.

Now let's go through each header.

Identity Headers

From

The author of the message, as defined by RFC 5322. This is what the recipient sees in their mail client. It consists of an optional display name (Alice) and a mailbox address (alice@example.com). DMARC alignment checks are performed against the domain in this header.

From is not the same as the envelope sender. The envelope sender (MAIL FROM in SMTP) can be completely different. The From: header is set by the message author; the envelope sender is set by the sending system.

To, Cc, Bcc

To: and Cc: are display headers — they indicate the intended audience but do not control delivery. The actual recipients are determined by the SMTP RCPT TO commands, which may include Bcc recipients not listed in any header. A message can have a To: header listing addresses that are not in the RCPT TO, and vice versa (this is how Bcc works).

Reply-To

Not shown in our example, but common. Specifies where replies should be directed if different from From:. Often used when a message is sent from a no-reply address but replies should go to support:

Sender

Used when the entity responsible for sending differs from the author. If Alice's assistant sends a message on her behalf, the headers might read From: Alice and Sender: Assistant. Most messages omit this header.

Message Identification

Message-ID

A globally unique identifier for this message, generated by the sender. The format is <unique-part@domain>. This is critical for threading, deduplication, and bounce correlation. Every message should have one. If your sending system does not set it, the first MTA will generate one — but then you lose the ability to correlate bounces with specific sent messages.

In-Reply-To and References

Used for threading. In-Reply-To contains the Message-ID of the message being replied to. References contains the full chain of Message-ID values in the thread. Mail clients use these to group conversations:

Date and Subject

Date

The date and time the message was composed, set by the sender. The format is specified in RFC 5322. It is not the delivery time. A message can sit in a queue for hours or days before delivery. Always include a timezone offset.

Subject

Free-form text summarizing the message. No length limit in the spec, but mail clients truncate at varying lengths. Keep it under 60 characters for consistent display. Non-ASCII characters must be encoded using RFC 2047 encoding (e.g., =?UTF-8?Q?...?=), though most modern mail systems handle this transparently.

The Received Chain

Each server that handles the message prepends a Received: header. They are read bottom to top — the oldest hop is at the bottom, the most recent at the top. Each header records:

• from — The server that sent the message (hostname and IP)
• by — The server that received it
• with — The protocol used (ESMTP, ESMTPS for TLS, LMTP for local delivery)
• id — The receiving server's queue ID
• for — The recipient (may be omitted for privacy with multiple recipients)
• timestamp — When this hop received the message

The Received chain is invaluable for debugging delivery delays. Compare timestamps between hops to find where time was lost. Note: Received: headers from the sender's side can be forged. Only trust headers added by your own infrastructure.

Return-Path

Set by the final delivering MTA, this records the SMTP envelope sender (MAIL FROM). This is where bounces are sent. In this example, VERP encoding is used — the original recipient (alice@example.com) is encoded into the local part of the bounce address.

The Return-Path is not set by the message author; it is extracted from the SMTP session and added by the delivering server. There should be exactly one Return-Path header in a delivered message.

Authentication Headers

DKIM-Signature

Added by the sending server. The d= field identifies the signing domain (used for DMARC alignment). The s= field is the selector used to look up the public key in DNS. The h= field lists which headers are signed. See Email Authentication Explained for the full verification process.

Authentication-Results

Added by the receiving server (RFC 8601). This is the authoritative record of authentication checks for this message at this hop. The authserv-id (mx1.example.net) identifies which server performed the check. It records SPF, DKIM, and DMARC results, including the identifiers checked.

Security note: Forged Authentication-Results headers from external sources should be stripped by the border MTA. Only trust this header when it is added by your own infrastructure.

MIME Headers

MIME-Version

Indicates the message uses MIME (RFC 2045). This is always 1.0 and should be present on every message. Without it, the message is interpreted as plain US-ASCII text.

Content-Type

Describes the media type of the message body. Common values:

• text/plain — Plain text
• text/html — HTML content
• multipart/alternative — Multiple versions of the same content (typically text and HTML). The mail client picks the best one.
• multipart/mixed — Message with attachments
• multipart/related — HTML with inline images

The boundary parameter defines the delimiter between MIME parts. See RFC 2046 for details.

Content-Transfer-Encoding

How the body is encoded for safe transit. Common values: 7bit, quoted-printable, base64. Attachments use base64. HTML email bodies typically use quoted-printable to handle non-ASCII characters while remaining mostly readable.

List Management Headers

RFC 2369 defines List-Unsubscribe, which provides a URL and/or mailto address for unsubscription. RFC 8058 adds List-Unsubscribe-Post, enabling one-click unsubscribe directly from the mail client's UI without opening a browser. Gmail and other major providers require both headers for bulk and marketing email.

Headers You Should Not See (But Sometimes Do)

X-Mailer / User-Agent

Identifies the mail client or sending software. Sometimes used by spam filters as a signal. Modern sending systems often omit this to reduce fingerprinting surface.

X-Priority / Importance

Non-standard headers that attempt to set message priority. Most mail clients ignore them. Some spam filters treat high-priority markings as a negative signal.

X-Spam-Status / X-Spam-Score

Added by spam filtering systems (like SpamAssassin). Not standardized, but widely used internally. These should not be present on outgoing mail — they are added by the receiving infrastructure.

What Can Go Wrong

Missing Message-ID

If you do not set a Message-ID, the first MTA adds one. But you lose the ability to correlate sent messages with bounces and delivery notifications. Always generate your own Message-ID before sending.

From and envelope sender confusion

A common source of deliverability problems. The From: header shows alice@example.com, but the envelope sender is bounce@esp.com. SPF validates the ESP domain, not your domain. If your DKIM signature also uses d=esp.com, DMARC alignment fails for both mechanisms. The fix: sign with d=example.com so DKIM aligns.

Duplicate or conflicting headers

RFC 5322 specifies that some headers (like From:, Date:, Message-ID:) must appear exactly once. Duplicates can cause unpredictable behavior — different mail clients may pick different values. Some spam filters treat duplicate From: headers as suspicious.

Missing Date header

Without a Date: header, the receiving MTA or mail client will substitute its own timestamp, which may differ significantly. Some spam filters penalize messages without a Date header.

Received chain forgery

Anyone can prepend fake Received: headers to a message before sending it. The receiving MTA can only trust headers it added itself. When debugging, start from the top (most recent) and work down, and stop trusting once you hit the border between your infrastructure and the external world.

Key Takeaways

• Headers are metadata about the message. The envelope (MAIL FROM / RCPT TO) controls delivery; headers are for display and processing.
• From: is what the recipient sees. Return-Path: is where bounces go. They are often different.
• Received: headers form a bottom-to-top chain showing the message's path. Only trust headers from your own infrastructure.
• Authentication-Results: is the receiving server's verdict on SPF, DKIM, and DMARC.
• Always set Message-ID, Date, From, MIME-Version, and Content-Type.
• For bulk/marketing email, include List-Unsubscribe and List-Unsubscribe-Post.

Further Reading

Related RFCs