Email Header Analyzer

How to use this email header analyzer

1. Open the original email and find "Show original" or "View source" in your email client.
2. Copy the full raw header block and paste it here.
3. See the SPF/DKIM/DMARC results and delivery hop chain instantly.

Does this send my email anywhere?

No — this parses the text entirely in your browser using pattern matching. Nothing is uploaded, and this tool doesn't even make a network request.

What SPF, DKIM, and DMARC actually check

These three mechanisms work together but check different things. SPF (Sender Policy Framework) verifies that the server which sent the message is actually listed as authorized to send mail for that domain, by checking a DNS record — it protects against the sending IP being spoofed, but it applies to the invisible "envelope from" address, not necessarily the "From" header a person actually reads. DKIM (DomainKeys Identified Mail) adds a cryptographic signature to the message, generated with a private key the sending domain controls, which lets the receiving server verify the message body and key headers weren't altered in transit — this is what actually protects content integrity. DMARC ties the two together: it's a policy, published in DNS by the domain owner, that tells receiving servers what to do when SPF or DKIM fails (quarantine, reject, or do nothing) and enables aggregate reporting back to the domain owner about who's sending mail claiming to be from them.

Reading the Received chain like a detective

Every mail server that touches a message prepends its own "Received" header at the top, so reading the chain from bottom to top reconstructs the message's actual path from the originating server to your inbox. This is useful for spotting inconsistencies — a message claiming to be from a well-known company but originating from an unrelated server or an unusual geographic hop is a warning sign. The important caveat is trust boundaries: headers added by servers before the message reached your own trusted infrastructure (your provider's own receiving server, typically the last hop added) can be forged by a sender, since anyone composing an email can write arbitrary text into headers before sending it. Only the hops added after the message entered a mail system you actually trust are reliable.

Why the "From" address alone proves nothing

One of the most common phishing techniques exploits the fact that email has two separate "from" concepts. The header From: address is what your email client displays, and it's just a text field the sender writes — nothing stops someone from typing any address they want there. The envelope-from (visible in headers as Return-Path, and what SPF actually checks) is set by the sending server during the SMTP conversation and is harder to fake convincingly, but the two don't have to match, and most email clients only ever show you the header From. A message can display "From: security@yourbank.com" while actually being sent through infrastructure with no connection to that bank at all — which is precisely why SPF, DKIM, and DMARC results matter more than the displayed sender name.

Common false positives worth understanding

A single SPF or DKIM failure doesn't automatically mean a message is malicious. Legitimate mail gets forwarded through mailing lists, corporate relay servers, or auto-forwarding rules that change the sending server without the original sender's knowledge — this routinely breaks SPF, since the message is now leaving a server the original domain never authorized, even though nothing suspicious happened. DKIM tends to survive simple forwarding better, since its signature covers the message content rather than the sending IP, but even DKIM can break if a forwarding service modifies the subject line or body (adding a footer, for instance). The most reliable single signal is usually the DMARC result, since it's specifically designed to account for how SPF and DKIM behave differently — but even that should be read alongside the actual Received chain and sender reputation, not in isolation.

Limitations of this tool

This analyzer works by pattern-matching the header text you paste — it reads the Authentication-Results line the receiving mail server already wrote (that's where the SPF/DKIM/DMARC verdicts come from), and reconstructs the Received chain from the header text itself. It does not perform its own DNS lookups or contact any mail server, by design, since that would require this tool to make a network request. That means its accuracy depends entirely on the receiving server having already done real authentication checks and written the results into the header — if you paste headers from a server that skipped that step, or headers that have been edited or truncated, this tool has no way to independently verify anything beyond what's written in the text you provided.