Email Header Analyzer

Where to find the headers

Gmail — open the message, the three-dot menu, Show original.
Outlook — open the message, File, Properties, and copy the Internet headers box.
Apple Mail — View, Message, All Headers.
Thunderbird — View, Message Source, or Ctrl+U.

Paste the whole thing, body included if it is easier. Parsing stops at the first blank line, which is exactly where the headers end.

Reading the delivery path

Each server that handles a message adds a Received header at the topof the list. The raw order is therefore backwards — newest first — which is the single most common source of confusion when reading headers by hand. They are reversed here, so hop 1 is where the message started and the last row is where it arrived.

The delay column is the gap between one server's timestamp and the next. Most hops are a second or two. A gap of minutes at one hop is usually greylisting, where a receiving server deliberately rejects a first attempt and accepts the retry, or a queue on a busy relay. Neither is a network fault, and both look identical to "the email was slow" from the outside.

Timestamps come from the servers themselves, and server clocks disagree. A hop that appears to take negative time is clock skew, not time travel; it is shown as zero here rather than as a negative number.

SPF, DKIM and DMARC in one sentence each

SPF asks whether the server that sent this message is allowed to send for that domain. It breaks legitimately when mail is forwarded, because the forwarding server is not on the original list.

DKIM is a cryptographic signature over the message. It survives forwarding, and fails if anything modified the content in transit — which some mailing lists do by appending footers.

DMARC ties the other two to the domain a reader actually sees in the From line, and tells receivers what to do when they disagree. It is the one that decides whether a message is trusted, which is why dmarc=fail matters more than either of the others failing alone.

These verdicts are the receivingserver's findings, recorded in the message. They are a report, not a live check — a header can say spf=pass for a domain whose policy has changed since.

What a Return-Path mismatch does and does not prove

If Return-Path is a different domain from From, the tool says so. That is deliberately phrased as something to check rather than a verdict, because the mismatch is entirely normal for mailing lists, newsletters and anything sent through a bulk provider — the bounce address belongs to the sending platform, not the brand.

It is also what unsophisticated spoofing looks like. The way to tell them apart is the authentication block: a legitimate bulk sender will show DMARC passing despite the mismatch, because the domain owner authorised that platform. A spoof usually will not.

Related tools

DNS lookupto read a domain's SPF and DMARC records directly, IP address and ISP lookup to identify a sending host, and the connection report when a support ticket needs the rest.

Privacy note

Headers are more sensitive than they look: they contain your address, the sender's, the subject line, and frequently internal hostnames and IP addresses from inside a company network. The established analysers post all of that to a server. This one parses it in your browser — there is no upload, no storage, and no request made while you type. You can confirm that in your browser's network tab.

Common questions