← Back

Email Header Analyzer

Paste email headers to trace the sender's delivery path

About Email Header Analyzer

This tool takes the raw header text of an email that you paste in, splits it into Field-Name: value pairs, lists the most useful ones (sender, recipient, subject, date and a few others) in a separate block, and numbers every Received record so you can roughly follow the servers a message passed through. It only parses and tidies text. It does not look up IPs or domains online, it does not verify SPF, DKIM or DMARC itself, and it does not decide whether a message is phishing or spam. If the header contains Authentication-Results, Received-SPF, DKIM-Signature or ARC fields, they are listed in a separate section exactly as the header states them (for example spf=pass), but that is text written into the header by a server, not a verdict from this tool. Think of it as a way to make headers easier to read, not as a security scanner.

How to use it

  1. Find the option in your email client that shows the original message. It goes by different names, such as View Original, Show Headers or View Source.
  2. Copy the header text, from the first field line to the end of the header block, and paste it into the large text box. There is no file upload; the tool accepts pasted text only.
  3. Results appear instantly with no button to press. The Basic Info section lists whichever of From, To, Subject, Date, Message-ID, Return-Path and Reply-To are present, in that fixed order.
  4. If the header has authentication-related fields, the Authentication headers section lists: the spf, dkim and dmarc results stated in each Authentication-Results header (such as pass, fail, softfail or none; an item the header does not mention shows 'not stated in this header'), the Received-SPF result and raw text, the signing domain (d=) and selector (s=) of each DKIM-Signature, and the instance numbers of ARC-Seal, ARC-Message-Signature and ARC-Authentication-Results. If none of these fields exist, it says they are not present.
  5. Look at the Delivery Path section below it, which lists every Received record. Number #1 is the record lowest in what you pasted, meaning the earliest hop. The highest number is the record at the top, the hop closest to your inbox.
  6. If the page says no valid fields were recognized, check that you pasted the header itself, with lines that look like Field-Name: value.

A real parsing example

The output below comes from running the same parsing logic the tool uses. The input header had two Received records (each continued on a second line that starts with whitespace, which marks a continuation), plus From, To, Subject, Date and Message-ID. The tool first joins the indented continuation lines onto the line above, so the first Received parses as: from mx.example.net (mx.example.net [203.0.113.5]) by mail.example.org with ESMTPS; Tue, 2 Jan 2026 09:00:05 +0800. The second parses as: from sender-pc (unknown [198.51.100.7]) by mx.example.net with SMTP; Tue, 2 Jan 2026 09:00:02 +0800. The page labels the first one #2 and the second one #1, so reading from #1 to #2 follows the message from the sending machine through mx.example.net to mail.example.org. The domains and IP addresses in this example are reserved documentation values used only for illustration.

Limits and known quirks

  • Parsing stops at the first blank line, which separates the headers from the body, so anything after it is ignored and pasting the body as well does not create extra fields.
  • Basic Info shows every occurrence of From, To, Subject, Date, Message-ID, Return-Path and Reply-To. Other fields, such as those starting with X-, are parsed but not displayed separately; authentication-related fields are shown in their own section.
  • The authentication section only reads the header text: simple text matching finds the result word after spf=, dkim=, dmarc= and arc= and shows it unchanged. No signature is checked, no DNS lookup is made, and the tool cannot tell whether a trusted server added those fields. A sender can write a forged Authentication-Results line into a message before sending it, so do not treat this as proof of authenticity. A message that passed through several servers can carry several Authentication-Results headers; they are listed separately, and you must decide which one comes from a receiving server you trust.
  • MIME encoded words in field values (like =?UTF-8?B?...?= or =?UTF-8?Q?...?=) are decoded automatically; an unsupported charset or damaged encoding is left as the raw text.
  • Received records are shown in text order. The tool does not parse times, IP addresses or hostnames from them and does not calculate delays between hops.
  • Received lines are added by intermediate servers, and a sender can forge the lowest few. Treat the information as a clue, not proof.
  • Nothing is saved or uploaded, and the box is empty again after a refresh.

Why is the bottom Received line the earliest?

Each server that handles a message adds its own Received line at the top of the header block. So lines lower down are older and lines higher up are newer. That is why the tool marks the bottom one as #1.

Is it normal for From and Return-Path to differ?

It is common and not necessarily a problem. Bulk mail, mailing lists and third-party sending services often use a different bounce address. But if a message claims to come from your bank or employer and the origin details clearly do not fit, be cautious. Use the verification result your mail client shows, and what the authentication section reports the header as saying, alongside this, because the tool only lays the fields out for you.

Can it tell me whether an email is a scam?

Not on its own. It shows the SPF, DKIM and DMARC results the header claims but does not verify them, and it does not inspect links or attachments. You can compare From, Reply-To and Return-Path side by side, but trust still depends on the message content, the sending domain and the warnings from your mail provider. For anything involving payments or passwords, confirm through an official channel.

Why does nothing show up after I paste?

If the box is empty or contains only whitespace, no result is shown. If nothing you pasted has a line with a colon, the page shows a red message. Copying from some web pages can also lose indentation or line breaks, which makes fields merge or split wrongly, so try copying straight from your client's original message window.

Privacy and processing

Headers can contain email addresses, server hostnames and IP addresses. All parsing here happens in your browser. The page contains no network request code and does not store what you paste. Even so, before sending a header to someone for help, review it and remove anything you do not want to share.