Where does the SPF/DKIM/DMARC result come from?

From the Authentication-Results header (and Received-SPF) that the receiving mail server adds. This tool reads the verdict the server already recorded — it does not re-run DNS lookups or re-verify the DKIM cryptographic signature itself.

Is my email content sent anywhere?

No. Parsing happens entirely in your browser with JavaScript. Nothing you paste — headers or otherwise — is transmitted to any server.

Why are the Received hops shown oldest first?

Mail servers prepend each Received header, so the raw list runs newest-to-oldest. The analyzer reverses them so you read the journey in the order it actually happened, from the sender's first server to your inbox.

What does a DMARC 'pass' actually require?

DMARC passes when the message has an aligned, passing SPF or DKIM result — meaning the authenticated domain matches the visible From domain. A DMARC fail with SPF/DKIM passing usually signals an alignment problem, often from a mailing list or forwarder.

What do large gaps between hops mean?

A long delay between two Received timestamps means the message sat in a queue at that server, commonly due to greylisting, rate limiting, or a backlog. Occasional gaps are normal; a consistently slow hop is worth investigating.

Email Header Analyzer

Every email carries a hidden audit trail in its headers: which servers handled it, when, and whether the sender’s domain authenticated correctly. This analyzer parses that block locally and surfaces the parts that matter for deliverability and spoofing investigations.

How it works

Headers follow a simple Name: value format, but a single logical header can be folded across several lines where continuation lines begin with whitespace. The analyzer first unfolds these, stopping at the first blank line (which marks the start of the message body), so multi-line Received and Authentication-Results headers are reassembled correctly.

It then extracts three things:

Authentication verdicts. SPF, DKIM, and DMARC results are pulled from the Authentication-Results header your receiving server stamped on, falling back to Received-SPF for SPF. Each is classified as pass, fail, softfail, neutral, none, or error and colour-coded.
Identity fields. From, To, Subject, Date, Return-Path, Message-ID, and X-Mailer / User-Agent — the headers most useful when checking whether a message is genuine.
The hop chain. Every Received header is parsed for its from, by, and with parts plus a timestamp. Because servers prepend Received lines, the list is reversed into chronological order and the gap between consecutive timestamps is shown as a per-hop delay.

Reading the authentication panel

The three checks answer different questions:

SPF asks whether the sending IP is authorised to send for the envelope (Return-Path) domain.
DKIM asks whether the message carries a valid cryptographic signature from the signing domain.
DMARC ties them together: it passes only when SPF or DKIM passes and the authenticated domain aligns with the visible From domain.

A common spoofing pattern is From: [email protected] while SPF and DKIM authenticate a completely unrelated domain — DMARC will report fail, which is the headline signal to watch.

Tips

Always copy from the top of the raw source down to the first empty line; that is the complete header block.
A long delay on one hop usually means the message was queued (greylisting or rate limiting) rather than anything malicious.
The verdicts reflect what the receiving server decided at delivery time. If you need to re-test a live domain’s policy, use a dedicated SPF/DKIM/DMARC record builder to inspect the current DNS records.