Email Header Analyzer

Paste the raw headers of a message to see the route it took, how long it spent at each hop, where it originated, and whether SPF, DKIM and DMARC passed.

Useful for two questions in particular: why a message took an hour to arrive, and whether the sender is who they claim to be. Everything is parsed here — no part of the message is sent anywhere else.

How it works

Every mail server that handles a message adds a Received header at the top of the block. The chain therefore reads backwards: the last Received in the file is the first hop, and the first one is the final delivery. This tool reverses them into chronological order and works out the gap between consecutive timestamps, which is what turns "the email was slow" into "it sat at this specific server for 47 minutes".

Treat those delays with a little scepticism. Each server writes its own clock, and a machine with drifting time can produce a negative delay or an impossible gap. A single strange interval in an otherwise sensible chain is usually a clock problem; a consistently large one at a particular hop is real, and typically means greylisting, queueing under load, or content scanning.

The authentication results are the part that decides whether to trust the sender. SPF checks that the connecting IP is permitted to send for the envelope domain. DKIM verifies a cryptographic signature over the message, proving it was authorised by the signing domain and has not been altered. DMARC ties either result back to the visible From: address through alignment — and alignment is the point. A phishing message can have a perfect SPF pass for its own throwaway domain while displaying your bank in the From field. Only DMARC connects the two.

Which brings us to the security caveat that governs reading headers at all. Headers are plain text and anyone can invent them. Only the headers added by your own mail infrastructure — from your boundary MTA inward — are trustworthy; everything below that point was supplied by the sending side and may be entirely fabricated, including convincing-looking Received lines designed to hide the true origin. Read the chain from the top down, and stop trusting it at the first server you do not operate.

Finally, note the difference between Return-Path and From. The first is the envelope sender, where bounces go and what SPF checks; the second is the display address the recipient sees. Legitimate mail from mailing lists and ticketing systems routinely differs between the two, so a mismatch is a prompt to look closer, not proof of anything by itself.

Frequently asked questions