Skip to main content
Start free

Free · no signup

Email Header Analyzer

Paste raw message headers and replay the delivery: every Received hop with its delay, the SPF, DKIM and DMARC verdicts, and the classic spoofing tells.

Headers are parsed in memory for this request only — never stored, never logged.

Every email carries its own delivery log

The From line, the Subject, even the Date are just claims typed by the sender's software. The Received headers are different: every mail server that handles a message stamps one on top as it passes, like a customs stamp in a passport. Reading them bottom-up replays the journey — the machine that first injected the message, each relay that carried it, and the moment of every hand-off. That's why the timeline above lists hops origin-first: the bottom Received header is where the story starts.

The per-hop delays are the diagnostic gold. A healthy hand-off takes a second or two; a hop that suddenly costs minutes points at greylisting (a receiver deliberately deferring first contact from an unknown sender), a queue backlog on an overloaded relay, or a struggling server retrying its neighbour. When someone says "your email took an hour to arrive", the Received chain names the exact machine that ate the hour. Slow is only one failure mode, though — silently junked is the other, and our guide to why emails go to spam covers that side of the story.

The authentication trio proves three different things. SPF asks whether the sending server was allowed to use the envelope sender's domain; DKIM verifies a cryptographic signature over the message; DMARC ties both back to the domain a human actually sees in From — and that tie is alignment. A message can pass SPF and DKIM for attacker-controlled domains and still fail DMARC, because neither passing domain matched the From domain. If the trio is new to you, start with SPF, DKIM and DMARC explained; and if you send any volume at all, note that the Gmail and Yahoo sender requirements now expect all three to be in order.

The classic spoofing tells are all visible in headers: a Reply-To that quietly redirects responses to a different domain, a DKIM d= that has nothing to do with the claimed sender, and look-alike domains built to survive a glance (paypal.com-verify.example.com is not paypal.com). One honest caveat: only the Received headers added by servers you trust are trustworthy — everything below the first hop your own provider stamped can be forged by the sender, "Received" lines included. And your own domain is only as safe as its DNS: SPF, DKIM and DMARC records that were right last quarter can be broken by one careless edit. A CompleteStatus email security monitor re-checks those records as often as twice a day and alerts you if your SPF or DMARC record disappears — start monitoring free.

Frequently asked questions

In Gmail, open the message, click the three-dot menu and choose "Show original" — copy everything on that page. In Outlook on the web (and new Outlook), open the message and choose the three-dot menu, then View, then "View message source"; in classic desktop Outlook it is File, then Properties, then "Internet headers". Paste the whole block here — the analyzer stops reading at the first blank line, so including the body does no harm.

Every server that handles a message stamps a Received header on top, so reading them bottom-up replays the delivery route: which machine originally sent it, which relays carried it, and when each hand-off happened. The timestamps expose exactly where a slow delivery lost its time, and the first hop shows the network the message really came from — regardless of what the From header claims.

The receiving server records them in the Authentication-Results header. SPF checks whether the sending server's IP is authorized by the envelope sender's domain; DKIM verifies a cryptographic signature over the message; DMARC checks that at least one of the two passed for the domain shown in From. "pass" is good; "softfail" and "neutral" are shrugs; "fail" and "permerror" mean the message flunked that check.

Look for a Reply-To domain that differs from the From domain (the classic business-email-compromise tell), a DKIM d= domain unrelated to the From domain, SPF evaluated against a completely different Return-Path, look-alike domains (paypal.com-verify.example.com is not paypal.com), and a first Received hop from a network that has nothing to do with the claimed sender. This analyzer flags all of those automatically.

No. Your headers are processed in memory for this single request only and the result is rendered straight back to you — nothing is ever stored, logged, queued or sent to any third party. That is also why this tool has no shareable result link: there is nothing saved to link to.