How do I analyze email headers to check SPF, DKIM and DMARC?

Every email carries a stack of headers that your mail client hides by default. They record who sent the message, which servers relayed it, and — most importantly for diagnostics — whether it passed authentication. Analyzing those headers is the fastest way to find out why a specific message did or did not authenticate, because you are reading the verdict the receiving server actually reached rather than guessing from DNS records.

Step 1: get the raw headers out of your mail client

The exact wording differs per client, but the action is the same: reveal the full original source.

• Gmail: open the message → three-dot menu → Show original. Copy the whole page, or use "Download Original" to save the .eml.
• Outlook (web): open the message → three-dot menu → View → View message source.
• Apple Mail: View → Message → Raw Source (or press Command-Shift-U).
• Thunderbird: View → Message Source (or Control-U).

Paste the entire block — including every Received and Authentication-Results line — into the email header analyzer. The whole .eml works too.

Step 2: read the SPF, DKIM and DMARC verdicts

The single most useful header is Authentication-Results, which the receiving server stamps with the outcome of each check:

Authentication-Results: mx.example.com;
  spf=pass smtp.mailfrom=sender.com;
  dkim=pass header.d=sender.com;
  dmarc=pass header.from=sender.com

The three checks answer different questions. SPF confirms the sending server is authorized for the envelope (Return-Path) domain. DKIM verifies a cryptographic signature, proving the message was not altered in transit and genuinely came from the signing domain. DMARC ties them together: it requires that an authenticated identifier aligns with the visible From domain, and publishes a policy — none, quarantine, or reject — telling receivers what to do when alignment fails. The analyzer surfaces the DMARC policy alongside the verdict, so you can see whether a failure would actually be enforced.

A subtlety worth knowing: a message can show raw spf=pass yet dmarc=fail if the SPF domain does not align with the From header, and a forwarded message can show spf=fail but still pass DMARC on aligned DKIM. Reading the headers — not just the DNS — is how you catch these alignment cases.

Step 3: read the Received hop chain

Below authentication, each server that handled the message stamps its own Received line on top, so reversing them traces the message from its origin down to your inbox. The chain reveals the original sending IP, any relays in between, and roughly how long each hop took. It is the fastest way to spot a forged origin, an unexpected relay, a sending IP in the wrong country, or a delay that explains a late delivery — context SPF, DKIM and DMARC alone do not give you. The analyzer reconstructs this chain in arrival order and highlights spam and header-quality red flags (a missing Message-ID, a Reply-To on a different domain, suspicious links).

What to do with the result

Once you spot a failing check, fix the underlying DNS rather than the headers. If DMARC failed, validate your live policy with the DMARC checker; if SPF failed on a lookup error, see how to fix an SPF permerror. The header analyzer reuses the same raw-email engine behind the full email deliverability tester, so for a fresh end-to-end benchmark of your own sending setup you can send a test message instead of analyzing one you already have. For the conceptual background on how the three checks differ, read SPF vs DKIM vs DMARC.