Last updated: October 10, 2026 · By Ned Walsch

Email Header Analyzer

An email header analyzer turns the hidden lines at the top of a message into a route and a set of checks. Paste the full header below, or drop an .eml file, and this free tool lists every Received hop oldest first with its IP addresses, TLS and delays; reads the SPF, DKIM and DMARC results your mail provider recorded; compares the From, Reply-To and Return-Path domains; and sums it up as red, caution and good signals for phishing review. Parsing happens in your browser: nothing is uploaded, and the one optional network request, a DNS lookup of the sender’s SPF and DMARC records, runs only if you click it. Read the route from the bottom up, because each mail server adds its Received line at the top and must not alter the ones already there RFC 5321, Simple Mail Transfer Protocol, Oct 2008, sections 3.6.3 and 3.7.2. What a header can’t do is name a person: it shows servers and networks, the lines added before your provider received the message can be forged, and mail written in webmail starts at the provider’s server, not the sender’s device. DMARC itself was updated in May 2026 as RFC 9989 RFC 9989, DMARC, May 2026 (Proposed Standard).

Private by design: the header is parsed by JavaScript in this page and never uploaded. Headers contain your own address and your provider’s internal server names, so remove them before you share an export. The optional DNS lookup further down sends only domain names, and only when you click it.

Which header lines matter, at a glance?

Every message carries a header block above the body. These are the lines this analyzer reads, what each one tells you, and whether the sender can fake it.

Header line	What it tells you	Can the sender fake it?
Received (top lines)	Which server handed the message to your provider, its IP address, protocol and time.	No. Your own provider writes them.
Received (lower lines)	The earlier route the sending side reports, often including its internal servers.	Yes. Anything below your provider’s line can be invented.
Authentication-Results	The SPF, DKIM and DMARC results a receiving server recorded.	The topmost one from your provider: no. Others can be. RFC 8601 says receivers should trust it only from a trusted source.
From	The author address your mail app shows.	Yes, unless DMARC passes for that domain.
Reply-To	Where your reply would go.	Yes, freely.
Return-Path	The envelope sender that receives bounces; SPF checks this domain.	Yes, but SPF then tests it against the sending IP.
DKIM-Signature	The signing domain (`d=`) and key selector (`s=`).	Anyone can add one. Only a verified signature (dkim=pass) counts.
ARC-Seal / ARC-Authentication-Results	Results recorded by forwarders and mailing lists along the way.	Only as trustworthy as the forwarder that sealed them.
Message-ID, X-Mailer, User-Agent	Clues about the sending software and service.	Yes.

Sources: Received lines are prepended by each relay, which must not alter the ones already there RFC 5321, Simple Mail Transfer Protocol, Oct 2008, sections 3.6.3 and 3.7.2; Authentication-Results trust rules RFC 8601, Authentication-Results header field, May 2019; DKIM signer identity RFC 6376, DKIM Signatures, Sep 2011; SPF identities RFC 7208, SPF, Apr 2014, sections 2.2 and 2.6.

How do you trace an email sender?

To trace an email sender, read the Received lines from the bottom up. Each mail server that relays a message adds its own Received line at the top and must not change the ones already there RFC 5321, Simple Mail Transfer Protocol, Oct 2008, sections 3.6.3 and 3.7.2, so the bottom line is the oldest and the top line is the newest. The analyzer above does this ordering for you.

Get the full original header, not the short From/To/Subject summary (steps for each mail app are in the next section).
Paste it above or drop the saved .eml file.
Find the hand-off to your provider. The “IP that delivered it” is the address your provider’s SPF check recorded (for example designates 198.51.100.41 as permitted sender or sender IP is 203.0.113.10). Your provider wrote that, so the sender could not fake it.
Look further down the route. The earliest public IP is the best guess for where the message entered the mail system. Treat it as a claim: the sending side writes those lower lines.
Pivot. Each public IP links to the IP lookup (network owner, abuse contact, approximate region) and each domain to Domain OSINT (registration, DNS, certificates).
Check authentication. A DMARC pass means the From domain really sent it; a DMARC fail plus a Reply-To elsewhere is the classic spoofing pattern.

Private addresses such as 10.x.x.x, 192.168.x.x and 172.16–31.x.x (RFC 1918) and the shared range 100.64.0.0/10 used for carrier-grade NAT appear inside organisations and mobile networks and can’t be looked up publicly IANA IPv4 Special-Purpose Address Registry (updated 9 Oct 2025). The tool labels them, along with the documentation ranges used in examples IANA IPv6 Special-Purpose Address Registry (updated 9 Oct 2025).

How do I find the full email header in Gmail, Outlook, Apple Mail, Yahoo and Proton Mail?

Each mail service hides the header behind a menu. These steps come from each vendor’s own help page, read on 10 October 2026.

Mail app	Steps to see the full header	Vendor source
Gmail (web)	Open the message → More (three dots, next to Reply) → Show original → Copy to clipboard. Gmail’s page does not give steps for the mobile app.	Gmail Help: Trace an email with its full header (read 10 Oct 2026)
Outlook: new Outlook for Windows	Open the message → More actions → View → View message details.	Microsoft Support: View internet message headers in Outlook (read 10 Oct 2026)
Outlook: classic Outlook	Open the message → File → Info → Properties; the header is in the Internet headers box.	Microsoft Support: View message headers, classic Outlook (read 10 Oct 2026)
Outlook on the web / Outlook.com	Microsoft’s page has a separate tab for this; we could not read its steps, so they are not repeated here.	Microsoft Support: View internet message headers in Outlook (read 10 Oct 2026)
Apple Mail (Mac)	View → Message → All Headers; Default Headers switches back. (We could read only Apple’s French-language page for Mail 14, which says “Présentation > Message > Tous les en-têtes”; Gmail Help also names Apple Mail’s “All Headers”.)	Apple Support: Afficher des en-têtes détaillés dans Mail sur Mac (French edition, Mail 14; read 10 Oct 2026) Gmail Help: Trace an email with its full header (read 10 Oct 2026)
Yahoo Mail	Open the message → More options icon → View Raw Message.	Yahoo Help: Find delivery delays and identify sender in New Yahoo Mail (read 10 Oct 2026)
Proton Mail (web)	Open the message → More (three dots) → View headers; the pop-up can download the header as a .txt file.	Proton Support: How to check email headers in Proton Mail (read 10 Oct 2026)
Proton Mail (iOS)	Open the message → three-dot menu → More options → View Headers.	Proton Support: How to check email headers in Proton Mail (read 10 Oct 2026)

Copy everything the view shows. If you only copy the From, To and Subject lines, there are no Received or Authentication-Results lines to analyse. Google’s page also points to its own analyzer, the Admin Toolbox Messageheader Gmail Help: Trace an email with its full header (read 10 Oct 2026); see the comparison below.

What do SPF, DKIM and DMARC results mean?

The receiving server records its checks in an Authentication-Results header, one line per method, such as spf=pass, dkim=fail or dmarc=pass RFC 8601, Authentication-Results header field, May 2019. Each check answers a different question:

SPF asks whether the server that connected is allowed to send for the envelope-sender (Return-Path) domain. It checks the MAIL FROM and HELO identities, not the From line you see RFC 7208, SPF, Apr 2014, sections 2.2 and 2.6.
DKIM checks a cryptographic signature. Verifying it shows the signed content has not changed since the domain in d= signed it. The public key is published in DNS at selector._domainkey.domain. The signer does not have to match the From address, and a valid signature does not by itself make the signer trustworthy RFC 6376, DKIM Signatures, Sep 2011.
DMARC ties the two to the From line. A message passes when SPF or DKIM passes for a domain that is aligned with the From domain: identical (strict) or sharing the same organisational domain (relaxed). The domain owner publishes a policy in a TXT record at _dmarc.domain: p=none (no preference), p=quarantine (treat failures as suspicious) or p=reject RFC 9989, DMARC, May 2026 (Proposed Standard). RFC 9989, published in May 2026, obsoletes the earlier Informational RFC 7489 RFC 7489, DMARC, Mar 2015 (Informational; now obsolete).

Result	SPF	DKIM	DMARC
pass	The sending server is authorised for the envelope-sender domain.	A signature verified for the `d=` domain.	SPF or DKIM passed for a domain aligned with From.
fail	The domain says this server is not authorised.	A signature was present but did not verify.	No aligned SPF or DKIM pass.
softfail	“Probably not authorised”: a weak fail.	–	–
neutral	The domain makes no statement about this server.	Signature could not be processed (syntax errors).	–
none	No SPF record found.	The message was not signed.	No DMARC policy published.
temperror / permerror	Temporary (usually DNS) error / record could not be interpreted.	Temporary / permanent verification problem.	Temporary / permanent problem.

SPF and DKIM meanings follow RFC 7208 section 2.6 and RFC 8601 RFC 7208, SPF, Apr 2014, sections 2.2 and 2.6 RFC 8601, Authentication-Results header field, May 2019. Some receivers add their own methods: compauth is Microsoft’s composite result, and arc= reports the Authenticated Received Chain, which records the results forwarders and mailing lists saw. ARC is Experimental, and a receiver may accept a forwarder’s results only as a local policy choice RFC 8617, Authenticated Received Chain (ARC), Jul 2019 (Experimental).

The optional DNS button looks up today’s SPF and DMARC records through Cloudflare’s JSON API for DNS over HTTPS Cloudflare docs: DNS over HTTPS, JSON format (read 10 Oct 2026). Cloudflare says it deletes its public resolver logs within 25 hours and does not store users’ IP addresses in non-volatile storage, apart from a small packet sample used for troubleshooting Cloudflare docs: 1.1.1.1 Public DNS Resolver privacy commitments (read 10 Oct 2026). Records can change after a message is sent, so they may differ from what the receiver checked.

Can you trace an email to a person or a location?

Usually not to a person, and only roughly to a place. Here is what a header can and can’t tell you:

No names or street addresses. A header lists servers, IP addresses and domains. The display name in From is typed by the sender and can say anything.
An IP is a network, not a person. An IP lookup shows who operates the network and an approximate region. Home and mobile connections are often shared through NAT (the 100.64.0.0/10 shared address space exists for this IANA IPv4 Special-Purpose Address Registry (updated 9 Oct 2025)), and VPNs show the VPN’s location. Matching an IP and time to one customer needs the network operator’s records; the header never contains them.
Webmail starts at the provider. A message written in Gmail, Outlook.com, Yahoo or a phone app enters the mail system at the provider’s own server, so that server is normally the earliest hop. The sender’s own IP appears only if the provider chooses to record it, for example in an X-Originating-IP line; the tool shows it when present.
Lower lines can be forged. Anything below the Received line your provider added was written by the sending side.
Time-zone hints are weak. The offset in the Date line (for example +0200) is the clock setting of the sending device or server, not a location.

For harassment, threats or fraud, keep the original message (with its header) and report it to the police or the platform. They can ask providers for records the header doesn’t contain.

How do you tell if an email is phishing from its header?

The analyzer sorts what it finds into red, caution, good and neutral signals. They are signals, not a verdict.

Red: DMARC fail, SPF fail, DKIM fail, or a display name that contains a different email address (for example "Bank Security <[email protected]>" <[email protected]>).
Caution: no DMARC result, SPF softfail or none, DKIM signed by an unrelated domain, a Reply-To on a different domain, invisible or text-direction characters in From or Subject, or a Date line far from the first server timestamp.
Good: DMARC pass, SPF pass, DKIM pass aligned with From. These show the mail came from the From domain’s systems. A scammer who registers a look-alike domain can pass all three, so check the domain itself with the Website Legit Checker or Domain OSINT.
Notes: a Return-Path or Message-ID on another domain, bulk-mail headers such as List-Unsubscribe, delivery delays and private IPs are common in legitimate mail and are shown for context.

If you received a phishing email in the US, the FTC says to forward it to the Anti-Phishing Working Group at [email protected] and to report it at ReportFraud.ftc.gov FTC Consumer Advice: How to Recognize and Avoid Phishing Scams (read 10 Oct 2026). In the UK, the NCSC runs a Suspicious Email Reporting Service; its page gives the forwarding address NCSC: Report a scam email (reviewed 5 Sep 2022; read 10 Oct 2026).

How does this compare with MXToolbox, Google and Microsoft header analyzers?

Several free analyzers do similar work. This table uses each tool’s own page as read on 10 October 2026. Where a page says nothing, we say so rather than guess.

Tool	What its page says it does	Where it is stronger	Where headers are processed
Google Admin Toolbox Messageheader	Analyses headers to find delivery delays, estimate their source and suggest who is responsible; normalises timestamps across hops. Paste or drop a text file. Google Admin Toolbox Messageheader (read 10 Oct 2026)	It is the tool Gmail Help itself points to Gmail Help: Trace an email with its full header (read 10 Oct 2026), and it is made by Gmail’s operator.	Not stated on the page.
Microsoft Message Header Analyzer (MHA)	Paste headers and analyse them; results can be copied. The source repository describes it as a mail app (add-in) for Outlook that an administrator installs, plus a standalone web version. Message Header Analyzer web version (read 10 Oct 2026) Message Header Analyzer source repository on GitHub (read 10 Oct 2026)	Inside Outlook it reads the transport headers straight from the mailbox, with no copying.	Not stated on the page.
MxToolbox Email Header Analyzer	Parses headers (it cites RFC 822) to make them readable and show hop delays and anti-spam results. MxToolbox Email Header Analyzer (read 10 Oct 2026)	It sits next to MxToolbox’s other DNS and mail tools.	Not stated on the page.
This analyzer	Hop table with IPs, TLS and delays; SPF, DKIM, DMARC and ARC; From, Reply-To and Return-Path comparison; phishing signals; JSON and text export; .eml drop.	Runs entirely in your browser; pivots to IP and domain tools.	In your browser. Only the optional DNS button sends domain names to Cloudflare.

How was this tool tested?

Synthetic headers shaped like real ones, using only example.com/.net/.org names and documentation IP ranges, were run through the parser and in headless Chromium: a Gmail-to-Gmail style message (IPv6 hop, ARC, Google-style Authentication-Results with DMARC policy comment), an Exchange Online style message with a two-instance ARC chain, Microsoft-style Authentication-Results without an authserv-id, compauth, four Microsoft SMTP Server hops and a 17-minute delay, and a spoofed message with SPF fail, DMARC fail, no DKIM, a forged lower Authentication-Results line, a display name containing another address, a Reply-To on another domain and a right-to-left override character in the Subject.
Folded headers, Q- and B-encoded words in UTF-8 and ISO-8859-1 (including adjacent encoded-words that must join without a space), [IPv6:…] literals, a date without a weekday, and an .eml file with CRLF line ends, an mbox From line and a fake Received line in the body (correctly ignored).
The DNS button was tested with mocked Cloudflare JSON responses, including a TXT record split into several quoted strings, a missing DMARC record with fallback to the organisational domain, and a timeout. A live request from this test machine to cloudflare-dns.com on 10 October 2026 returned access-control-allow-origin: *, so browsers can call it directly.
Hostile input (<script> and javascript: in header values) is rendered as text; there is no horizontal scrolling at 375 px.

Sources

Frequently asked questions

Is this email header analyzer free, and is my header uploaded?

It is free and needs no account. The header is parsed by JavaScript in your browser and is not uploaded or stored. The only optional network request is the SPF and DMARC button, which sends just the sender domain names, never the header itself, to Cloudflare public DNS resolver, and only when you click it. Exports are built in your browser too.

How do I trace an email sender location?

Copy the full header, paste it here and look at the IP that delivered the message to your provider and the earliest public IP in the route. Open those IPs in an IP lookup to see the network owner and an approximate region. That traces the sending server, not the person. If the message was written in webmail or a phone app, the first public hop is usually the provider server, and lines added before your provider received the message can be forged.

How do I trace an email sender in Gmail?

In Gmail on a computer, open the message, click the three-dot More menu next to Reply and choose Show original, then click Copy to clipboard and paste the result here. Gmail Help gives these steps on its Trace an email with its full header page. The SPF, DKIM and DMARC lines near the top of that view are the results Gmail itself recorded.

How do I trace an email sender in Outlook?

In the new Outlook for Windows, open the message, select More actions, then View and View message details, and copy the text. In classic Outlook, open the message and select File, Info, Properties; the headers are in the Internet headers box. Paste them here to see the route, the sending IP and the authentication results.

Can I analyze an .eml file?

Yes. Drop an .eml file on the drop zone or choose it with the file button. Only the header block at the start of the file is read, up to the first blank line, so the message body and attachments are ignored and nothing is uploaded. Outlook .msg files are a different binary format: open the message and copy its Internet headers instead.

Can an email header analyzer detect phishing?

It can show signals, not a verdict. A DMARC or SPF fail, a Reply-To that goes to an unrelated domain, or a display name that contains a different email address are strong warning signs. Passing checks only prove the message came from the mail system of the domain in the From line; a scammer who registers a look-alike domain can pass all three. Judge the links and the request in the message as well.

Can I find out who owns an email address from its header?

Not directly. A header shows servers, IP addresses and domains, not the name of the person behind an address. You can pivot from the From domain to domain registration data and from an IP to the network that operates it, and a reverse email lookup can show where an address appears publicly. Matching an IP and time to a specific customer needs the network operator records, which the header never contains.

Which Received line shows the original sender?

Each mail server adds its Received line at the top, so the bottom one is the oldest and the top one is the newest. This tool lists them oldest first. The most reliable line is the one where your own provider received the message, because the sender can write fake Received lines below it. The earliest public IP is the best guess for where the message entered the mail system.