Email Header Analyzer
Paste raw headers to see the delivery path, hop delays and SPF/DKIM/DMARC results.
Ham başlıkları yapıştırın
Gmail: ⋮ → Orijinali göster · Outlook: Dosya → Özellikler → İnternet başlıkları · Apple Mail: Görünüm → Mesaj → Tüm Başlıklar
What is Email Header Analyzer?
The Email Header Analyzer reconstructs the delivery path from raw headers: it puts every Received hop back in chronological order, computes the delay between hops and marks which ones were carried over TLS.
The authentication results recorded by the receiving server (SPF, DKIM, DMARC, ARC, iprev) are parsed, along with whether the From and Return-Path domains align and the first public IP where the message entered the internet — one click sends that IP to a blacklist or geolocation lookup.
Analysis runs entirely in your browser. Headers contain recipient addresses, subject lines and internal hostnames, so this is deliberate: nothing leaves your device, reaches a server, or gets logged.
Frequently Asked Questions
11 questionsAre the headers I paste sent to a server?
No. There is no API behind this tool — parsing runs entirely in your browser. Headers contain recipient addresses, subject lines and internal hostnames, so this is deliberate: nothing leaves your device and nothing is logged.
Where do I get raw headers?
Gmail: open the message → ⋮ → "Show original". Outlook desktop: File → Properties → Internet headers. Outlook.com: ⋯ → View → View message source. Apple Mail: View → Message → All Headers. Thunderbird: Ctrl+U.
Why is the hop order reversed?
Each server prepends its own Received header, so the topmost line in the raw text is the last step. This tool reverses that — hop 1 is the first machine that handled the message, so you read it in real chronological order.
One hop shows a long delay — why?
Three usual causes: greylisting (the receiver deliberately rejects the first attempt and the sender retries minutes later), queue backlog, and antivirus/spam scanning. A single delay over five minutes is usually greylisting and is normal.
Can I trust the Authentication-Results line?
Only the one added by your own receiving server — normally the topmost. An attacker can embed fake Authentication-Results headers in the message body, so lines further down are not evidence.
Is a From/Return-Path mismatch proof of spoofing?
No, not on its own. Marketing platforms, newsletters and ticketing systems set Return-Path to their own domain routinely. In that case DMARC alignment must come from DKIM — if DKIM doesn't align either, then the message really is suspicious.
How do I tell whether a message is spoofed?
Don't rely on a single signal. The strongest is a dmarc=fail in the Authentication-Results line your own receiving server added — it means the From domain couldn't be verified. Add a Reply-To mismatch and an unfamiliar originating IP and the case gets strong.
Can I trust the lower Received lines?
No. An attacker can prepend as many fake Received headers as they like; only the top lines added by your own infrastructure are trustworthy. Below the first line your server added, it's a claim, not evidence.
Where do X-Spam-Status and similar headers come from?
Filtering software on the receiving side — SpamAssassin, Rspamd, Microsoft Exchange Online Protection. They aren't standardised: each system names them differently and their scoring scales aren't comparable.
Why do the same message's headers differ per recipient?
Every server adds its own Received line and its own authentication result. The same message to two recipients takes different paths and ends up with different headers — which is why you should ask the affected user for their own copy when diagnosing.
What do ARC headers mean?
ARC (Authenticated Received Chain) lets a mailing list or forwarder carry the original authentication result forward after modifying a message. When SPF and DKIM break in transit, a receiver can look at the ARC chain to see the message verified on first entry.