Reading mail headers: the road a message takes
A message arrives in a mail app as sender, subject and content — but the part that tells the story stands above it, hidden: the headers. Every server that touched the message wrote a Received line, the receiving server that tested SPF, DKIM and DMARC wrote its verdict in Authentication-Results, and Return-Path and From show which envelope and which shown name — together those lines form a travel log.
The travel log is self-reported, and that is both its limit and its value. Because every server writes its own line on its own clock, a chain is no verdict: times drift and sometimes fall away. That is exactly why the patterns that do show in the log weigh so heavily: a From domain appearing in none of the hops, or two receivers judging one message differently — you see those without trusting a single line.
Start at the mail header analyzer: paste the raw headers of a message and the timeline appears in travel direction — from the first sending server to the receiver that you are, per hop the timestamp that server noted for itself, the difference with the previous hop and the verdict of every receiver. The mail does not leave your browser: parsing, timeline and findings happen here.
1. The lines that carry the story
The Received line is the itinerary of the travel log: `from` names the server that delivered the message, `by` the server that accepted it, `with` says what kind of connection it was — SMTP, ESMTPS with TLS — and the date is the moment the receiver noted for itself. The lines stand reversed: the topmost Received is the last hop, so a travel log is read from bottom to top.
Besides the route stands the question of who the message claims to be: From is the shown name, Return-Path is the envelope on which bounces return — and if those two live on different domains, that is not automatically a lie, but it is a pattern you must weigh. In the headers of your own mail you find it back within a minute; the rules for those domains stand in SPF, DKIM and DMARC explained.
2. Verdicts per receiver, not per message
Authentication-Results is not one verdict but a row of verdicts: every receiving server that tested wrote its own line with its own SPF, DKIM and DMARC outcome. That is what makes forwarding visible: the first receiver passes SPF because the message really came from the sender’s server, and the receiver after the forwarding server fails SPF because the message now comes from the forwarder — normal, and to be read as a chain, not as a contradiction. The DKIM signature usually survives forwarding; SPF usually does not.
If two receivers judge the same method differently, that is a finding but no conviction: policies differ, and the last receiver in the chain — the one who saw your mail — weighs heaviest for your judgement. The analyzer lays both verdicts side by side per method on the timeline, so you see where the judgement switches without comparing lines yourself.
3. What you can see in the log
Suspicious patterns have their own signature: the From domain appears in none of the hops and in none of the verdicts; the envelope comes from another domain than the shown sender; a receiver who should have tested wrote no Authentication-Results; or two Received lines that apparently arrive back in time — mail-server clocks drift, so a negative time difference says more about the clocks than about the message.
And there is deeper: the DKIM verification recomputes the signature of the message itself in your browser, the SPF recomputation tests whether a sending IP stood on the SPF of the From domain at all, and the mail security shows the DMARC policy from the sender’s side — the headers show what happened, those tools show what the rules are.
4. Read your own mail without sending anything
The headers of a received message carry more than the sender: your own address, addresses of others on the line, sometimes internal hostnames and ids of the systems that relayed. That is why this analysis runs in your browser: the paste, the timeline and the findings happen there, and not one byte goes to our server. If you export the analysis as JSON, you are the one who decides where that file goes.
For large questions there is a larger view: at the DMARC report reader lies the aggregate of many messages from your domain, at the mail security the record picture of the domain itself — and for one message that may not be right, the travel log above, read hop by hop.