Email Header Analyzer

Paste the raw headers of a received email (Received:, Authentication-Results:, etc.) to see the delivery path broken down hop by hop, along with SPF/DKIM/DMARC results. Parsing runs 100% in your browser.

Last updated: 2026-10-18

What each Received: clause means

Clause	Meaning
from	The hostname/IP address of the server that handed off this message, as recorded by the receiving server that wrote this line. Senders can add as many fake Received lines as they like, so the oldest lines are the easiest to forge. To find the real originating IP, use the from of the oldest line written by a receiving server you control (in this tool's list, the first hop whose "by" is your own server).
by	The hostname of the server that received the message at this hop (e.g. your own mail server).
with	The delivery protocol used (e.g. ESMTP, ESMTPS, SMTP). ESMTPS indicates the connection was encrypted with TLS.
for	The recipient address the message was delivered for. Often omitted for mailing lists or messages with multiple recipients.
timestamp	The date and time this hop received the message. The time and timezone are recorded by the receiving server that wrote this line (RFC 5321 §4.4). The gap between hops is a rough measure of delivery delay.

What each Authentication-Results: field means

Field	Meaning
SPF	SPF (Sender Policy Framework) result: whether the sending IP is listed among the addresses the domain's DNS record permits.
DKIM	DKIM (DomainKeys Identified Mail) result: whether the cryptographic signature over the message body and key headers verified against the sending domain's public key.
DMARC	DMARC (Domain-based Message Authentication, Reporting & Conformance) result: an overall verdict checking SPF/DKIM alignment against the domain in the From header.

Tracing the route of a message from its headers

Paste in the raw headers of a message you received and this tool breaks the Received: lines apart hop by hop to lay out the route, and lists the SPF, DKIM and DMARC verdicts recorded in Authentication-Results:. The whole analysis happens inside the browser, so nothing you paste is sent anywhere.

The first thing to grasp about reading them is that Received: lines run from the bottom upward. Each server, on receiving the message, adds its own line at the very top, so the oldest leg sits at the bottom and the server that received it last sits at the top. More importantly still, these headers can be forged by anyone. A sender may fabricate as many Received: lines as they please and put them at the head. What may be trusted is the line written by a server under your own control, and everything above it; anything below it means no more than that someone claimed it. The same holds for Authentication-Results:, since unless you look at which server wrote the verdict, the verdict itself may be a fake.

How to use it

Paste in the raw headers They can be had from "show original" or "view source" in your mail client.
Read the Received lines from the bottom up The bottom is the first sender; the top is the server that received it last.
Check the authentication results The SPF, DKIM and DMARC verdicts are set out together.
Work out where trust begins Anything below the line written by a server under your control may have been forged.

Tips for getting more out of it

In Gmail, open the message, click the three-dot menu in the top right, and choose "Show original" to get the raw headers. In Outlook, use File > Properties > Internet headers.
Received: headers are prepended to the message in newest-first order (the receiving side comes first), so this tool reorders them chronologically from sender to receiver for you.
If mail servers along the path have slightly unsynchronized clocks, the "delay since previous hop" can show a negative number. A small negative value usually just reflects clock drift, not an actual delivery problem.
Even if SPF, DKIM, and DMARC all pass, that does not guarantee the message is not a scam. Authentication only verifies the domain owner's own setup was followed correctly — it cannot detect a malicious actor who legitimately owns a look-alike domain.
If the delay jumps sharply between two particular hops, that segment of the path is where a delivery bottleneck or spam-filter hold likely occurred.

Where it comes in useful

Investigating where spam came from

The true originating address appears in the lowest Received: line you can trust.

Seeing through an impersonation

A display name and a From line are trivially faked, so judge by the authentication results.

Tracing a delay in delivery

Reading the times at each hop shows you where the message sat still.

Confirming that your own mail passes authentication

Send yourself a test message and see whether SPF, DKIM and DMARC all pass.

Email header terms

Received: The header to which each receiving server adds its own line at the very top. The route is read from the bottom upward.
Authentication-Results: The header recording the SPF, DKIM and DMARC verdicts reached by the receiving side. Which server wrote it is what matters.
Return-Path: Where a failed delivery is returned to. SPF is checked against this domain.
From: The sender as displayed. Anything may be written here, so it proves nothing about who sent the message.
Message-ID: The string uniquely identifying a message, used to tell duplicates of the same one apart.
Hop: A single server the message passed through. Each hop leaves one Received: line behind.

Frequently Asked Questions

In Gmail: open the message, click the three-dot menu in the top right, and choose "Show original". In Outlook: File > Properties > Internet headers. In Apple Mail: View > Message > All Headers. Copy the full text shown and paste it into this tool.

No, not by itself — the From header can be freely set by the sender. Received: headers can also be forged by adding fake lines, so the oldest line cannot be taken at face value either. To check the real source, look at the IP address in the from clause of the oldest line written by the receiving server you use (for Gmail, mx.google.com and the like; in this tool's list, the first hop whose "by" is your own server), together with the SPF/DKIM/DMARC results recorded by that server.

Not a full guarantee. These checks only verify that the message passed through the setup the owner of the From-header domain configured. An attacker who registers a look-alike domain (e.g. one character off from a legitimate one) and configures SPF/DKIM/DMARC correctly for it can still pass every check while sending a fraudulent message.

No. All parsing happens in your browser's JavaScript, and nothing is sent to an external server. Email headers can contain details about internal mail server configurations, so this was designed with privacy in mind.

Each relaying server timestamps the message using its own clock, so if two servers' clocks are slightly out of sync, a hop that was actually processed later can end up with an earlier recorded time than the one before it. A negative value of a few seconds is normally just clock drift, not an actual delay problem.

Side Note — Email headers are a stack of digital postmarks

Just as a postmark on a letter records which post office handled it and when, the Received: headers on an email are a stack of "digital postmarks" — every server that relayed the message stamps its own timestamp onto it. The SMTP protocol (RFC 5321) requires every relaying server to prepend its own information to the top of the header block, so a complete record of the delivery path accumulates naturally with every message.

This turns out to be most useful for tracing the source of spam. The catch is that Received: headers can be forged just as freely as the From header: a sender can add any number of fake Received: lines before sending the message out, so the oldest (bottom) lines are the most likely to be fake. The only lines you can really trust are those written by receiving servers under your own control. The oldest of those was recorded when your server accepted the connection from the outside, and the connecting IP address in its from clause is something the sender cannot fake. That "first connection recorded by your own server" is exactly what anti-spam specialists look at first.

SPF, DKIM, and DMARC were added later to catch spoofing that postmarks alone cannot stop. SPF checks whether the sending IP is on the domain's permitted list, DKIM verifies a cryptographic signature to confirm the content was not altered, and DMARC combines both checks against the domain in the From header for an overall verdict. After Google and Yahoo effectively required DMARC for bulk senders in 2024, Authentication-Results headers became a routine sight in everyday inboxes.

Email headers are something most people never open, but the moment you do, you find a precise, invisible travel log — which servers around the world a single message passed through, and how many seconds it took at each step.

Browse all trivia