sitekits.dev
press ⌘K to switch tools
EMAIL AUTH

Email Header Analyzer

Analyze email headers and trace delivery path.

local
message-header
§01 ABOUT THIS TOOL

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

  1. 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.
  2. Paste everything from the top of the message down to the first blank line. The body is not needed.
  3. Read the hop list top to bottom — hop 1 is the origin.
  4. 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 the From: 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 and s= 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-Results on 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 from on hop 1 against the domain in the visible From: 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.

FAQ
Are the headers I paste uploaded anywhere?
No. The headers are unfolded and parsed in the page; there is no network request. That matters here because full headers contain recipient addresses, internal hostnames and message ids.
Why is the hop list in the opposite order to the raw headers?
Because each relay prepends its own Received line, so the raw order is newest first. The list is reversed so hop 1 is the original sender and the last hop is your mailbox — the direction the message actually travelled.
Can I trust the earliest hops?
Only from the first server you control, inwards. Anything before that was written by machines you do not operate and can be fabricated wholesale. Read the chain from the bottom up and stop trusting it at the boundary of your own infrastructure.
A hop shows a dash instead of a sending host. Is that a problem?
No. Internal relays often record only a `by` clause with no `from`, which is normal for local delivery, LMTP handoff and sieve filtering. A dash means the header genuinely had no from clause, not that parsing failed.
What does a long delay on one hop mean?
Usually greylisting or a queue at the receiving server. Delays are computed from the timestamps in consecutive Received headers, and those clocks belong to different machines, so a small negative or zero delay is clock skew rather than time travel.