Email Header Analyzer
Paste raw email headers to see the delivery path hop by hop with delays, SPF, DKIM and DMARC results and spoofing warnings.
Analyze email headers
Runs in your browser; the headers never leave this page.
What the Email Header Analyzer does
Email Header Analyzer takes the raw headers of a message and turns them into something you can read: who sent it and to whom, the subject, date and Message-ID, then the full delivery path. Every Received header is a hop, and the tool lists them in the order the message travelled, from the first server to the last, with the time each hop took, so a message that arrived two hours late shows exactly which server held it.
It also reads the Authentication-Results header that the receiving server added and shows the SPF, DKIM and DMARC verdicts with the domain each was checked against, pulls the selector and signing domain out of the DKIM-Signature, and compares the Return-Path with the From address. A mismatch is normal for newsletters and CRMs, but on a message that claims to be from a colleague it is the signature of a spoof.
Everything happens in your browser. The headers are never sent to our server, which matters because they contain addresses and internal host names.
Step by step
- 01Open the message and choose "Show original" (Gmail), "View message source" (Outlook) or "View raw message" (Yahoo, Apple Mail with Option-Command-U).
- 02Copy everything from the first header line down to the blank line before the body, and paste it here. The whole source is fine too; the body is ignored.
- 03Read the summary and the authentication verdicts first, then the hop list for delays.
- 04Check the warnings: a Return-Path on another domain, a failed DKIM or a missing DMARC pass are what phishing looks like.
Common questions
Each server adds its Received header to the top of the message, so in the raw source the newest hop comes first. The tool reverses them so you read the path in travel order, from the sender's server to your mailbox, which is the natural way to look for where a delay happened.
The server named in that hop held the message for that long before passing it on. Common causes are greylisting on the receiving side (a deliberate delay of a few minutes for unknown senders), a queue backlog on a busy relay, or a spam scanner. A delay at the first hop usually means the sender's own outgoing server was slow.
Not necessarily. SPF is checked against the Return-Path domain, so a legitimate message sent through a tool that uses its own bounce address can fail SPF while DKIM passes and DMARC is satisfied. If DKIM also fails and DMARC says fail, treat the message as not from who it claims.
Yes. The parsing runs entirely in your browser; the page makes no request with the text. You can confirm that by opening the network tab of the browser's developer tools while you paste.
Keep checking
SPF Checker
Validate a domain's SPF record: mechanisms, the include tree, the 10 DNS lookup limit, +all and syntax mistakes.
Free toolDKIM Checker
Find and validate a domain's DKIM record by selector: tags, key type and size, test mode, or try the common selectors.
Free toolDMARC Checker
Validate a domain's DMARC record: policy, subdomain policy, pct, reporting addresses, alignment and common mistakes.
Free toolBlacklist Checker
Check whether an IP or mail server is listed on Spamhaus, SpamCop, Barracuda, SORBS and ten more DNS blacklists.
Free toolReverse DNS Lookup
Find the PTR host name of an IPv4 or IPv6 address and check that it resolves back to the same address.
Want these fixes done for you?
Our team runs the audit, makes the changes and reports the result.