How the headers are parsed
An email header is one logical line per field, but long values are folded onto continuation lines that start with whitespace (RFC 5322). The analyzer joins those back together, stops at the first blank line where the body begins, and keeps every field in the All headers table with a filter box. If nothing parses it tells you that no headers were recognised, which usually means the body was pasted instead of the source.
Received lines are split at their last semicolon: the date follows it, and the text before it supplies the from host, the IP in square brackets, the by host and the with protocol such as ESMTPS. The IP in each row links to the IP lookup so you can see who owns the server that handed the message on.
Reading the delivery path
The Delivery time tile is the difference between the first and last dated hops. The per-hop Delay column shows where the time went. A gap of a few seconds between servers is normal. A gap of minutes or hours on a single hop points at that server: greylisting, a queue backlog, a spam scan that took a while, or a relay that only retries on a schedule.
Negative delays happen. Every server stamps the time by its own clock, so a hop whose clock runs slow or whose timezone is wrong appears to have received the message before the previous one sent it. The finding only mentions this when a hop is more than two minutes in the past, and it is a clock problem rather than a routing one.
SPF, DKIM and DMARC from Authentication-Results
The receiving server records its checks in an Authentication-Results header (RFC 8601). The analyzer reads the topmost one, falling back to ARC-Authentication-Results, and splits it into method=result clauses with their properties: smtp.mailfrom for SPF, header.d or header.i for DKIM, header.from and the policy for DMARC. SPF softfail and neutral are shown as warnings. Any DKIM result other than pass is a fail.
DKIM-Signature headers are listed separately with the signing domain (d=), selector (s=) and algorithm (a=), and each carries a Check key link to the DKIM checker that fetches the public key from DNS. If the Authentication-Results header is absent the tool says so rather than inventing a result, which is common when you paste headers from a sent item or an internal system.
Spoofing signs the findings look for
The findings compare domains at the organisational level, so mail.example.com and example.com count as the same owner. A Reply-To at a different organisation is a warning because that is how reply-based fraud works. A Return-Path at a different organisation is only information, because bulk senders use their own bounce domain, but it also means SPF cannot align for DMARC.
- DMARC fail with policy reject or quarantine: the domain asked receivers to refuse this
- DKIM signed by a domain unrelated to From: passes DKIM but not alignment
- Display name containing another address: the real sender is the one after it
- First hop from a consumer ISP range for a message claiming a corporate sender
Limits of header analysis and related checks
Headers added before the message reached your provider can be forged. Only the Received lines stamped by servers you trust, and the authentication results your own receiver wrote, are reliable. The tool does not verify DKIM signatures itself and does not query DNS. It reports what the headers say. For the sender's published policies, check the domain in the SPF checker and the DMARC checker.