Guide
Reading e-mail headers: route, delays and SPF, DKIM, DMARC results
Every e-mail carries a block of technical lines above its text. Most of them are added by servers on the way, and together they tell where the message came from, how long it was held up and whether the sender’s domain vouches for it. Mail programs hide them, but they are the first thing to read when a message looks suspicious or an important one arrives late. This analyzer takes the raw header block and turns it into a route, a list of results and a short list of things that stand out.
The route
Each server that handles a message adds a Received line at the top, so the lines read from newest at the top to oldest at the bottom. The page reverses them into a table, oldest first, with the “from” and “by” names, the protocol, the time and the delay since the previous hop. It adds up the time in transit and picks the first public IP address as the likely sending host. A delay of several minutes at one hop points to greylisting, a queue or a scanning step on that server.
A worked example
The Sample button loads a message titled “Invoice 4471” from "Billing Team" <[email protected]>. The page shows SPF pass, DKIM pass and DMARC pass, and 3 hops with a total of 5 seconds in transit. The likely sending IP is 203.0.113.25. The hop table starts with an internal host app01.internal [10.0.0.5] handing to mail-out.sender.example, then mx.example.net receiving it from 203.0.113.25 over ESMTPS after 4 seconds, and a third hop one second later. Under “What stands out” there are four notes. Three are good: SPF passed, DKIM passed and DMARC passed. One is a medium warning: the Reply-To goes to [email protected], a different domain, so replies would not reach the billing team. Phishing often uses that pattern to collect answers.
Authentication results
The receiving server records SPF, DKIM and DMARC outcomes in Authentication-Results. SPF checks that the sending IP is listed in the envelope sender’s record. DKIM checks a cryptographic signature added by the sending domain; the page lists each signature with its domain, selector, algorithm and which headers it covers. DMARC passes when SPF or DKIM passed and the domain involved lines up with the visible From address. Only the lines added by your own mail provider, usually the topmost, are trustworthy; a sender can write false lines further down.
Spotting forgeries
Check that the From domain matches the Return-Path and the DKIM domain. A display name such as “PayPal Support” over an address at an unrelated domain is a classic trick, and so is a Reply-To that differs from the From address. Look at the hops: a message that claims to be from a bank but entered through a residential address, or one with a missing authentication result, deserves caution. Time stamps that run backwards between hops suggest tampering or clock errors.
Limits
The page reads what the headers say. It does not verify DKIM signatures, does not query DNS to re-check SPF, and cannot confirm that early Received lines are genuine, since a sender can add them. Headers can contain private addresses, so keep them out of public forums. Everything is processed locally in your browser.
Related tools
- SPF Record Checker tests the SPF record of the sending domain.
- DMARC Checker reads the policy that decided the result.
- DKIM Record Checker finds the public key for a selector from the header.
- DMARC, SPF and DKIM Record Generator builds records for your own domain.
Checked against the current version of the Email Header Analyzer on .