How to use it
- Open the message in your mail program, find its original or full headers, and copy them from the first line down to the blank line.
- Paste them into Raw headers. The page reads them in your browser.
- Read Hops in order from the first hop to the last, and the Delay column for the time each hop took.
- Read SPF result, DKIM result and DMARC result. A pass is green; any other result is red.
How mail records its route
Each server that handles a message adds a Received line at the top of the headers (RFC 5321, section 4.4). The line names the host it heard from (from), the host it passed the mail to (by), the protocol (with), and a date after the semicolon (RFC 5322, section 3.6.7). Read from the bottom, the lines give the route in order.
- The delay of a hop is its time minus the time of the hop before it, read from the bottom up.
- A server's clock can be wrong, so a negative or long delay says as much about the clock as about the network.
Addresses and alignment
From is the author's address. Return-Path is where bounces go, and it is the address SPF checks (RFC 5322, sections 3.6.2 and 3.6.7). DMARC compares the From domain with the domain that SPF or DKIM checked. Under relaxed alignment, the default, the two need only share an organizational domain; under strict alignment they must be the same name (RFC 7489, sections 3.1 and 3.1.1). Reply-To is where replies go when it is set (RFC 5322, section 3.6.2).
Authentication results
A receiving server records its checks in an Authentication-Results header. Its first word is the authserv-id of that server, and each result is a method with a value, such as spf=pass, dkim=pass or dmarc=pass (RFC 8601, sections 2.2 and 2.7). Received-SPF is the older header that records one SPF check (RFC 7208, section 9.1).
Example: a message through three servers
The default headers show a message from client.example.net that passed through relay.example.net and mx.example.org before it reached mail.example.net. Read from the bottom, the three Received lines are timed 09:59:21, 10:00:03 and 10:02:14, so the second hop took 42 seconds and the third 2 minutes 11 seconds.
The Authentication-Results header reports spf=pass, dkim=pass and dmarc=pass for example.net. Replies go to [email protected], another domain, which the page marks because a reply that leaves the sender's domain is worth checking.
| Measure | Value |
|---|---|
| Received lines | 3 |
| Time from first to last hop | 2 min 53 s |
| SPF | pass (example.net) |
| Reply-To | Replies go to example.org, not example.net. Check that this is intended (RFC 5322, section 3.6.2). |
Frequently asked questions
Why are the hops in the reverse order of the Received lines?
Each server puts its Received line at the top, so the newest hop is first in the headers (RFC 5321, section 4.4). The page reverses them, so the first row is the server the mail left from.
Can I trust the Received lines?
Each server writes its own line, but the names and addresses in it are what that server reported, and the sender may add lines of its own. The lines at the top were added most recently, by the servers closest to you, and deserve the most attention.
What does a negative delay mean?
A hop timed earlier than the one before it means that the clocks of two servers disagree, or that a time zone was read wrongly. It is a sign of clock error, not of a faster network.
What is Authentication-Results?
It is a header that a receiving server adds to say what it checked, such as SPF, DKIM and DMARC, and the result of each check (RFC 8601). Its first word names that server, and only the header of your own receiving server should be trusted (section 2.5).
Why does the Reply-To domain matter?
Replies go to Reply-To when it is set, and to From otherwise (RFC 5322, section 3.6.2). If it names another domain, replies leave the domain the message came from. That is not wrong in itself, but it is worth checking.
Does this tool send my headers anywhere?
No. The headers are read in your browser. Nothing is sent or stored.
Sources
- RFC 5322: Internet Message Format
- RFC 5321: Simple Mail Transfer Protocol, trace information
- RFC 8601: Message Header Field for Indicating Message Authentication Status
- RFC 7208: Sender Policy Framework (SPF)
- RFC 7489: DMARC
Figures and text last checked on Tuesday, November 10, 2026.