Gmail
Open the message, click the ⋮ menu in the top-right of the message, and choose Show original. Copy everything shown (or use “Copy to clipboard”).
EMAIL YOUR DEVICE
Paste the raw headers of any email to see SPF, DKIM, DMARC and ARC authentication results, the full delivery path with per-hop delays, and common spoofing red flags. Headers are analysed entirely on your device — nothing is uploaded or stored.
Every email carries a hidden block of headers recording who sent it, which servers relayed it, how long each hop took, and whether it passed the SPF, DKIM and DMARC authentication checks. Reading them is the fastest way to investigate a suspicious message, trace a delivery delay, or debug why mail lands in spam.
This tool parses the raw headers for you: authentication verdicts up top, then the message summary, the receiving server's detailed results, DMARC alignment, and the complete relay path in chronological order.
Open the message, click the ⋮ menu in the top-right of the message, and choose Show original. Copy everything shown (or use “Copy to clipboard”).
Open the message in its own window, then File → Properties. Copy the contents of the Internet headers box.
Open the message, click ⋯ → View → View message source (or “View message details”), and copy the text.
Open the message, then View → Message → All Headers (⇧⌘H), select the header text and copy it.
Checks that the sending server's IP is authorised by the envelope sender's domain. A pass on its own is not enough — the envelope domain must also align with the visible From domain for DMARC.
A cryptographic signature added by the sending system. d= shows the signing domain and s= the selector. A message can carry several signatures; any aligned pass helps DMARC.
Passes when SPF or DKIM passes and that domain aligns with the From address. The policy in brackets (p=none / quarantine / reject) is what the From domain asks receivers to do on failure.
Authenticated Received Chain preserves earlier authentication results when a message is forwarded (mailing lists, distribution groups), letting the final receiver trust results that forwarding would otherwise break.
Each relay adds a Received header on top, so the bottom one is the origin. The delay column shows the wall-clock gap between hops — large gaps reveal exactly where a message sat in a queue.
Exchange Online's composite authentication verdict. It can fail even when SPF and DKIM pass if the message looks spoofed, and the reason= code explains why.
Headers are parsed in your browser with no network requests: the tool unfolds wrapped lines, reads the receiving server's Authentication-Results, Received-SPF and DKIM-Signature headers, reconstructs the relay path from the Received chain, and derives DMARC alignment using relaxed (parent-domain) matching.
Trust note: only the headers added by your own receiving server are trustworthy — anything below them can be forged by a sender. Authentication verdicts shown here are read from the message; this tool does not re-verify DKIM signatures cryptographically.
Yes. Analysis runs entirely on your device — the headers are never uploaded, stored, or sent to any server, and leave no trace once you close the page.
SPF checks the envelope sender, which often differs from the visible From address (bulk mailers, forwarding). DMARC additionally requires the passing domain to align with the From domain.
Each server stamps its own clock, and clocks drift. Small negative gaps are shown as 0s; hops without a parseable date show no delay.
The earliest public IP address in the relay chain — usually the real sending server. Internal 10.x / 192.168.x addresses before it are the sender's private infrastructure.
Forwarding changes the sending server (breaking SPF) and can modify the message (breaking DKIM). ARC headers, when present, carry the original verdicts across the forward.
The topmost one, added by the server that received the message for you. Lower ones were added earlier in the path — or could be forged by the sender.