The Authentication-Results: header near the top of a delivered message is where the receiver records its SPF, DKIM, and DMARC verdicts on the way in. Read the whole header block from bottom to top and you can also reconstruct every hop the message took, spot the ARC seal a mailing list added when it rewrote the body, and tell whether a bounce or spam-folder placement is your problem or the sender’s. Almost nobody does. The header block is dense, the field values are formatted for parsers not people, and the useful bits are scattered across half a dozen distinct header names.
This visualiser reads the headers you paste in and prints the useful bits: a hop-by-hop chain from the origin MTA to the final recipient, per-mechanism verdict cards for SPF / DKIM / DMARC / ARC, an ARC chain summary if a forwarder is in the middle, and — where a mechanism failed — a plain-English “what to fix” block that links directly to the nanoPost tool for the fix (SPF merger for SPF fails, DKIM inventory for DKIM fails, DNS auth checker for DMARC fails).
Parsed with regex + String.prototype.split in your browser.
This plugin serves no upload endpoint; the headers never cross the
network. Provider fingerprinting matches against the same
providers.json that powers the nanoPost reviews.
How to get raw headers
- Gmail / Google Workspace. Open the message. Three-dot menu → Show original. The page that loads is the raw source; copy from the first
Delivered-To:line down through the blank line that ends the header block. (You do not need the message body.) - Outlook (web) / Microsoft 365. Open the message. Three-dot menu → View → View message source. Same rule: copy from the top through the first blank line.
- Apple Mail (macOS). View → Message → All Headers toggles the header display; View → Message → Raw Source opens the full source in a new window.
- Thunderbird. View → Message Source, or
Ctrl+U.
Copy the whole header block and paste it into the textarea above. Nothing crosses the network — the tool parses in the browser and there is no upload endpoint.
What the chain diagram shows
The Received: header stack is a log of every SMTP handoff the message went through, in reverse chronological order. The receiving MTA prepends its Received: line to the top of the stack on the way in, so the top-most Received: in the raw source is the last hop and the bottom-most is the first. The visualiser reverses that stack for you and numbers the hops origin → recipient.
Each hop shows the from host and its IP (when the receiving side recorded the reverse-DNS lookup in the parenthetical), the by host that accepted the handoff, the SMTP protocol used (ESMTPS means STARTTLS was negotiated), and the timestamp the receiver stamped. On the final hop the visualiser also pins the receiver’s SPF / DKIM / DMARC badges — those verdicts belong to the message as it arrived, not to the intermediaries.
Why ARC matters when a forwarder is in the middle
A mailing list, a ~/.forward file, and a bulk-mail relay all do the same destructive thing to authentication: they change the envelope-from to their own domain (breaking SPF alignment for the original sender), often rewrite the message body to add an unsubscribe footer (breaking the DKIM signature), and then re-sign the message with their own DKIM key. By the time the message reaches the final receiver, the receiver cannot tell whether it originally passed SPF and DKIM at the sending domain — because the visible SPF and DKIM now belong to the forwarder.
ARC (Authenticated Received Chain, RFC 8617) fixes that. Each hop in the chain that supports ARC signs an ARC-Seal over the running chain, an ARC-Message-Signature over the message body, and an ARC-Authentication-Results recording what SPF / DKIM / DMARC looked like at that hop. A receiver that trusts the ARC-sealing intermediary can honour the pre-forwarding verdicts even when its own SPF / DKIM / DMARC check on the incoming message would fail. The visualiser groups all the ARC headers by their i= instance number so you can see the chain build.
Two things to check when ARC is in play: the cv= value on each ARC-Seal (none on the first hop, pass on every subsequent hop; anything else means the chain is broken), and whether the receiver actually respected the chain — Google, Yahoo, and Microsoft 365 do; not every receiver does.
What the tool does not do
- No live DNS lookups. The tool works entirely from what is in the headers you paste; it does not query the current SPF / DKIM / DMARC records for the sending domain.
- No IP geolocation, WHOIS, or reputation scoring. The chain shows the hosts and IPs the headers already record; enriching those against external services would defeat the browser-only guarantee.
- No decoding of DKIM signature bodies. The visualiser reads the
d=,s=, and result — verifying the signature itself against the published key requires a DNS lookup, which the DNS Auth Checker does.
When you’re ready to fix a failing mechanism
- SPF fails point at the SPF Record Merger — the mechanical step of adding a new sending provider’s
include:token to your existing record without blowing the RFC 7208 10-lookup ceiling. - DKIM fails point at the DKIM Inventory — an enumeration of every well-known selector currently published for a domain, so you can confirm the failing one is still live and the message is not signed by a key you already rotated.
- DMARC fails point at the DNS Auth Checker — the live SPF / DKIM / DMARC check for a domain, scored against the Gmail, Yahoo, and Microsoft 365 bulk-sender requirements. If the header from is on your domain but nothing aligns, the fix is at the provider that is sending on your behalf; the checker confirms which of the three mechanisms is missing.
- If a specific bounce string in a
Diagnostic-Code:header is what surfaced the investigation, the SMTP Error Decoder maps common reply codes to the actual fix.