Email header analyzer

Each Received header logs one hop, the handoff from one mail server to the next. Read them bottom-up: the lowest one is the first server that touched the message, the top one is the server that handed it to you. The line records which host sent it (from), which host received it (by), the protocol used (with), and a timestamp. A long gap between two timestamps points to a queue delay at that hop.

The receiving server writes this header to record what its own checks found. It opens with an authserv-id (the server's name, such as mx.google.com), then lists each method and its result: spf=pass, dkim=pass, dmarc=pass. Each result names the identity it judged, written as ptype.property: smtp.mailfrom for SPF, header.d for the DKIM signing domain, header.from for DMARC. This is the only place the SPF, DKIM, and DMARC verdict actually lives. The analyzer quotes it. It does not re-run the checks.

The sender adds this header and signs part of the message with a private key. The receiver verifies it against a public key published in DNS. The tags that matter: d= is the signing domain, s= is the selector (so the public key is found at s._domainkey.d), h= lists which headers the signature covers, bh= is the body hash, and b= is the signature itself. The analyzer shows you the tags. Verifying the signature needs a DNS lookup, which it does not do.

A human-readable note some receivers add next to the SPF result, naming the connecting IP (client-ip=) and the envelope sender it was checked against. Treat the spf= value inside Authentication-Results as the authoritative result. Received-SPF is a convenience copy.

The Authenticated Received Chain lets a forwarder record the authentication result it saw, so a later receiver can still trust mail that broke SPF or DKIM in transit. Each link carries an instance number i= (1 for the first hop, counting up). The ARC-Seal reports a chain-validity value cv=: none means this is the first link, pass means the chain so far validated, fail means it did not. The analyzer reports the cv= each seal claims. It does not validate the seals itself. Read more on DMARC alignment.

Four addresses that usually agree. From is who the message says it is from, and the identity DMARC judges. Return-Path is the envelope sender, where bounces go, and the identity SPF judges. Reply-To is where a reply is sent. Sender names who actually submitted the message when that differs from From. When these point at unrelated domains, it can be a sign of spoofing. The phishing triage card above compares them for you. Read more on DMARC alignment.

A globally unique identifier the sending server stamps on the message. Its domain part usually matches the sending system, which is a quick sanity check, and it is the value support teams ask for when they trace a single message through the logs.

The time the message was composed, as the sender's system reported it. Compare it with the timestamps in the Received headers. A Date far from the first hop's time can signal a misconfigured clock or a replayed message.

Microsoft 365 stamps these on inbound mail to record what its filter observed: the connecting IP and country, the spam and bulk confidence levels, the filter verdict, and any safety tips. They are the first thing to read when legitimate mail lands in Junk on Microsoft 365. The codes are decoded in the next section and in the Microsoft 365 card above.

Does this tool upload my headers?

No. The analyzer does not upload your headers. Parsing runs entirely in your browser. You can open DevTools and watch the Network tab while you click Analyze; no request carries your header text. The page itself loads the standard site scripts (analytics, chat) before you paste anything; those scripts never see your header content.

Does it independently verify SPF, DKIM, DMARC, and ARC?

No. The tool reports what the Authentication-Results header says the receiving server verified. To re-verify a DKIM signature or check a published DMARC policy we would need DNS lookups, which would defeat the privacy guarantee. Verdicts are labelled with their provenance: per Authentication-Results, signature present (unverified), or unknown.

How do I view headers in Gmail?

Open the message, click the three-dot menu in the top right of the message, and choose Show original. Gmail opens a new tab with the full source. Copy everything above the first blank line, or click Download Original to save the .eml file.

How do I view headers in Outlook?

Outlook on the web: open the message, click the three-dot menu, choose View, then View message source. Classic Outlook for Windows: open the message in its own window, choose File > Properties, and copy the Internet headers box. New Outlook and Outlook for Mac: open the message, click the three-dot menu, and choose View source.

How do I view headers in Apple Mail?

Open the message, then in the menu bar choose View > Message > All Headers (or press Shift+Cmd+H). The full headers appear above the body.

How do I view headers in Thunderbird?

Open the message, then in the menu bar choose View > Headers > All. You can also save the message as .eml from File > Save As, and drop the .eml on the analyzer.

What does X-Forefront-Antispam-Report mean?

It is a Microsoft 365 header that records what the inbound mail-flow filter observed. The analyzer decodes the codes it carries: CIP (the connecting IP), CTRY (its country), SCL (spam confidence level, -1 to 9), BCL (bulk confidence level 0-9), SFV (the spam filter verdict), SFTY (phishing safety tip), IPV (sender IP allow-list status), and the override flags SOR / SOT / SOI. Each row in the M365 section shows the raw value and a plain-English explanation.

Is it safe to paste a sensitive production header?

Parsing happens locally, so the header text itself is not sent anywhere by the analyzer. If your organisation forbids pasting any production data into a third-party page, follow that policy: it is the safer rule, and you can still verify the privacy claim by watching DevTools while you click Analyze.

Can you tell if an email is spoofed from the header?

Often, though not always with certainty. The header shows tells, not proof. The strongest signal is a DMARC fail in the Authentication-Results header, which means the From domain did not authenticate. The phishing triage card adds more: a From display name that names a brand its address does not match, or a Reply-To and Return-Path on unrelated domains. Any one of these is worth a second look. None of them on its own proves the message is malicious, and a well-built phishing message can still pass the basic checks, so treat the header as one input, not a final verdict. DMARC passes but spoofing continues.

Why does my legitimate email show DMARC=fail?

Almost always because of alignment, not because the message is fake. DMARC passes only when SPF or DKIM authenticates a domain that matches the From domain. When you send through a third-party service (a marketing platform, a help desk, a payroll tool) and have not set up your own domain inside it, SPF passes for the provider's domain and DKIM signs with the provider's domain, so neither aligns with your From. A forwarder breaks alignment the same way. Read the Authentication-Results header and the phishing triage card here to see which identity failed to align, then fix it inside the sending service. ESP mail fails DMARC: per-provider fixes.

Does a DMARC pass mean the email is safe?

No. A DMARC pass tells you one thing: the message genuinely came from the domain in the From address, and was not spoofed. It says nothing about whether that domain is trustworthy or whether the content is safe. An attacker who controls a domain, or who registered a look-alike domain, can send mail that passes DMARC for that domain. Authentication answers "is this really from this domain?", not "should I trust this domain?". Use the pass as a starting point, then judge the sender and the content on their own.