Headers are the flight recorder
Every message carries its own delivery log. Each server that touches it prepends a Received header, the receiving server writes its authentication verdicts into Authentication-Results, and the sending platform leaves identifying headers it never mentions in its marketing. When a message arrives late, lands in spam, or looks suspicious, the headers usually contain the answer — the problem is that raw headers are unreadable, fifty-plus folded lines in reverse chronological order.
The analyzer unfolds them into four views:
- Delivery timeline. The Received chain in chronological order, with the time spent at each hop computed from the timestamps. "The message took 4 hours" becomes "it sat 3h 52m at hop 3, a relay inside the sender's own infrastructure" — which is the difference between blaming Gmail and fixing a queue.
- Authentication board. SPF, DKIM and DMARC results as the receiver recorded them, with the domains each verdict applies to. This is where DMARC alignment failures become visible: dkim=pass for
esp-platform.comdoes not help a From address atyourbrand.com, and the analyzer flags exactly that case. - Identity and alignment. From, Return-Path, Reply-To and Message-ID domains side by side. A Return-Path on the ESP's domain is normal bounce handling; a Reply-To pointing somewhere unexpected earns a warning.
- Fingerprints and compliance. A curated map of platform headers —
X-SG-EID(SendGrid),X-Mailgun-*,X-MC-*(Mailchimp/Mandrill),X-SES-*,X-Klaviyo-*and a dozen more — plus List-Unsubscribe and the RFC 8058 one-click header that Gmail and Yahoo now require from bulk senders.
Reading it like an investigator
Received headers deserve measured trust. The ones written by your own receiving server are reliable; everything below them was written by other machines and can be fabricated wholesale. Spam sometimes carries invented hops designed to shift blame. The reliable anchor is the top of the chain — your provider's own entries — and the analyzer's negative-delay flags often mark exactly where fabricated timestamps meet real ones.
The Authentication-Results header has the same property: only the topmost one, added by your receiving provider, is authoritative. ARC headers, when present, mean a forwarder re-sealed earlier verdicts — common for mailing lists and account forwarding, and the analyzer notes it rather than treating forwarded mail as suspicious by default.
Diagnosing your own mail
Send yourself a message through your normal platform, view the raw source at the receiving end, and paste it here. Three findings are worth acting on the same day: a DKIM signature whose d= is the platform's domain instead of yours (fixable — publish the platform's DKIM records under your own domain, then verify with the DKIM checker), a missing one-click unsubscribe header if you send bulk, and any authentication verdict other than pass — trace those back with the SPF and DMARC checkers to see whether the DNS side or the sending side is at fault.
Scope, honestly
The analyzer parses what the headers say; it cannot verify DKIM signatures cryptographically (that requires fetching keys and hashing the exact signed bytes, which a paste cannot reproduce), and it cannot tell you why a filter made its decision — headers record verdicts, not reasoning. Treat it as the fastest way to locate a problem, then use the record-level tools to fix it. For the DNS side of the same story, the full email DNS check audits your domain's records in one pass.
Frequently asked questions
Where do I find the raw headers to paste?
Gmail: open the message → three-dot menu → Show original. Outlook (web): three-dot menu → View → View message source. Apple Mail: View → Message → All Headers. Yahoo: More → View raw message. Copy everything from the top down to the first blank line (including the body is fine — the analyzer stops at the blank line).
Is it safe to paste headers with private information?
The analysis runs entirely in your browser: the parser is JavaScript on this page, there is no API call, and nothing you paste is transmitted or stored anywhere. Headers do contain personal data — addresses, server names, sometimes your IP — which is exactly why this tool is built client-side. You can verify with your browser's network tab: analyzing triggers no request.
How does the analyzer compute per-hop delays?
Every server that handles a message prepends a Received header with a timestamp. Reading them bottom-up gives the chronological path, and the difference between consecutive timestamps is the time spent at each hop. A delay of minutes or hours at one hop locates a slow queue; a negative delta means a server clock is wrong — or a header was forged, since spammers write fake Received lines.
What do the SPF, DKIM and DMARC verdicts in headers mean?
The Authentication-Results header records what the receiving server concluded when the message arrived: spf=pass means the sending IP was authorized by the envelope domain, dkim=pass means the signature verified (with header.d naming the signing domain), dmarc=pass means one of those aligned with the visible From domain. These are the receiver's actual verdicts for this specific message — more definitive than any DNS lookup, which only shows what should happen.
Why does the analyzer flag a Reply-To that differs from From?
Because it is one of the oldest phishing patterns: display a trusted From, harvest replies at an unrelated address. Legitimate uses exist — support desks, marketing platforms answering from a CRM — so the flag is a prompt to look, not an accusation. Combined signals matter: a mismatched Reply-To plus failing DMARC plus a Message-ID from a third domain is a very different picture than any one alone.