Email Header Analyzer
Paste the raw headers of an email to trace its delivery path hop-by-hop, see how long each step took, and check the SPF, DKIM and DMARC results. Everything runs in your browser — nothing is uploaded.
This analyzer reads the standard Received, Authentication-Results and Received-SPF headers. Times come from each server's own clock, so small skews between hops are normal.
What is an email header?
Every email carries a block of headers — metadata your mail client usually hides. They record who sent the message, the chain of servers it passed through, timestamps at each step, and the results of authentication checks. Reading them is the fastest way to answer questions like "where did this really come from?", "why was it slow?", or "is this a spoof?".
How to read email headers
The most useful part is the Received: chain. Each mail server that handles the message prepends its own Received line, so the list reads newest-first — the top line is the server closest to your inbox and the bottom is closest to the original sender. This tool reverses them into chronological order, draws the journey from origin to delivery, and shows the time gap between each hop so you can spot delays.
What do SPF, DKIM and DMARC mean?
- SPF (Sender Policy Framework) checks that the server which sent the mail is authorised to send for the From domain.
- DKIM (DomainKeys Identified Mail) verifies a cryptographic signature, proving the message wasn't altered in transit and genuinely came from the signing domain.
- DMARC ties SPF and DKIM to the visible From address and tells receiving servers what to do when a check fails (none, quarantine, or reject).
A pass on all three is a strong signal the mail is legitimate. A fail can mean spoofing — or simply a misconfigured sender — so read it alongside the delivery path.
How to find the raw headers
- Gmail: open the message → the ⋮ menu → Show original → copy the whole page.
- Outlook (desktop): open the message → File → Properties → copy the Internet headers box.
- Apple Mail: select the message → View → Message → All Headers.
- Yahoo: open the message → More → View raw message.
A worked example: three hops from sender to inbox
Here is a shortened Received chain as you would see it in the raw source, newest line first:
Received: from mx.example-mail.net (mx.example-mail.net [203.0.113.10])
by inbox.example.org with ESMTPS; Tue, 14 Oct 2026 08:02:17 +0000
Received: from out3.sender-platform.example (out3.sender-platform.example [198.51.100.7])
by mx.example-mail.net with ESMTPS; Tue, 14 Oct 2026 08:02:15 +0000
Received: from [10.0.4.21] (unknown [192.0.2.44])
by out3.sender-platform.example with ESMTPSA; Tue, 14 Oct 2026 08:02:14 +0000Read it from the bottom up. The message started on a device with the private address 10.0.4.21, connecting from the public address 192.0.2.44, and was accepted by the sending platform's outbound server using an authenticated session (the ESMTPSA keyword, where the trailing A means the client logged in). One second later it reached the recipient's mail exchanger, and two seconds after that it was handed to the final inbox server. Three hops, three seconds: a normal delivery. If the gap between two lines had been forty minutes, that hop is where the delay happened, and the server named on the left of by is the one to ask about it.
Header fields worth checking, and what each one tells you
| Header | What it means | What to look for |
|---|---|---|
From | The display name and address shown in your client. It is free text and can say anything. | Compare the domain after the @ with the domains in Return-Path and the DKIM signature. |
Return-Path | Where bounces go. This is the envelope sender that SPF is actually checked against. | A completely unrelated domain is common for newsletters, but suspicious for a message claiming to be from your bank. |
Reply-To | Where your answer is sent if you press reply. | If it differs from From, replies go somewhere else. Phishers rely on this when sending through a hijacked account. |
Message-ID | A unique identifier set by the first server or client. | The domain in it usually reveals the real sending system, even when From is spoofed. |
Authentication-Results | The receiving server's verdict on SPF, DKIM and DMARC. | Only trust the copy added by your own provider; earlier copies can be forged by the sender. |
X-Mailer / User-Agent | The program that composed the message. | A bulk-mailing tool on a message that claims to be a personal note is a mismatch worth noticing. |
List-Unsubscribe | A machine-readable opt-out link or address. | Its presence means the sender runs a real list; its absence on commercial mail is a bad sign. |
Why a legitimate message can still fail SPF or DKIM
A fail is not automatic proof of forgery. The most common innocent cause is forwarding: when a university or old-job address forwards mail to your main inbox, the forwarding server is not in the original domain's SPF record, so SPF fails even though the message is genuine. DKIM survives forwarding as long as nothing in the message changes, but mailing lists often add a footer or a subject prefix, which breaks the signature. Large providers mitigate this with ARC (Authenticated Received Chain) headers, which let the forwarder vouch for the results it saw before it altered the message. A third cause is a sender who simply never set up authentication, which is sloppy rather than malicious. The pattern that should worry you is a fail on a message whose From domain belongs to a company that definitely does publish SPF and DKIM, such as a major bank, combined with a Return-Path on an unrelated domain and a link you were not expecting. Our guide on spotting a phishing email walks through that judgement step by step.
What headers cannot tell you
Headers show the servers a message passed through, not the person behind it. The IP address in the lowest Received line is usually the sender's mail provider, not their home connection, and webmail services such as Gmail and Outlook.com deliberately omit the user's own address. Timestamps come from each server's clock, which may be set wrongly, and some providers strip or rewrite internal hops before delivery. Headers also say nothing about the content: an email can pass SPF, DKIM and DMARC perfectly and still be a scam sent from a freshly registered look-alike domain. Treat the analysis as one input alongside the message itself. For a slower, line-by-line explanation of every field, see how to read email headers.
Is this analyzer private?
Yes. The headers you paste are parsed entirely on your device with JavaScript — they are never sent to, logged by, or stored on our servers. That's the same privacy-first principle behind our disposable email service, our disposable domain checker, and our password generator.
Testing your own email's headers?
If you build software that sends mail and want to verify SPF/DKIM/DMARC end-to-end automatically, MailboxTemp offers a free disposable email API and an open-source npm client — generate a throwaway inbox, send to it from your app, then read back the delivered message and its headers from your test code.