Email Headers Explained: What the Metadata Shows

Email headers are metadata attached to an email message. They record information such as the sender and recipient fields, the route the message took, and authentication results. To read raw headers, start with the message’s identity and route, then inspect authentication-related fields and any headers relevant to the issue you are investigating. A header is evidence about a message and its processing—not, by itself, proof of who operated a server or whether a message reached a person’s inbox.

What email headers contain

An email message has a body and a set of header fields. The fields appear before the body in raw message data. Mail apps usually show only a subset in the message view; a command such as “show original” or “view source” may expose the full headers. The exact label and location depend on the app, so treat interface instructions as client-specific.

Common fields include:

For related terminology, see the core email glossary. For a closer look at one important field, read Authentication-Results header.

How to read raw email headers

Use this reading order to avoid treating one field as a complete explanation:

1. Confirm the message. Check From, To, Date, and Subject against the message you meant to inspect. Remember that displayed fields describe the message; they do not independently verify the sender.
2. Trace the route. Read the Received fields as a reported sequence of server handoffs. Since each receiving server prepends a field, the newest hop is commonly near the top and earlier hops follow below. Establish the order by comparing timestamps and host details rather than assuming every line is trustworthy or complete.
3. Inspect authentication results. Find Authentication-Results and note which domain and method each result refers to. SPF, DKIM, and DMARC are related but distinct checks; a pass for one does not mean every identity in the message aligns. The guide to reading authentication results explains how to interpret the result details.
4. Check fields tied to your question. For a mailing-list unsubscribe review, inspect List-Unsubscribe and List-Unsubscribe-Post; the latter has specific one-click semantics. See List-Unsubscribe one-click semantics and testing one-click unsubscribe headers.
5. Compare with independent records. If you are diagnosing delivery or authentication, compare the headers with relevant sending and receiving system logs. A header snapshot alone may not show later processing or what a recipient saw.

What headers can and cannot establish

Headers can help reconstruct a reported route, identify message metadata, and understand authentication results recorded by a system. They are useful diagnostic evidence, particularly when compared across copies of the same message or with server logs.

They have limits. From is not proof that the apparent sender controlled the sending system. A Received line records a system’s account of a handoff; it does not independently validate every earlier line. Authentication results describe checks performed in a particular context and should be read with the relevant domain and method. Nor do headers alone establish that a human opened or read a message.

When comparing a failed DMARC evaluation, focus on the specific domains and values in the relevant fields rather than treating “pass” or “fail” as a verdict on the whole message. See DMARC alignment and failed header values.

Practical header review checklist

• Confirm the message using its subject, sender, recipient, and timestamp.
• Preserve the complete raw header, including all Received fields.
• Read route entries alongside their timestamps and server names.
• Identify the Authentication-Results field and the domain each check evaluates.
• Check list-unsubscribe fields only when unsubscribe behavior is relevant.
• Compare the header with available mail-system logs before drawing a conclusion.
• Record uncertainty: a header is a useful record, not a complete account of every event.

Common mistakes when reading headers

• Treating From as authentication. It is a message field, not proof of domain control.
• Reading Received lines in the wrong order. Work from the newest reported hop toward earlier ones, checking timestamps and context.
• Equating one authentication pass with DMARC alignment. The method, domain, and alignment matter; inspect the details.
• Assuming headers show the complete delivery story. They may need to be supplemented with system logs and other copies.
• Treating unsubscribe headers as proof of an unsubscribe event. They describe supplied mechanisms, not whether a recipient or client used them.

Sources