How-to Concepts

How to Read an Email Header (SPF, DKIM, and DMARC)

The From line you see is not the address SPF actually checks. Learn to read the headers that decide whether a message is real: Return-Path, the Received hops, and the Authentication-Results that record spf, dkim, and dmarc.

Watch

Find where mail really came from: From vs Return-Path, Received hops, and Authentication-Results.

June 11, 2026 · 7 min read

TL;DR

1 The visible From is what the reader sees; the Return-Path (envelope sender) is what SPF actually checks, and the two can differ.
2 Authentication-Results records the receiver's verdict: spf=, dkim=, and dmarc= each pass or fail. DMARC passing means SPF or DKIM passed AND aligned with the From domain.
3 View raw headers via Gmail Show original or Outlook View source, then read the path and the auth results from the top down.

What it does

Every email carries a block of headers above the body that records who sent it, the path it took, and how the receiving server judged its authenticity. Most of those headers are invisible in a normal mail client, but they are the difference between "this looks like it is from my bank" and "this actually authenticated as my bank." Learning to read them is the single most useful skill for answering the question "is this email real?"

The trap is the From header. It is the only sender field a reader normally sees, and it is trivial to forge: anyone can write <code>From: support@yourbank.com</code> in a message. SPF does not check that header at all. SPF checks the Return-Path (the envelope sender, also called <code>MAIL FROM</code>), which is a separate address the visible From can diverge from. A message can show a perfect-looking From and still fail authentication because the Return-Path belongs to somewhere else entirely.

The header that resolves it is Authentication-Results, written by the receiving mail server. It records the verdicts for <code>spf=</code>, <code>dkim=</code>, and <code>dmarc=</code>, each pass or fail. Read together with the Received hops (the relay-by-relay path the message took), these headers let you reconstruct where a message really came from and whether it authenticated as the domain it claims.

How it works

1
From vs Return-Path. <code>From</code> is the display identity the reader sees and is not what SPF validates. <code>Return-Path</code> (the envelope sender) is the address SPF checks against the sending IP. When the two domains differ, it can be legitimate (some bulk senders use a separate bounce domain) but it is also the classic spoofing tell, so the mismatch is worth confirming against a known relay.
2
Received hops. Each relay that handled the message prepends a <code>Received</code> header, so the chain reads newest-first: the top-most Received is the final receiving server, and the bottom-most is closest to the origin. Reading the chain from the top down traces the path back toward where the message actually entered the mail system.
3
Authentication-Results: spf=. <code>spf=pass</code> means the sending IP is authorized by the Return-Path domain's SPF record. <code>spf=fail</code> or <code>spf=softfail</code> means it is not, which is a suspicion signal. An inconclusive result (no SPF record, or <code>none</code>) means the check could not reach a verdict.
4
Authentication-Results: dkim=. <code>dkim=pass</code> means the cryptographic signature validated, proving the message was signed by the holder of the signing domain's key and was not modified in transit. <code>dkim=fail</code> means the signature did not validate, which points to tampering or a key mismatch.
5
Authentication-Results: dmarc= and alignment. DMARC is the meta-signal. <code>dmarc=pass</code> means SPF or DKIM passed and aligned with the From domain; <code>dmarc=fail</code> means alignment broke regardless of what the individual checks said. Alignment is the key idea: the DKIM signing domain (the <code>d=</code> tag) or the SPF domain has to match the From domain for DMARC to be satisfied. Mail can pass SPF and DKIM and still fail DMARC if neither aligns.

Common pitfalls

Trusting the From line. The visible From is the easiest field to forge and the one SPF never checks. A convincing From proves nothing on its own; the Authentication-Results verdict does.
Reading a raw SPF or DKIM pass as "this is safe." A message can pass SPF and DKIM for some other domain and still be spoofing yours. What matters is whether the passing identifier aligns with the From domain, which is precisely what DMARC measures.
Reading the Received chain backwards. The hops are newest-first, so the top Received is the last relay and the bottom is nearest the origin. Read it top-down to trace the path back to the source.
Forgetting the receiver writes Authentication-Results. A message can carry its own forged Authentication-Results header lower down; the one that counts is the top-most, written by your receiving server. Trust the receiver's verdict, not a header the sender supplied.