Email header analyzer

What it does

Every mail server that handles a message adds lines to the top of its headers, and the server that finally accepts it records whether the sender passed its checks. The result is a long, wrapped block of text that is slow to read by eye. This analyzer parses the raw headers of one email and sorts them into five parts:

• Summary: From, To, Subject, Date, Message-ID, Return-Path and Reply-To.
• Authentication: SPF, DKIM and DMARC verdicts (pass, fail, none and so on) from the Authentication-Results and Received-SPF headers, plus the domain (d=) and selector (s=) of each DKIM-Signature header.
• Alignment: whether the From domain matches the DKIM d= domain and the Return-Path domain.
• Received chain: every hop numbered oldest first, with the from and by hosts, the protocol (such as ESMTPS), the timestamp and the delay since the previous hop, plus the total delivery time.
• Warnings: a Reply-To that differs from From, hops with out-of-order timestamps or clock skew, and missing authentication results.

Parsing is done by JavaScript in your browser. Nothing is uploaded or sent anywhere, and once loaded the page keeps working with the network disconnected. The tool does not verify DKIM signatures cryptographically or query DNS; it reports what the receiving servers wrote into the headers.

How to use it

1. Open the message's raw source. In Gmail, use the three-dot menu next to Reply and choose Show original. In classic Outlook for Windows, open the message in its own window, choose File, then Properties, and copy from the Internet headers box. In Outlook on the web and the new Outlook, use the three-dot menu, then View, then View message source. In Apple Mail, choose View, then Message, then Raw Source.
2. Copy the header block: everything down to the first blank line. The body below it is not needed.
3. Paste it into the box on this page.
4. Read the summary and authentication results, then the warnings, then the hop list.

Forwarding a message drops its original headers, so work from the copy in the mailbox that received it, or ask the recipient to forward it as an attachment.

Use cases

• Checking a suspicious message. A payment request from a supplier shows dmarc=fail, a DKIM d= domain unrelated to the From domain, and a different Reply-To. That is enough to report it instead of answering.
• Finding where a delay happened. A password reset arrives 40 minutes late. Most hops took a second or two, but one relay held it for 38 minutes, which tells you whose queue to ask about.
• Testing your own domain. After connecting a newsletter service, send yourself a test and confirm that SPF and DKIM pass and that d= is your domain, not the service's shared one.
• Tracing a message in logs. Give your mail administrator the Message-ID and the time your provider accepted it; both are searchable in delivery logs.
• Confirming encryption in transit. ESMTPS on a hop means that link used TLS; plain ESMTP or SMTP means it did not.

Reading the Received chain, and what can be forged

Each server prepends its Received line above the existing ones, so the newest hop is at the top. Reading bottom-up follows the message forward in time; the tool reverses the order for you.

Received: from mx-out.shop.example (mx-out.shop.example [198.51.100.25])
        by mx1.recipient.example with ESMTPS id 4f2ac81e
        for <you@recipient.example>; Tue, 6 Oct 2026 14:02:11 +0000
Received: from app01.internal (app01.internal [10.0.4.7])
        by mx-out.shop.example with ESMTP id 91c0d3;
        Tue, 6 Oct 2026 14:02:09 +0000

Trust depends on who wrote each line. Find the earliest hop added by your own provider, here the one stamped by mx1.recipient.example. That line and everything after it are reliable, and the bracketed IP address on it is the machine that really handed over the message. Everything recorded before it, which in the raw text means below it, came from the sender's side and can be invented, including fake Received lines suggesting another origin. From, Reply-To, Subject, Date and Message-ID are also set by the sender.

Each timestamp comes from that server's own clock. A delay a few seconds below zero usually means a clock is slightly off. Long gaps point to a queue, a retry after a temporary rejection, or a message held for scanning.

What SPF, DKIM and DMARC each prove

SPF compares the connecting IP address with the servers a domain lists in DNS. The domain checked is the envelope sender, which becomes the Return-Path, not the visible From. A pass proves only that this server may send for the Return-Path domain. Forwarding often breaks SPF because the forwarder is not on the list.

DKIM is a signature over the body and selected headers. d= names the signing domain and s= the selector used to find its public key. A pass means the signed parts were not altered and the d= domain vouched for them. It says nothing about From unless the domains match.

DMARC ties both checks to the address readers see: it passes when SPF or DKIM passes and the passing domain aligns with the From domain. A message can pass SPF and DKIM for a bulk sender's own domains while the From line names a bank, and DMARC will still not pass.

Authentication-Results: mx1.recipient.example;
       dkim=pass header.d=shop.example header.s=s2026;
       spf=pass smtp.mailfrom=bounce.shop.example;
       dmarc=pass header.from=shop.example

Under DMARC's default relaxed mode, bounce.shop.example aligns with shop.example because they share an organizational domain. Check that the first name in this header is your provider's server; a sender can insert a fake Authentication-Results line, and careful receivers strip those.

Finally, look past the display name. In PayDesk Billing <billing@paydesk-help.example> most mail apps show only the friendly name, but the checks above concern the address.

Frequently asked questions

The analysis repeats what receiving servers wrote into the headers and applies simple heuristics. It cannot prove who sent a message; when money or credentials are involved, confirm through a channel you already trust.