Analyze an email's headers
The relay chain, the delay at each hop, the SPF / DKIM / DMARC verdicts and the real sender — in one paste. Nothing is stored.
How it works
- Get the raw headers — "Show original" in Gmail, "View message details" in Outlook, Ctrl+U in Thunderbird. Copy the whole block above the first blank line.
- Paste them into the field above — the tool unfolds wrapped lines, ignores the message body if you copied it by mistake, and decodes MIME-encoded subjects.
- Read the report — the relay chain in chronological order with the delay at each hop, the SPF / DKIM / DMARC verdicts exactly as the receiving server wrote them, displayed sender versus real sender, and the headers worth a look.
Use cases
- Checking whether a message is a phishing attempt — a reassuring displayed name in front of an unknown address, a failing DMARC and a Return-Path on an unrelated domain: three signals you can read at a glance here.
- Understanding why an email arrived late — the per-hop delay points at exactly which relay held the message, instead of leaving "the internet" to take the blame.
- Diagnosing a deliverability problem with your own sending — send yourself a message from your emailing tool, then read here the SPF and DKIM verdicts actually obtained on the receiving side.
- Evidencing a message's route — in a dispute or an incident, the timestamped Received chain is the only verifiable trace of what happened.
- Identifying the sending software — the X-Mailer and User-Agent headers often give away a bulk send dressed up as a personal message.
What this tool doesn't do
- The tool reads the SPF, DKIM and DMARC verdicts; it does not recompute them. Those checks are only meaningful when run at delivery time by the receiving server: redoing them after the fact, without the original connecting IP, would produce a wrong answer.
- Received headers are declarative: a hostile server can forge them. Only the Received lines added by trusted servers, at the end of the chain, are genuinely reliable.
- The message body is not analysed: not the links, not the attachments, not the HTML. To open a complete message, use the EML viewer.
- No IP or domain reputation is looked up here: blacklist checking will get its own dedicated tool.
- Nothing is stored, so nothing can be compared over time: the tool keeps no history of your analyses.
Frequently asked questions
Where do I find an email's full headers? +
In Gmail: open the message, "⋮" menu, then "Show original". In Outlook on the web: "⋯", then "View" and "View message details". In Thunderbird: Ctrl+U, or "View › Message source". Copy the whole block above the first blank line — that is exactly what this tool expects.
What does the chain of Received headers tell me? +
Every server that relays the message adds a Received line at the top. Read backwards, that stack tells the message's journey, from the sender's machine to your mailbox. The tool puts those lines back in chronological order and works out the time spent between two relays: a hop of several hours points straight at the server that held the message.
What do the SPF, DKIM and DMARC verdicts mean? +
SPF checks that the sending server was authorised by the sender's domain. DKIM checks a cryptographic signature added by the sender's domain. DMARC combines both and checks that they line up with the domain shown in the From field. These verdicts are written by the server that received the message, in the Authentication-Results header: the tool reads them, it does not recompute them.
Does a failing SPF or DKIM mean the message is fraudulent? +
Not necessarily. A mailing list, an automatic forward or a badly configured sending service routinely break SPF or DKIM on perfectly legitimate messages. A failing DMARC on a message claiming to come from a bank or a public service, however, is a serious signal — especially combined with a gap between the displayed name and the real address.
Why can the displayed name lie about the sender? +
The displayed name is plain free text chosen by the sender: nothing stops anyone writing "Customer service" or even "[email protected]" in front of an address that has nothing to do with it. The tool always separates the two and flags the gap, as well as any difference between the displayed address and the technical return address (Return-Path).
Are my headers stored anywhere? +
No. The analysis happens during the request and the result is returned straight away: nothing is written to a database, nothing is written to disk, nothing is sent to a third-party service. Reload the page and nothing is left.
Is there a size or usage limit? +
Headers are read up to 256 KB, which covers any real message with plenty of room to spare. An anti-abuse rate limit applies per IP address, the same for everyone: it goes unnoticed in normal use, even heavy use.