Skip to content

Email Header Analyser

Parses raw email headers into a delivery timeline with per-hop delays, reads the receiving server’s SPF, DKIM and DMARC verdicts, and flags From/Reply-To/Return-Path mismatches.

Paste the raw headers of a message and it reconstructs the path it took, reads the receiving server’s SPF, DKIM and DMARC verdict, and flags the patterns that phishing relies on — a Reply-To on a different domain, a display name containing a second address. Everything happens in the tab.

🔒 Runs entirely in your browseremailheadersforensicsspam

The headers are parsed inside your browser. Neither the headers nor the message go anywhere.

Drop an .eml file, or paste the headers below

Gmail: message menu ▸ Show original. Outlook: File ▸ Properties ▸ Internet headers. Naver: top of the message ▸ 원본 보기 (Show original).

How to use it

  1. Get the original, not a forward

    Gmail: message menu, Show original. Outlook: File, Properties, Internet headers. Naver: 원본 보기 (Show original) at the top of the message. Forwarding a message rewrites its headers and loses the evidence.

  2. Read the authentication row first

    SPF, DKIM and DMARC as your own mail server judged them. DMARC pass means the From address is aligned and verified; DMARC fail on a message that reached your inbox is worth taking seriously.

  3. Compare From, Reply-To and Return-Path

    A Reply-To on a different domain sends your answer somewhere the sender does not control, which is the commonest single trick in business email compromise. A differing Return-Path is normal for bulk senders.

  4. Use the timeline to find a delay

    Each hop shows the gap from the one before it. A message that took two hours usually spent all of it at one server, and the table names it.

Common questions

Are my headers uploaded?

No. The parsing runs in your browser and nothing is sent. Headers carry recipient addresses, internal server names and message ids, which is exactly why this one does not leave the tab.

Can I trust the Received headers?

Only the last few. Each server appends its own line and none of them are verified, so a sender can plant fake ones before the message ever leaves. The lines your own mail server added are the ones with any weight.

Is the sending IP the sender’s real address?

It is the address the first trustworthy hop observed, which for anyone using a normal mail provider is that provider’s outbound server, not their home connection. Paste it into the IP info tool to see whose network it is.

Everything passed — is the message safe?

It means the message really came from the domain it claims. It says nothing about whether that domain is trustworthy — a lookalike domain the attacker registered passes its own SPF and DKIM perfectly.

Feed it from

Next

These accept what this tool produces, so the result can go straight in.