# 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.

**URL:** https://convertto.tech/t/email-header-analyzer
**Category:** Network Tools (https://convertto.tech/c/network-tools)
**Privacy:** Runs entirely in the browser; no upload
**Cost:** Free, no sign-up
**Last updated:** 2026-09-11

## Key facts

- **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.

> **Only the top of the chain is evidence** — A sender can write anything into the headers of a message before sending it, including a fake Received chain. The fields added by your own provider are trustworthy; everything below the first server you control is a claim. That is why the originating IP is taken from the earliest public hop rather than from a header like X-Originating-IP, which the sender can set freely.

## 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](https://convertto.tech/t/dns-lookup) for the sending domain when SPF or DMARC fails — the published policy is the other half of the story.
- Use the [WHOIS lookup](https://convertto.tech/t/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](https://convertto.tech/t/what-is-my-ip) to see which network announces it and whether it appears on mail blocklists.

## How to use

1. Open 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.
2. Paste everything down to the blank line that starts the message body.
3. Read the delivery path from hop 1 downwards and look for the hop that took the longest.
4. Check the Authentication panel for the SPF, DKIM and DMARC results the receiving server recorded.
5. Compare the From domain against the Return-Path domain when you are assessing a suspicious message.

## FAQ

### 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.

## Sources

- [RFC 5322 — Internet Message Format (trace fields, §3.6.7)](https://www.rfc-editor.org/rfc/rfc5322) — IETF
- [RFC 5321 — Simple Mail Transfer Protocol (Received, §4.4)](https://www.rfc-editor.org/rfc/rfc5321) — IETF
- [RFC 8601 — Authentication-Results Header Field](https://www.rfc-editor.org/rfc/rfc8601) — IETF
- [RFC 7208 — Sender Policy Framework (SPF)](https://www.rfc-editor.org/rfc/rfc7208) — IETF
- [RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures](https://www.rfc-editor.org/rfc/rfc6376) — IETF
- [RFC 7489 — Domain-based Message Authentication, Reporting and Conformance (DMARC)](https://www.rfc-editor.org/rfc/rfc7489) — IETF
- [RFC 8617 — Authenticated Received Chain (ARC)](https://www.rfc-editor.org/rfc/rfc8617) — IETF
- [RFC 2047 — MIME Part Three: Message Header Extensions for Non-ASCII Text](https://www.rfc-editor.org/rfc/rfc2047) — IETF

## Related tools

- [DNS Lookup](https://convertto.tech/t/dns-lookup): Pull every DNS record for a domain at once, check SPF and DMARC, and compare four public resolvers.
- [HTTP Header Checker](https://convertto.tech/t/http-header-checker): Follow every redirect, grade the security headers and read the cookie and caching settings.
- [QR Code Reader](https://convertto.tech/t/qr-code-reader): Decode a QR code from an image or your camera, and check the link before you open it.
- [Quoted-Printable Encoder & Decoder](https://convertto.tech/t/quoted-printable): Encode and decode quoted-printable, the MIME format used in email bodies and headers.
- [Content Security Policy Generator](https://convertto.tech/t/csp-generator): Build a CSP header from common presets, with each directive explained.
- [HTTP Security Header Analyser](https://convertto.tech/t/http-header-analyser): Paste response headers and get a security grade, with what is missing and why it matters.
- [Format Validator](https://convertto.tech/t/validator-suite): Validate emails, UUIDs, IP addresses, credit card numbers, IBANs and semver strings.
- [Open Graph Preview](https://convertto.tech/t/open-graph-preview): Render your share card the way each platform really draws it, with the og:image measured.