Email Header Analyzer
Analyze email headers and trace delivery path.
Overview
Every mail server that handles a message prepends a Received header. Read in
order, those headers are the delivery path: which host handed the message to
which, and when. Read alongside the authentication results, they tell you
whether the message is actually from where it claims.
This tool unfolds the headers, reconstructs the path as a numbered hop list with per-hop delays, and surfaces the authentication headers separately so you do not have to find them in the noise.
How to use
- In your mail client, open the original or raw source of the message. In Gmail this is Show original; in Outlook, Properties → Internet headers; in Apple Mail, View → Message → Raw Source.
- Paste everything from the top of the message down to the first blank line. The body is not needed.
- Read the hop list top to bottom — hop 1 is the origin.
- Read the authentication results below it.
Reading the hop list
Each row shows the sending host (from), the receiving host (by) and the
delay since the previous hop. A normal delivery is two to five hops completing
in a few seconds.
The direction matters. Relays prepend rather than append, so the raw headers run newest first; the list here is reversed so it reads in the direction the message travelled. When you compare against the raw source, remember they are upside down relative to each other.
Delays come from the date in each Received header, and those timestamps are
written by different machines with independently set clocks. A one- or
two-second discrepancy, including a negative one, is skew and not evidence of
anything. A gap of minutes or hours is real, and almost always means the
receiving server queued the message — greylisting, which deliberately defers a
first-time sender, is the single most common cause.
Reading the authentication results
Four headers matter, and they answer different questions:
Received-SPF— was the connecting IP authorised to send for the envelope sender’s domain? SPF checks the envelope (MAIL FROM), which is not theFrom:header your recipient sees. A message can pass SPF and still display a forged sender.DKIM-Signature— a cryptographic signature over selected headers and the body, verifiable against a public key in the signing domain’s DNS.d=is the signing domain ands=is the selector, which together locate the key at<selector>._domainkey.<domain>.Authentication-Results— the receiving server’s own verdict, combining SPF, DKIM and DMARC. This is the line to read first, because it is written by the one machine in the chain you have a reason to trust.ARC-Authentication-Results— the verdict recorded by an intermediary before it modified the message. Mailing lists rewrite headers and break DKIM by design, and ARC exists so the original result survives that.
DMARC is the one that determines what recipients actually do. It requires SPF
or DKIM to pass and to be aligned — the passing domain must match the domain
in the visible From: header. Alignment is why a message can show spf=pass
and dkim=pass and still fail DMARC: both passed, for the wrong domain.
Examples
- “Our mail goes to spam.” Read
Authentication-Resultson a message you sent to yourself at another provider. If DKIM passes but DMARC fails, the problem is alignment, not signing. - A convincing phishing message. Compare the
fromon hop 1 against the domain in the visibleFrom:header. Forged display names are trivial; a forged first hop that matches the claimed domain’s real infrastructure is not. - Delivery that takes twenty minutes. Find the hop with the delay. If it is the recipient’s first inbound server, greylisting is the likely answer and it resolves itself on retry.
- Mail that stopped arriving after a DNS change. Check SPF in the results. Two SPF records on one domain, or a record that exceeds the ten-lookup limit, both produce a permanent failure that looks like a mystery.
- A mailing list breaking your signature. Look for ARC headers. Their presence tells you an intermediary modified the message and recorded the earlier verdict.
Notes
Continuation lines are unfolded before parsing. Long headers are wrapped across multiple lines with leading whitespace, and a parser that reads line by line without joining them will truncate exactly the headers that matter most.
The from and by values are read only from the start of a clause. A
Received header with no from clause often still contains the string
envelope-from inside a comment, and treating that as the connecting host
would display an attacker-supplied address as the origin of the message —
precisely the fact you came here to check.
Everything here describes what the headers say. Headers written before the first machine you control can be fabricated in full, so the chain is evidence about your own infrastructure and a claim about everything upstream.
For inspecting a saved message rather than its headers, use the EML viewer.