Paste the raw headers of a message to rebuild its delivery path hop by hop, read the SPF, DKIM and DMARC verdicts, check whether those identities actually align with the visible sender, and see the spoofing signals a filter would react to. Everything is parsed in your browser.
Gmail: ⋮ → Show original. Outlook: File → Properties → Internet headers. Apple Mail: View → Message → All Headers. Copy the whole block — the trace is only complete if you take it from the mailbox that received the message.
{{ note }}
Repeated single-instance headers: {{ report.duplicates.map(item => item.name + ' ×' + item.count).join(', ') }}. RFC 5322 allows one of each, and clients disagree about which copy to show.
No Received headers in this paste — the trace cannot be rebuilt.
| # | Delay | Time | From | By | Transport |
|---|---|---|---|---|---|
| {{ hop.number }} | — {{ delay(hop.delay) }} | {{ hop.timestamp ? isoTime(hop.timestamp) : '—' }} | {{ hop.from || '—' }} {{ hop.ip }} | {{ hop.by || '—' }} | {{ hop.protocol || '—' }} TLS no TLS marker |
Hops are listed oldest first — the reverse of how they appear in the source, where each server prepends its own Received line. A delay is the gap between one server's own stamp and the next one's, so it includes queueing on the receiving side.
{{ auth.evaluated.fromDomain || '—' }}d={{ auth.evaluated.dkimDomain }} no passing signature to align relaxed · org domain estimated strict match{{ auth.evaluated.spfDomain }} no passing SPF identity relaxed · org domain estimated strict matchDMARC passes when at least one of these two lines is aligned and its underlying check passed. Relaxed alignment compares organizational domains, which needs the Public Suffix List; this page uses a compact heuristic instead, so relaxed matches are labelled as estimated. Strict matches are exact and need no guessing.
Every server that touches a message prepends a Received line, so the header block is a delivery log written from the bottom up. Reading it answers two different questions: where did this message spend its time, and is the sender who it claims to be. This page answers both from a single paste.
Authentication is three separate mechanisms that people routinely conflate. SPF checks whether the connecting IP is allowed to send for the envelope domain in Return-Path — not the address your reader sees. DKIM verifies a signature over selected headers and the body, made by the domain in the d= tag. DMARC is the part that ties either result back to the visible From: header through identifier alignment: a pass means SPF or DKIM succeeded and its domain lines up with the one in From. That is why a message can show spf=pass and still fail DMARC — the SPF pass belonged to someone else's domain.
The alignment block re-derives that decision from the headers instead of repeating what the server reported, which is what makes a forwarded message readable: mailing lists rewrite subjects and footers, DKIM breaks, SPF now authenticates the list rather than the author, and DMARC fails on a message nobody forged. The trace above usually shows exactly that.
The header table explains the common fields in plain language, decodes RFC 2047 encoded words, and keeps the raw value beside the decoded one. Findings are flagged by category — spoofing signals, weak DKIM configuration, clock skew, slow hops — rather than rolled into a single invented score.
Privacy: parsing is 100% client-side. The headers you paste are never uploaded, logged or stored, and no DNS lookup is performed — every verdict shown here comes from the text itself. Because of that, this tool reads the authentication results your receiving server already computed; it cannot re-verify a DKIM signature without fetching the public key.
