Email header analyzer
Paste a message’s headers to see the route it took and how long each hop took, what the receiving server concluded about SPF, DKIM and DMARC, and what spam filters decided. Everything is read in your browser.
By using these tools you accept the Terms and the Privacy page.
How the email header analyzer works
The email header analyzer reads the headers of a received message and explains them: where it came from, which servers passed it on, how long that took, and what each receiving server and spam filter concluded. It is for anyone who needs to know why a message landed in junk, took an hour to arrive or failed DMARC.
What it reads
- Received headers: read bottom-up into a route, with each server’s name, IP address, protocol and TLS version where it is written, the time it stamped and the delay since the previous hop. Slow hops, clock skew, private addresses and hops without TLS are flagged, and the hop where the message reached your provider is marked as the sending IP.
- Authentication-Results (RFC 8601): every SPF, DKIM, DMARC, ARC and reverse-DNS result per receiving server, top first, including Microsoft’s headers that leave out the server name and its compauth reason codes.
- ARC (RFC 8617): the ARC sets, who sealed each one and whether the chain is complete, with cv=none on the first seal and cv=pass after it.
- Spam filter verdicts: Microsoft’s SFV, CAT, SCL, BCL, SRV and SFTY values and SpamAssassin’s status, score and rules, in plain words from the vendors’ own documentation. Other vendors’ headers are shown as written.
- Bulk-sender rules: List-Unsubscribe with an HTTPS link, List-Unsubscribe-Post for one-click unsubscribe (RFC 8058), whether DKIM signs both, Feedback-ID, Precedence, and the Message-ID and Date.
Alignment and DKIM
DMARC only counts SPF and DKIM results for domains aligned with the From address. The analyzer compares the From domain with the envelope sender (Return-Path) and every DKIM d= domain, using the strict or relaxed mode and the organizational domain from the From domain’s DMARC record, looked up when you analyze.
When you paste the full message or drop an .eml file, every DKIM signature is verified in your browser (RFC 6376 with RFC 8301 and RFC 8463), with the same verifier the email test uses. With headers only, the receiver’s recorded result is shown instead, and the analyzer says that it couldn’t verify.
Built for big and hostile pastes
Header fields are written by senders and relays, so nothing in them is trusted. Every reader goes through each character once, so even a 10 MB message with thousands of Received lines, huge folded headers or endless nested comments is read in a second or two, with an “Analyzing…” line while it runs. Only the top 100 Received headers are read, as RFC 5321 suggests for loop detection, and everything is shown as text, never as HTML.
What it can’t see
Headers record what each server decided, not why a provider’s machine learning or the recipient’s own actions put a message in junk. Lower headers can be made up by the sender, so trust the ones your own provider added. To test a real delivery, send a message to the email test; for the sending IP, run the blacklist check and reverse DNS.
Updated · Maintained by Liviu Tanase
Questions
How do I find the full headers of an email?
In Gmail on a computer, open the message, click More next to Reply, choose Show original, then Copy to clipboard. In new Outlook and Outlook on the web, open the message, choose More actions, then View, then View message details. In classic Outlook for Windows, open the message and choose File, then Properties: the headers are in the Internet headers box. In Apple Mail, choose View, then Message, then All Headers, or Raw Source for the whole message. In Yahoo Mail, open the message, click More, then View raw message.
What do SPF, DKIM and DMARC results mean?
SPF pass means the sending IP is allowed by the envelope domain’s SPF record; softfail and fail mean it isn’t. DKIM pass means a signature verified with the key the signing domain (d=) publishes. DMARC pass means SPF or DKIM passed for a domain aligned with the From address, the same domain or, by default, the same organizational domain. temperror is a temporary DNS problem and permerror a broken record. Check the records themselves with the SPF, DKIM and DMARC tools.
Why did my email go to spam?
Look at the spam filter section first. Microsoft writes its decision into X-Forefront-Antispam-Report: SFV:SPM means spam filtering marked it as spam, CAT names the policy that applied (SPM spam, PHSH phishing, BULK bulk), and BCL rates bulk senders from 0 to 9, with 7 as the default threshold. SpamAssassin writes X-Spam-Status: Yes with its score and the rules that fired. A DMARC failure is the other common cause. Reputation and content weigh in too: score the content with the spam checker and send a real message to the email test.
What do the delays between hops mean?
Each server stamps the time it received the message, so the gap between two Received headers is how long the earlier server held it. Seconds are normal. Five to thirty minutes at the receiving side usually means greylisting: the server refused the first attempt on purpose and accepted the retry. Hours mean a queue, a deferral or an unreachable server. A hop that is earlier than the one before it means one of the clocks is wrong.
Can it verify DKIM signatures?
Yes, when you paste the whole message source or drop the .eml file: the signatures are checked in your browser against the keys the signing domains publish now. With headers only it can’t, because each signature covers the body. Copying from a browser can change spaces or line endings and break a signature that passed at delivery, so a dropped .eml file is the most reliable.
Where do my headers go?
Nowhere. They are parsed in JavaScript on this page, never put in the URL and never saved. The page looks up the From domain’s DMARC record and, for a full message, the DKIM keys, over DNS-over-HTTPS with Cloudflare or Google, like the other DNS tools here; only those domain names leave your browser.