DNSVerdictAll toolsGuidesHow it works

How to read email headers: Received, SPF, DKIM, DMARC

Published · Updated

Open the message’s full headers (in most clients, a menu item called “Show original”, “View message details” or “View raw message”), then read the Received: lines from the bottom up to follow the path and find delays, and read the topmost Authentication-Results: line to see what your own mail server concluded about SPF, DKIM and DMARC. Paste the text into the email header analyzer, which runs in your browser, if you want the hops and results laid out in a table.

Get the full headers

ClientWhere to find themProvider documentation
Gmail (web)Open the message, More menu beside Reply, Show originalGmail Help
Outlook on the web / new OutlookMore actions at the top of the message, then View > View message detailsMicrosoft Support
Outlook classic (Windows)Double-click the message, File > Properties, “Internet headers” boxsame Microsoft page
Apple Mail (Mac)View > Message > All HeadersApple Support
Yahoo MailOpen the message, More options, View Raw MessageYahoo Help
ThunderbirdView > Message Source or Ctrl+U (Cmd+U on Mac)Mozilla Support, keyboard shortcuts

Two notes. Apple’s page covers the All Headers view, not the raw source. In Thunderbird, menu names differ slightly between versions; look for the option to view the message source. Copy the whole block, from the first Received: to the blank line before the body. Partial headers hide the hops that matter.

Read the Received chain bottom-up

Every server that handles the message adds a Received: line at the top. The oldest hop is therefore the bottom line, and the line closest to your mailbox is the top one.

Received: from mx.example.net (mx.example.net [203.0.113.10])
        by mail.yourdomain.example with ESMTPS; Tue, 20 Oct 2026 09:14:12 +0000
Received: from app01.sender.example (app01.sender.example [198.51.100.7])
        by mx.example.net with ESMTP; Tue, 20 Oct 2026 09:14:11 +0000
Received: from [10.0.0.5] (unknown [192.0.2.44])
        by app01.sender.example with ESMTPSA; Tue, 20 Oct 2026 08:41:03 +0000

Read from the bottom: the client at 192.0.2.44 submitted at 08:41:03, app01 handed it on at 09:14:11, delivery happened one second later. The 33-minute gap sits between the first and second hop, so the delay was inside app01.sender.example (a queue, greylisting retry or rate limit), not on your side. Compare timestamps hop by hop and check the time zone offsets; a negative gap usually means a server clock is wrong.

Authentication-Results: which one to trust

RFC 8601 defines Authentication-Results:. Its first token is the authserv-id, the name of the server that did the checks, followed by method results:

Authentication-Results: mail.yourdomain.example;
    spf=pass smtp.mailfrom=bounce.sender.example;
    dkim=pass header.d=sender.example header.s=s1;
    dmarc=fail (p=reject) header.from=yourdomain.example

Anyone can add a header line with that name, including the sender. RFC 8601 §5 requires a receiving server to delete such lines that claim its own authserv-id when they arrive from outside its trust boundary. So trust the line whose authserv-id is your own receiving server or provider, normally the topmost, because it was added last. Treat lines further down, from earlier hops, as claims by other parties. Ignore any “X-” header that says spam=no or verified=true unless your own provider is known to add it.

Result values

MethodValues (spf and dkim: RFC 8601 §2.7; dmarc: RFC 7489)What it means for you
spfpassThe sending IP is listed for the envelope domain
fail / softfailIP not authorized / weakly not authorized (-all vs ~all)
neutral, noneDomain makes no claim / no SPF record
temperror, permerrorDNS glitch, retry may work / record is broken, see SPF too many lookups
dkimpass, failSignature verified / did not verify (body or headers changed, key missing)
none, neutral, policyNot signed / signature present but not accepted for a local-policy reason
temperror, permerrorDNS glitch / malformed signature or key
dmarcpass, fail, noneAt least one aligned pass / none aligned / no DMARC record

dmarc=fail with spf=pass and dkim=pass is an alignment problem, not an authentication problem. See DMARC fails although SPF and DKIM pass. To check the record the receiver evaluated, use the DMARC checker and the SPF checker.

ARC: when forwarding breaks the original result

Mailing lists and forwarders often break SPF (the IP changes) and DKIM (the body changes). Authenticated Received Chain, RFC 8617, lets each intermediary record what it saw. Three headers appear per hop, all with the same i= instance number (1 to 50): ARC-Authentication-Results (the results at that hop), ARC-Message-Signature (a DKIM-style signature of the message) and ARC-Seal (a signature over the chain, with cv=). The cv= value is none for the first hop, then pass or fail. ARC does not make a message legitimate; it lets the final receiver decide whether it trusts the sealing domains. Microsoft documents ARC as the way to keep DKIM-based trust through an intermediary that modifies mail (the intermediary is configured as a trusted ARC sealer). RFC 8617 §5.2 says a chain that fails validation is treated as if there were no chain.

Common red flags

None of these proves fraud alone. Newsletter platforms routinely show a different envelope domain than the From address.

FAQ

Can headers be forged? Everything below your own server’s Received: and Authentication-Results: lines can be written by the sender. Only the lines your server added are evidence.

Why does my message show two DKIM results? A message can carry several signatures, for example one from your domain and one from the sending platform. DMARC passes if one aligned signature verifies.

Does spf=pass mean the email is safe? No. It means the IP was authorized for the envelope domain, which can be a domain the attacker owns.

Sources

Tools used

Email Header AnalyzerSPF Record CheckerDMARC Record Checker