Email header analyzer: how do you read the Received chain and Authentication-Results?
How does this check work, and what does the result tell you?
AdminKit's email header analyzer parses the raw headers you paste, entirely in your browser, into the Received delivery chain in order, a per-hop delay computed from those servers' own timestamps, the Authentication-Results SPF, DKIM and DMARC verdicts already stamped, and the earliest public IP it can identify. It reads what the servers wrote; it never verifies anything live.
Part of the Email authentication cluster — more tools, guides and terms on email authentication.
Everything below is computed in your browser the moment you paste — nothing you enter is sent to AdminKit or anywhere else, and this tool never contacts a mail server itself.
What the result means
This reads the Received and Authentication-Results headers the mail servers along the delivery path already wrote — it is a transcript of what those servers reported, not a live re-check. The per-hop delay is computed from their timestamps, which can disagree across time zones or be skewed by a wrong server clock, so treat it as approximate. For a live SPF/DKIM/DMARC verdict against your own domain's current DNS, use AdminKit's SPF check, DKIM check or DMARC check instead.
Next step
If the Authentication-Results above show a failing SPF, DKIM or DMARC verdict, fix the underlying DNS record with AdminKit's SPF generator, DKIM generator or DMARC generator, then confirm the fix took effect with the matching live check once DNS has propagated.
Keep this result
Copy a link to this check so you can share it or run it again later. Want a heads-up if something changes? That's early access, not a live feature yet — tell us and we'll set it up by hand.
How it works and limits
Paste the full raw header block from your mail client’s “show original” / “view source” view and this tool parses it as you type, entirely in your browser — nothing you paste is sent to AdminKit or anywhere else, and the tool never contacts a mail server itself. It only reads what the servers along the delivery path already wrote; it does not verify SPF, DKIM or DMARC live. For a live verdict against a domain’s current DNS, use AdminKit’s SPF check, DKIM check or DMARC check instead.
What do the Received headers tell you?
Every mail server that handles a message prepends its own Received header (RFC 5322 §3.6.7),
recording roughly where the message came from, which server accepted it, what protocol was used, and when. Because
each new hop is added at the top, the headers appear newest-first in the raw text — this tool reverses that order so
the chain reads origin-first, the way the message actually traveled. For each hop it surfaces:
- from — the sending server’s claimed hostname and, usually, its IP address.
- by — the server that accepted the message at this hop.
- with — the protocol used (e.g. ESMTP, ESMTPS).
- id — that server’s internal queue ID for the message.
- for — the recipient address the server was handling it for.
- timestamp — that server’s own clock reading when it accepted the message.
The delay shown between consecutive hops is computed purely by subtracting one hop’s timestamp from the next. That calculation is only as good as the clocks that wrote those timestamps — see the FAQ below for why it can look odd.
What does Authentication-Results show (and not show)?
If a receiving server ran SPF, DKIM or DMARC, RFC 8601 has it record the
verdict in an Authentication-Results header rather than silently accepting or rejecting the message. This tool
reads that header exactly as written — the mechanism (spf/dkim/dmarc), the result (pass/fail/softfail/none/…), and
the domain it was evaluated against — without re-running any of those checks itself. A message can carry more than
one such header if more than one server in the path performed its own checks; this tool lists every one it finds, in
header order.
Limits
- This is a reader, not a verifier: it never queries DNS, never connects to any mail server, and never re-computes SPF, DKIM or DMARC from scratch. It can only show what is already written in the pasted text.
- Received headers before the first hop you actually trust can be forged by whoever sent the message — see the FAQ below.
- Per-hop delay is computed from each server’s own clock and is approximate, not authoritative, across time zones or a misconfigured server clock.
- Header formats vary across mail servers; an unusual or heavily customized
Receivedline may not split cleanly into from/by/with/id/for even though the raw text is shown in full.
Once you’ve confirmed a message’s authentication failed, AdminKit’s SPF generator, DKIM generator and DMARC generator help build the records that would fix it, and SPF, DKIM and DMARC explained covers how the three fit together.
Frequently asked questions
Does this tool check live whether my SPF, DKIM or DMARC records are actually correct?
No. It only reads the Authentication-Results header a receiving mail server already wrote into the message — a transcript of a verdict someone else already computed — and never queries DNS or re-runs SPF, DKIM or DMARC itself. For a live verdict against your domain's current DNS, use AdminKit's SPF check, DKIM check or DMARC check, each of which does query DNS for real.
Why does the delay between two Received hops sometimes look impossibly small, negative, or missing entirely?
Each Received timestamp comes from that server's own clock, and RFC 5322 §3.6.7 only says "non-authenticated Received header fields SHOULD appear in order with the most recent at the top" — SHOULD, not MUST, so a misconfigured relay, a clock in the wrong time zone, or a server that doesn't set its clock from NTP at all can make hops look out of order or produce a delay that doesn't match reality. Treat the computed delay as approximate, never as authoritative.
Can the Received chain in an email be forged?
Yes, partially: a sender fully controls everything in the message before it reaches the first mail server you actually trust, including fake Received lines designed to look legitimate. The only Received header you can rely on is the one added by a server on a path you control or trust — typically your own receiving mail server's hop, which the sender had no way to touch. Headers added before that point are only as trustworthy as whoever wrote them.
What exactly does an Authentication-Results header show, and who adds it?
RFC 8601 defines it as a trace field a receiving mail server (the "authserv-id") adds to record the result of whatever authentication checks it performed — SPF, DKIM, DMARC, or others — before passing the message along to its mailbox or another hop. It shows what that specific server concluded at that specific point in the delivery path, which is why a message can carry more than one Authentication-Results header if it passed through more than one authenticating server.