How to Read Email Headers

Email headers are the metadata every message carries: who sent it, the path it took to reach you, and whether it passed the checks that prove it is genuine. Most of it stays hidden behind a friendly From line and a subject, but the full block is always there, and it answers the two questions that matter most. Where did this really come from, and can I trust it? To skip straight to a parsed view, paste a header block into the email header analyzer. This guide explains what that output means.

The message format itself is defined in RFC 5322, and the transport that stamps most of the interesting headers is SMTP. You do not need to memorize either to read a header, but it helps to know the fields are a standard, not each provider's invention.

Finding the raw headers

The headers you want are the raw ones, not the tidy summary your mail client shows. Each major client hides them in a different place:

• Gmail: open the message, click the three-dot menu at the top right, and choose Show original.
• Outlook (desktop): open the message, go to File, then Properties, and copy the text in the Internet headers box.
• Outlook on the web: open the message, click the three-dot menu, and choose View, then View message details.
• Apple Mail: select the message and choose View, then Message, then Raw Source.

Copy the whole block, from the first line to the blank line that separates the headers from the body. That blank line matters: everything above it is header, everything below is the message itself.

The fields you can read at a glance

The top of a header block holds the familiar fields, and it is worth knowing that a sender controls all of them:

• From is the address you see in your inbox. It is display text, and nothing stops a sender from writing whatever they like here. This is exactly why spoofing works and why authentication exists.
• To, Subject and Date are equally sender-set.
• Return-Path is the envelope sender, the address bounces go back to. It is set during delivery rather than by the person composing the mail, so it often reveals the real sending system even when From is dressed up.
• Message-ID is a unique identifier for the message, useful when you need to trace one specific email through server logs.

Because From is unverified, comparing it against the Return-Path is a quick sanity check. When the two sit on different domains, the mail was sent by a system other than the one it appears to come from. That is entirely normal for newsletters and mailing platforms, which send on a brand's behalf from their own infrastructure, so it is a flag to understand rather than a verdict on its own.

Reading the Received chain

The Received headers are the message's travel log. Every mail server that touches a message adds its own Received line, and it adds it to the top, so the newest hop sits highest and the original sender sits at the bottom. To follow the journey in order, read from the bottom up.

A single Received header looks dense but breaks into a few parts:

Received: from sender.example.com (sender.example.com [198.51.100.7])
        by mx.google.com with ESMTP id abc123
        for <you@gmail.com>;
        Tue, 22 Jul 2026 08:15:20 -0700 (PDT)

The from names the server that handed the message over, the by names the server that received it, with records the protocol used, and the timestamp after the final semicolon says when. Line up the timestamps across the chain and you can see how long each hop took. Most legitimate mail crosses its entire path in seconds. A gap of minutes or hours between two hops usually means greylisting, where a receiver deliberately delays a first-time sender, or a queue that backed up somewhere along the way. If you are chasing down why a message arrived late, the Received chain is where the delay is recorded. For the delivery side of that problem, see why your email goes to spam.

The part that actually proves trust

The header that settles whether a message is genuine is Authentication-Results, defined in RFC 8601. Your receiving mail provider runs the authentication checks and records the outcome here, which is why it is trustworthy: it reflects a decision made by the receiver, not a claim made by the sender.

A typical result reads like this:

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=news@example.com;
       dkim=pass header.d=example.com;
       dmarc=pass (p=REJECT) header.from=example.com

Three checks, three verdicts:

• SPF confirms the server that sent the message is one the domain authorized to send for it. A pass means the sending IP was on the domain's approved list. The full mechanism is covered in what is SPF.
• DKIM confirms the message carries a valid cryptographic signature and was not altered in transit. See what is DKIM.
• DMARC ties the two together and checks they align with the visible From domain, then applies the domain owner's stated policy. See what is DMARC.

A pass on all three is the healthy result. A fail is worth stopping on, especially a DMARC fail, because DMARC failing means the message could not be tied back to the domain it claims to be from. That is the single strongest signal that an email is not what it says it is.

Spotting a spoofed message

Put the pieces together and a forgery usually gives itself away. The classic pattern is a From address on a domain you recognize, an SPF or DMARC result of fail, and a Return-Path pointing at some unrelated domain. The display name looks right, the authentication does not, and the envelope sender confirms the message came from somewhere else entirely.

None of these signals is conclusive in isolation. Plenty of legitimate mail has a mismatched Return-Path, and SPF can fail for dull reasons like a forwarding server. It is the combination that matters: a failed DMARC result alongside a domain mismatch is a message to treat with suspicion, whatever the From line says.

Let the tool do the parsing

Reading headers by hand is a useful skill, but you do not need to do it every time. Paste a full header block into the email header analyzer and it lays out the delivery path, the timing of each hop, and the SPF, DKIM and DMARC results, and flags a From-versus-Return-Path mismatch for you. It only reads what the receiving servers already recorded, so it is a faster way to see the same evidence this guide walks through.

For the wider picture of how these checks fit together, start with email authentication explained.