Email Header Analyzer
Paste raw email headers and instantly see what's really behind a message — SPF, DKIM & DMARC authentication, the full Received chain with per-hop delays to trace the real sender, and spoofing red flags used to detect phishing. Free, no signup. Everything runs in your browser — nothing is ever uploaded.
How to get email headers
Every provider hides full headers behind a menu. Here's how to check email headers in Gmail, Outlook, Yahoo, and Apple Mail — grab them, then paste above:
Gmail (web)
Open the message → ⋮ menu → Show original → copy all the text.
Outlook (web)
Open the message → ··· → View → View message details.
Outlook (desktop)
Open the message → File → Properties → copy the Internet headers box.
Yahoo Mail
Open the message → ⋮ menu → View raw message.
Apple Mail
Select the message → View → Message → Raw Source.
.eml files
Open the .eml file in any text editor and copy everything above the first blank line.
How to read email headers: the fields that matter
From
Who the message claims to be from. Easy to forge on its own — never trust it without authentication.
Return-Path
The envelope sender used for bounces. SPF is checked against this domain, not the From address.
Received
Added by every server that handled the message, newest first. Read bottom-up to trace the delivery path and spot foreign relays.
Authentication-Results
Your provider's verdict: spf, dkim, dmarc each pass, fail, softfail or none.
Received-SPF
Raw SPF check result plus the client-ip that was evaluated — the actual sending server's IP.
DKIM-Signature
Cryptographic signature (d= signing domain, s= selector). Proves the content wasn't altered after signing.
Message-ID
Unique ID assigned by the sending system. Missing or malformed IDs are a (weak) forgery hint.
Reply-To
Where replies go. When it points to a different domain than the sender, treat the message with suspicion.
Investigate like a pro: common use cases
🎣 Phishing investigation
Paste the suspect headers and read the red flags top-down: failed SPF/DKIM/DMARC, brand-name impersonation in the display name, Reply-To on a different domain, lookalike domains. Try the Phishing demo sample above to see what a real spoofing attempt looks like when dissected.
🕵️ Trace the real sender
Wondering how to trace email sender infrastructure? Read the Received chain bottom-up: the last entry is where the message entered the mail system. The client-ip in Received-SPF is the actual connecting server's IP — the one address the sender cannot forge without detection.
🔬 Forensic analysis
Document the full hop timeline with per-hop delays, export every parsed field from the all-fields table, and record the ARC chain state. Timestamps, Message-IDs, and authentication results are the core artefacts of email forensics.
📬 Deliverability troubleshooting
Large delays between hops reveal greylisting or queuing problems; softfail/fail verdicts explain why legitimate mail lands in spam. Check which hop introduced the delay before blaming the sender.
How this compares to other email header analyzers
Three tools dominate this space. Here is a factual feature comparison based on their public documentation (October 2026):
| Feature | This analyzer | Google Admin Toolbox Messageheader | MxToolbox Header Analyzer | mailheader.org |
|---|---|---|---|---|
| Received hops + per-hop delay | ✓ | ✓ | ✓ | ✓ |
| SPF / DKIM / DMARC parsing | ✓ | ✓ | ✓ | ✓ |
| 100% client-side (headers never uploaded) | ✓ | — | — | — |
| Spoofing red flags (brand impersonation, Reply-To mismatch) | ✓ | — | — | — |
| Lookalike / typosquat domain detection | ✓ | — | — | — |
| ARC chain integrity check | ✓ | — | — | — |
| Private-IP forgery detection | ✓ | — | — | — |
| Built-in sample headers (Gmail, Outlook, SES, SendGrid, Yahoo) | ✓ | — | — | — |
| No signup, no ads | ✓ | ✓ | — | ✓ |
Google's Messageheader is excellent for delivery-delay troubleshooting; MxToolbox adds blacklist and DNS diagnostics around its analyzer; mailheader.org offers MTA analysis with route visualization. This tool's edge is security depth + privacy: deeper spoofing checks, with headers that never leave your browser.
Email header analysis FAQ
What is email header analysis?
Email header analysis is reading the hidden metadata attached to every email — fields like From, Return-Path, Received, and Authentication-Results — to verify where a message really came from, which servers handled it, and whether it passed SPF, DKIM, and DMARC authentication. It is a core technique in phishing investigation and email forensics.
How do I check email headers for phishing?
Paste the raw headers above and review the red flags: SPF/DKIM/DMARC failures, a display name impersonating a known brand while the address uses another domain, a Reply-To on a different domain, lookalike domains (for example paypaI with a capital i instead of paypal), and anomalies in the Received chain. The analyzer above flags all of these automatically.
What do SPF, DKIM, and DMARC tell me?
SPF tells you whether the sending server is authorized to send mail for the domain. DKIM is a cryptographic signature proving the message was not altered in transit. DMARC ties them together and states the domain owner's policy for mail that fails authentication. When all three pass, the sender's identity is strongly verified.
What does the delay between Received hops mean?
Each mail server stamps a Received header with the time it handled the message. The delay between consecutive hops shows how long the message waited at each relay. A few seconds is normal; very large gaps can indicate greylisting, queuing problems, or a forged timestamp worth a closer look.
How do I get full headers in Gmail or Outlook?
In Gmail on the web: open the message, click the three-dot menu, then Show original. In Outlook on the web: open the message, click the three-dot menu, then View → View message details. In Outlook desktop: open the message and go to File → Properties, then copy the Internet headers.
Can I analyze a .eml file?
Yes. Open the .eml file in any text editor (Notepad, VS Code, TextEdit), copy everything from the top down to the first blank line — that block is the headers — and paste it into the analyzer above.
Is it safe to paste email headers into this tool?
Yes. Everything runs 100% client-side in your browser via JavaScript — headers are never uploaded anywhere, which you can confirm in DevTools → Network. If the headers contain sensitive addresses, you can redact them before pasting; authentication results still parse.
Why is Return-Path different from From? Is that spoofing?
Not necessarily. Return-Path is the envelope sender used for bounces, and bulk senders (newsletters, Amazon SES, SendGrid, Mailchimp) legitimately use their own bounce domains while From shows the brand. It becomes a real spoofing signal mainly when combined with failed SPF, DKIM, or DMARC authentication.
How do I trace the real sender of an email?
Read the Received headers from bottom to top: each mail server prepends its own entry, so the bottom-most Received line is the first hop — the closest you get to the true origin. Then check Received-SPF: its client-ip is the actual IP address of the connecting server, recorded by your provider and hard to forge. Paste the headers into the analyzer above and the timeline table lays this out hop by hop.
What is the Authentication-Results header?
Authentication-Results is a header added by the receiving mail server (never trust one that arrives from outside) summarizing its SPF, DKIM, and DMARC checks, each marked pass, fail, softfail, none, or similar. The analyzer above parses every Authentication-Results block — including Gmail's ARC variants and Microsoft's compauth — and rolls them into a single verdict.
How can I tell if an email is spoofed?
Check five things: (1) Authentication — SPF, DKIM, and DMARC should pass; failures are the strongest signal. (2) Display name vs address — "PayPal Security" writing from security@paypaI-support.com is impersonation. (3) Reply-To pointing to an unrelated domain. (4) Lookalike domains — substituted letters (rn for m), digits for letters, or punycode. (5) Received chain anomalies. The analyzer flags all five automatically.
What is an ARC chain and why does it matter?
ARC (Authenticated Received Chain) lets email authentication survive forwarding: each forwarder cryptographically seals the authentication results it saw, so the final receiver can still trust them. The analyzer validates the ARC chain structure — instance numbering, the cv= sequence, and that all three ARC headers exist per instance — and reports breaks that suggest tampering.
How do I find the sender's IP address from email headers?
Look at the earliest (bottom-most) Received header's IP in brackets, and cross-check Received-SPF's client-ip — that is the IP your mail provider actually saw connecting, so it is the most reliable. Note that for webmail senders this is the provider's server IP, not the person's device. The analyzer extracts and lists every hop IP in its timeline table.
How does this analyzer compare to Google Admin Toolbox or MxToolbox?
Google Admin Toolbox Messageheader is great for delivery-delay troubleshooting and MxToolbox adds DNS/blacklist diagnostics, but both process your headers on their servers. This analyzer runs 100% in your browser — headers are never uploaded — and goes deeper on security: spoofing red flags, lookalike-domain detection, ARC chain validation, and forged-header detection that the others don't offer. See the comparison table above for details.
What does "softfail" mean in an SPF result?
Softfail (~all in the domain's SPF record) means the sending IP is probably not authorized, but the domain owner asked receivers not to reject the message outright — a transitional state between neutral and fail. Treat softfail as a yellow flag: legitimate mail occasionally softfails (forwarding, new servers), but so does most spoofed mail that bothers to set up SPF.