Paste raw email headers: every hop with its delay, sender IPs, SPF, DKIM and DMARC results
Runs in your browser. Nothing you type is sent anywhere. Updated on 24 Oct 2026.An email header analyzer reads the raw headers of a message and lays out its route: every Received hop from oldest to newest, the delay between each, the sending server's IP, and the SPF, DKIM and DMARC results the receiving server recorded. A 4-hop message usually arrives in under a minute; hours mean a queue.
Copy the raw headers from your mail app: in Gmail, Show original; in Outlook, File, Properties, Internet headers.
Paste them into the box; they are read in this page as soon as you paste.
Read Route for each Received hop, oldest first, with its delay and the first public IP.
Read Alignment and Authentication headers for the SPF, DKIM and DMARC results.
Press Copy analysis to copy the summary.
Paste the full headers of a message, or the whole .eml file, and the page reads them in your browser. Nothing is looked up and nothing is sent.
The route. Each mail server adds a Received line at the top as it passes the message on, so the headers read newest first. The page turns them around and lists each hop oldest first: the server it came from with the address it connected from, the server that received it, the protocol, the time in UTC, and the delay since the hop before. Folded lines are joined first, as RFC 5322 section 2.2.3 describes, and the date is taken from after the last semicolon. A negative delay is flagged, because it means a server's clock is wrong, not that mail travelled back in time.
The verdicts. SPF, DKIM and DMARC are read from the topmost Authentication-Results header, the one your own provider wrote, using the RFC 8601 layout, with Received-SPF as a fallback. Lower Authentication-Results headers are listed too, since anyone could have added those before the message arrived. ARC seals from forwarders and mailing lists are shown with their chain verdicts, and each DKIM-Signature with its domain, selector and signed headers.
Alignment. DMARC passes only when the From domain matches the Return-Path domain (for SPF) or a DKIM signing domain. The page compares them and says whether they are identical, share an organisation, or differ, and it warns when replies go to another domain.
What it does not do. It does not verify DKIM signatures, which needs the public key from DNS, and it does not geolocate or blocklist the addresses; links take the first public IP to the Blacklist Checker and WHOIS Lookup if you want that. Organisation matching uses the last two labels of a domain (three for names like co.uk), close to but not the full public suffix list.
A sample header written for this page, with invented names and addresses, shows every part at once.
In Gmail, open the message, choose the three-dot menu and Show original. In Outlook on the desktop, open the message, then File, Properties, and copy the Internet headers box. In Apple Mail, choose View, Message, All Headers. Copy everything from the first Received line down and paste it here.
Each server adds one at the top when it takes the message, so the bottom Received line is the oldest. The page reverses them and shows each hop oldest first with the sending server, its IP address, the receiving server and the time. Only the top lines, written by your own provider, are fully trustworthy.
Look at the Delay column. The hop with the big number is where the message waited: a sender's outbound queue, a greylisting receiver that asked it to retry, or a spam filter. A few seconds per hop is normal. A negative delay means one server's clock is wrong, so the delays next to it are unreliable.
The receiving server found that neither SPF nor DKIM passed for a domain matching the visible From address. Either the message was forged, or a real service is sending for the domain without being set up in its SPF record or signing with its DKIM key. The Alignment section shows which domains were compared.
Usually. The first public address in the oldest Received lines is normally the server that sent the message; private addresses such as 10.x or 192.168.x belong to the sender's own network. Webmail often hides the user's own address. Lines added before your provider's servers can be forged by a spammer.
No. The headers are parsed in the page with JavaScript, with no request of any kind, and they are not saved; leaving the page forgets them. The IP addresses are not looked up. If you want to check one, the links open the Blacklist Checker or WHOIS Lookup, which do send that address.
Still stuck? Ask about Email Header Analyzer and anybody who knows can answer. No account needed.
On the related tools: SPF Record Generator – Write an SPF record for your mail providers and see how many lookups it uses · DMARC Record Generator – Build a DMARC record step by step, from p=none reporting to p=reject.