Free · No signup · Runs in your browser

Email header analyzer

Paste the raw headers from any email and get a plain-English answer: who really sent it, every server it passed through, and whether SPF, DKIM and DMARC checked out. Nothing is uploaded - the analysis runs entirely on this page.

Your headers never leave this page. The analysis is JavaScript running in your browser - nothing is sent to our servers, logged, or stored.

Processing
In your browser
Checks
SPF, DKIM, DMARC
Delivery path
Every hop, timed
Registration
Not required
Price
Free
The short version

What is an email header?

An email header is the block of metadata attached to every email that records who sent it, which servers relayed it, when each one handled it, and whether the sending domain passed authentication. Your mail client shows you four fields from it - From, To, Subject and Date - and hides the rest, which is where anything genuinely useful lives.

The headers are written by machines, for machines. A typical message carries thirty to sixty fields, several of them repeated, most of them wrapped across multiple lines. Reading them by eye is possible but tedious, and the parts that matter for working out whether a message is genuine are scattered across three or four different fields that have to be compared against each other.

That comparison is what this tool automates. It reconstructs the delivery path in the order the message actually travelled, pulls out the authentication verdicts the receiving server recorded, and checks whether the domain that passed those checks is the same one shown in the From line - the single question that separates a genuine message from a convincing forgery.

Also searched as an email header reader, message header analyzer, mail header parser, or an email trace tool - all the same job, and this page does it for every one of them.

How it works

How to analyze email headers

Four steps, and the only one that takes any effort is finding where your mail client hid the headers.

01
Open the message where it landed

Headers are written by the receiving server, so they only exist in the mailbox that received the message. A copy in your sent folder will not carry them.

02
Copy the original headers

Every client hides this somewhere different - "Show original" in Gmail, "View source" in Outlook. The per-client instructions further down cover the six most common.

03
Paste them into the box

Paste the whole thing, including the message body if that is easier. Everything after the first blank line is discarded automatically.

04
Read the verdict, then the path

The summary tells you whether the sender was authenticated. The delivery path shows every server the message passed through, and where it stalled.

Step two, in detail

How to get email headers from your mail client

Every client buries this somewhere different. Pick yours.

How to view email headers in Gmail

  1. 1 Open the message in Gmail on the web.
  2. 2 Click the three-dot menu at the top right of the message, not the one in the toolbar.
  3. 3 Choose "Show original". A new tab opens with the full source.
  4. 4 Click "Copy to clipboard", or select everything above the first blank line.

The Gmail mobile apps cannot show original headers. Use the web version on any device.

How to view email headers in Outlook (web)

  1. 1 Open the message in Outlook on the web.
  2. 2 Click the three-dot menu at the top right of the message.
  3. 3 Choose "View", then "View message source".
  4. 4 Select all of the text in the panel and copy it.

Outlook.com, Hotmail and Microsoft 365 webmail all follow these steps.

How to view email headers in Outlook (desktop)

  1. 1 Double-click the message so it opens in its own window.
  2. 2 Go to File, then Properties.
  3. 3 The headers are in the "Internet headers" box at the bottom.
  4. 4 Click inside the box, select all, and copy.

The box is small and does not resize - select all rather than trying to read it there.

How to view email headers in Apple Mail

  1. 1 Select the message in Apple Mail.
  2. 2 Open the View menu, then Message, then "All Headers".
  3. 3 The full header block appears above the message body.
  4. 4 Select it and copy.

Shortcut: Command + Shift + H toggles all headers on and off.

How to view email headers in Yahoo Mail

  1. 1 Open the message in Yahoo Mail.
  2. 2 Click the three-dot menu above the message.
  3. 3 Choose "View raw message".
  4. 4 Select everything in the window that opens and copy it.

AOL Mail uses the same interface and the same steps.

How to view email headers in Thunderbird

  1. 1 Select the message in Thunderbird.
  2. 2 Press Ctrl + U (Command + U on macOS), or use View, then "Message Source".
  3. 3 The complete source opens in a new window.
  4. 4 Select the text above the first blank line and copy it.

Thunderbird shows the rawest output of any mainstream client - useful when another client has stripped something.

Reading the results

What SPF, DKIM and DMARC actually tell you

Three checks, three different questions. Only the third one answers "is this really from who it says?"

SPF

Was this server allowed to send?

The domain publishes a list of servers permitted to send mail on its behalf. SPF checks whether the server that actually delivered this message is on that list. It breaks on forwarded mail, because the forwarding server is not on the original list.

DKIM

Was the message altered in transit?

The sending domain signs the message cryptographically. The receiving server verifies that signature against a public key in DNS. A DKIM pass proves both that the domain sent it and that nothing changed on the way. It survives forwarding, which is why it matters more than SPF.

DMARC

Is the visible sender the real sender?

DMARC ties the other two together and adds the part that actually stops spoofing: it requires that the domain which passed SPF or DKIM is the same domain shown in the From: line. Without that alignment check, an attacker can pass SPF using their own domain while displaying yours.

Why alignment is the part that matters

An attacker can register their own domain, publish perfectly valid SPF and DKIM records for it, and send you mail that passes both - while the From line displays your bank. The checks passed; they just passed for the attacker's domain, not the one you can see. DMARC alignment is the rule that catches this, which is why a DMARC failure on mail claiming to come from a major brand is the strongest single signal in the whole header block.

— Red flags

How to tell if an email is spoofed

Any one of these can be innocent. Two or three together, on a message that wants you to click something or move money, is not.

DMARC failed on a message claiming to be from a large brand. Those domains publish strict policies, so genuine mail from them passes.
Reply-To points at a different domain from the From address - the core mechanic of business email compromise.
Return-Path matches neither the From address nor anything related to it.
No Message-ID at all. Every mainstream client sets one; scripts often do not.
The originating server has no relationship to the brand in the From address.
A display name showing one address while the actual address underneath is something else entirely.
FAQ

Email header analysis: frequently asked questions

An email header is the block of metadata that travels with every message and records how it got to you: who sent it, which servers relayed it, when each one handled it, and whether the sending domain passed authentication. Your mail client hides almost all of it and shows you only From, To, Subject and Date. The rest is where the useful information lives.

It takes that raw block - which is dense, repetitive and written for machines - and turns it into something readable. This one extracts the delivery path hop by hop, pulls out the SPF, DKIM and DMARC verdicts the receiving server recorded, checks whether the visible sender domain matches the domain that actually authenticated, and flags the patterns that show up in forged mail.

It depends on your client. Gmail: open the message, three-dot menu, "Show original". Outlook on the web: three-dot menu, "View", "View message source". Apple Mail: View menu, Message, "All Headers". Yahoo: three-dot menu, "View raw message". Thunderbird: Ctrl+U. Full instructions for each are in the section above.

SPF checks whether the server that sent the message is on the list of servers the domain authorised. DKIM checks a cryptographic signature proving the message was not altered in transit and really came from that domain. DMARC ties the two together and adds the part that matters most: it requires that the domain which passed SPF or DKIM is the same domain shown in the From: line. A message can pass SPF and still be a forgery if the passing domain is not the one you see.

The strongest single signal is a DMARC failure on a message claiming to be from a large brand - those domains all publish strict policies, so a genuine message from them passes. After that, look for a Reply-To that points at a different domain from the From address, a Return-Path that does not match either, and a missing Message-ID. Any one of these can be innocent. Two or three together, on a message that wants you to click something, is not.

Almost always forwarding. When a message is forwarded, the forwarding server becomes the sender as far as SPF is concerned, and it is not on the original domain's authorised list - so SPF fails through no fault of the original sender. This is exactly why DKIM exists: the signature survives forwarding. If DKIM passed and SPF failed, forwarding is the likely explanation.

Each server adds its own Received: line to the top of the header block as the message passes through, so the raw headers read newest-first - the last server to touch the message is at the top and the original sender is at the bottom. This tool reverses them, so the delivery path you see runs in the order the message actually travelled.

Only roughly, and often not at all. The originating IP tells you which server submitted the message, which for anyone using Gmail, Outlook or any mainstream provider is a data centre, not a person. Mail sent from a self-hosted server or a compromised device can reveal more. Treat any location you derive this way as a weak signal, never as an identification.

No. The entire analysis runs as JavaScript inside your browser - the headers are never sent to our servers, never logged, and never stored. You can disconnect from the internet after the page loads and the tool still works. Email headers routinely contain internal hostnames, recipient addresses and routing details, which is exactly the kind of thing that should not be handed to a third party to process.

No. There is no signup, no limit on how many messages you can analyse, and no paid tier. If you also need a disposable address to test where your own mail ends up, you can create one on this page in a click - that is free too.

Testing where your own mail actually lands?

Send it to a disposable address, then run the headers it arrives with through this analyzer. Free, no signup, and the inbox deletes itself afterwards.

10 minute email