Tiny Online Tools
What the Received chain is
Every server that handles a message adds a Received: line at the top of the header block, so the stack reads newest first. Reversed, it is the route the message travelled. Each hop names the host it came from, the host that took it by, usually the peer IP address and the reverse-DNS name that address resolved to, the protocol it arrived over, and a timestamp. Subtracting consecutive timestamps gives the delay each hop added, which is how a message that took six minutes to arrive tells you where the six minutes went — almost always a queue or a greylisting retry.
Negative delays are normal, not a bug. Two relays whose clocks differ by a few seconds produce one, and so does a server stamping in local time with a wrong offset.
What this can and cannot tell you
This is the part most header tools are quiet about. Everything below the topmost Received: was written by a machine the recipient does not control. A forged chain looks exactly like a real one. Only the hops added by your own infrastructure — the ones at the top — and the Authentication-Results written by the final receiving server are evidence of anything.
And those authentication results are recordings, not checks. SPF, DKIM and DMARC verdicts shown here are read out of headers a receiving server already wrote. Verifying them independently would require DNS lookups — the sender's SPF record, the DKIM public key at the selector — and this tool makes no network requests at all. A DKIM-Signature header with no matching Authentication-Results proves only that the sender claimed to sign; it is shown as unverified for exactly that reason.
Alignment
DMARC passes when the domain SPF or DKIM authenticated matches the domain in the From: header. That comparison is shown explicitly, because a message can carry spf=pass and still be a forgery: the SPF pass may belong to a bounce domain that has nothing to do with the visible sender.
Nothing you paste is uploaded. The analysis runs in this tab and can be downloaded as JSON.