Email Header Analyzer — Received Chain, Hop Timings and SPF, DKIM and DMARC

Paste raw email headers to map the delivery path, time every hop and read the SPF, DKIM and DMARC results the receiving server recorded.

Paste a raw email header block and every Received field is read in the order the message actually travelled, with the delay between each hop, the first public IP address it was sent from, and the SPF, DKIM and DMARC results the receiving server recorded in its Authentication-Results header. Parsing happens in your browser, so nothing is uploaded.

Runs in your browser

Privacy: Runs entirely in your browser — headers are never uploaded
Reading order: Received fields are reversed, so hop 1 is the first machine that handled the message
Authentication: SPF, DKIM and DMARC are reported from Authentication-Results, not re-verified
Encoding: RFC 2047 encoded-word Subject and From lines are decoded
Cost: Free, unlimited, no sign-up

How to read a Received chain

Every mail server that touches a message adds one Received: field at the top of the header block, so the raw text reads backwards in time: the last line added is the first one you see. This tool reverses them, which is why hop 1 here is the machine that first handled the message and the final row is the server that delivered it to your mailbox. RFC 5321 §4.4 gives each field the same shape — from the host that connected, by the host that accepted, with the protocol used, id the local queue identifier, for the envelope recipient, and a timestamp after the final semicolon.

What the authentication results actually mean

Result	Meaning	Defined in
pass	The check ran and succeeded.	RFC 8601 §2.7
fail	The check ran and the message failed it.	RFC 8601 §2.7
softfail	SPF only. The record ends in ~all and the sender is not listed — suspicion, not an assertion.	RFC 7208 §8.4
neutral	The domain owner explicitly asserts nothing about this sender.	RFC 7208 §8.2
none	No policy was published, so there was nothing to evaluate.	RFC 8601 §2.7
temperror	A transient failure, almost always a DNS timeout. Inconclusive, not a failure.	RFC 7208 §8.6
permerror	The published record is malformed, or SPF exceeded its ten-lookup limit.	RFC 7208 §8.7

Reported from the receiving server's Authentication-Results field, not recomputed.

The three mechanisms answer different questions. SPF (RFC 7208) asks whether the connecting IP address is allowed to send for the envelope domain. DKIM (RFC 6376) asks whether a cryptographic signature over selected headers and the body still validates against a public key in DNS. DMARC (RFC 7489) asks whether *either* of those passed and aligned with the domain in the visible From: header — alignment is the part that makes the pair useful against spoofing, because SPF and DKIM on their own can both pass for a domain the reader never sees.

Using hop timings to find a delay

A message that arrived an hour late almost always spent that hour in one queue rather than a little at each stage. The delay column makes that obvious: look for the single hop measured in minutes among hops measured in seconds. Greylisting produces a characteristic gap of several minutes at the first external hop; a content scanner produces one in the middle; a full mailbox or a rate limit produces one at the last. Timestamps come from independent clocks, so small negative delays mean two servers disagree by a second or two and can be ignored.

Compare the DNS records for the sending domain when SPF or DMARC fails — the published policy is the other half of the story.
Use the WHOIS lookup on an unfamiliar sending domain: a domain registered days ago is the strongest single signal in a phishing assessment.
Run the originating address through what is my IP to see which network announces it and whether it appears on mail blocklists.

Frequently asked questions

Which Received header is the real sender?

The bottom one in the raw block, which appears as hop 1 here because the chain is reversed for reading. Each server prepends its own field, so the list grows downwards in time and upwards on screen. Only the fields added by servers you or your provider control can be trusted — anything below that point was written by machines the sender could have configured.

Can this tell me who sent a spoofed email?

It can tell you which IP address handed the message to your provider, and that address is genuine because your own mail server recorded it. It cannot tell you who was using that address. Everything above the sending server in the chain, including the display name and the From address, is text the sender chose.

Why do the hop delays not add up, or come out negative?

Every timestamp is written by a different machine using its own clock. A server a few seconds out of sync produces a zero or negative delay, which is a clock problem rather than a delivery one. Use the figures to find the one hop that took minutes while the rest took seconds — that is the queue worth investigating.

Does this verify SPF, DKIM and DMARC?

No, and no browser tool can. Verification needs live DNS lookups for the SPF record, the DKIM public key and the DMARC policy, plus the message body for the DKIM body hash. What is shown is the Authentication-Results field the receiving server wrote at delivery time under RFC 8601, which is the authoritative record of what actually happened.

What does spf=softfail mean?

The domain publishes an SPF record ending in ~all, and the sending address is not listed in it. The domain owner is saying they suspect the message is unauthorised but is not asking you to reject it. A record ending in -all would have produced fail instead. DMARC is what turns either into a delivery decision.

Why is the From domain different from the Return-Path?

The Return-Path is the envelope sender, where bounces go, and mailing-list and transactional providers legitimately set it to their own domain. The From is what you see. DMARC exists precisely because those two can differ: it requires that either SPF or DKIM align with the From domain, which is what stops the split being abused.

Are my headers uploaded anywhere?

No. This is a pure parser running as JavaScript on your device, which is why it is worth using on real mail — a header block routinely contains recipient addresses, internal hostnames, message subjects and mailing-list tokens.

How to use the email header analyzer

1Open the original message in your mail client and copy the raw headers — Gmail: More ▸ Show original; Outlook: File ▸ Properties ▸ Internet headers; Apple Mail: View ▸ Message ▸ All Headers.
2Paste everything down to the blank line that starts the message body.
3Read the delivery path from hop 1 downwards and look for the hop that took the longest.
4Check the Authentication panel for the SPF, DKIM and DMARC results the receiving server recorded.
5Compare the From domain against the Return-Path domain when you are assessing a suspicious message.

Sources & specifications

Embed this tool

Put the working email header analyzer on your own site. It runs in your visitors' browsers exactly as it does here — free, no account, nothing uploaded.

DNS LookupPull every DNS record for a domain at once, check SPF and DMARC, and compare four public resolvers.HTTP Header CheckerFollow every redirect, grade the security headers and read the cookie and caching settings.QR Code ReaderDecode a QR code from an image or your camera, and check the link before you open it.Quoted-Printable Encoder & DecoderEncode and decode quoted-printable, the MIME format used in email bodies and headers.Content Security Policy GeneratorBuild a CSP header from common presets, with each directive explained.HTTP Security Header AnalyserPaste response headers and get a security grade, with what is missing and why it matters.

Last updated 11 Sept 2026

More network tools