Secure Email Header Analyzer & Hop Tracer
Paste raw email headers to trace delivery hops, inspect SPF/DKIM/DMARC/ARC results, flag spoofing clues, and explain spam-filter signals — locally in your browser.
Parsing happens entirely in your browser. Nothing is uploaded.
Paste raw email headers on the left, or load a sample above, to trace hops, inspect authentication results, and surface spoofing or deliverability clues.
Header parsing runs entirely in your browser. Pasted headers are never sent to a server. If your headers contain sensitive routing details, internal hostnames, or personal data, continue to follow your organisation's incident-handling and privacy policies.
Header parsing runs entirely in your browser using a local parser — no headers, IPs, hostnames, or mail content are uploaded to a server. Email headers can still contain internal hostnames, personal data, and sensitive routing details. Follow your organisation's privacy and incident-handling policies before sharing them externally.
Overview
Raw email headers are where the real story of a message lives, and they are deliberately verbose. Every mail system the message passes through stamps its own Received: line on top, so the newest hop is at the top and the oldest is at the bottom. Authentication systems add their verdicts as Authentication-Results. Vendors layer on their own spam scores. The result is dense, easy to misinterpret, and exactly what phishing investigators and deliverability teams need.
This tool turns a pasted header block into a readable delivery timeline, an authentication dashboard, and a findings panel. It flags From / Reply-To / Return-Path mismatches, surfaces ARC evidence, interprets SpamAssassin and Microsoft SCL headers, calculates hop-by-hop delays, and highlights the trust-boundary problem rather than pretending every Received line is equally reliable.
All parsing is local. The raw headers you paste — including internal hostnames, IPs, recipients, and vendor trace data — are never uploaded. This matters for corporate mail, for customer escalations, and for anti-phishing triage where the message under investigation may contain targeted data.
Use cases
When to use it
- Phishing and BEC triageinspect From / Reply-To / Return-Path, DMARC alignment, display-name impersonation patterns, and unauthenticated claims on a single screen.
- Deliverability debuggingfind exactly where a message spent its time, why it landed in spam, and whether SPF, DKIM, or DMARC are blocking it for a given receiver.
- Helpdesk and IT support investigationstrace a message across internal and external relays, identify the receiving system that failed authentication, and produce a copyable incident note.
- Forwarding and mailing-list debuggingARC evidence and DKIM signature surfacing help distinguish legitimate list/forwarder modification from real authentication failure.
- SOC / email security analystsspot spoofing clues, severity-grouped findings, and hop-level delay anomalies without forwarding headers to an external service.
- Marketers and ESP teamsinspect a single problematic message in detail after a broader DMARC aggregate review to understand what failed at receipt.
When it's not enough
- Proof of email origin from headers aloneupstream Received lines are written by sending infrastructure, not the recipient. Trust only up to the receiving boundary and the systems you recognise.
- Authoritative DMARC policy analysisheaders show what one receiving system observed. For domain-wide authentication posture, use the DMARC / SPF / DKIM Analyzer & Aggregate Report Parser.
- Content or attachment inspectionthe analyzer reads header metadata only. Message bodies, attachments, and rendered HTML are not parsed here.
How to use it
- 1
Copy raw headers from your mail client
Gmail: open the message → More ⋮ → Show original. Outlook on the web / new Outlook: open the message → ⋯ → View → View message source. Apple Mail: View → Message → Raw Source (or All Headers).
- 2
Paste into the analyzer
Paste the full header block into the left panel, or load a sample to see the tool in action. Parsing runs in your browser.
- 3
Inspect the delivery timeline
Switch to the Timeline tab for a hop-by-hop view with hostnames, IPs, public/private classification, timestamps, and calculated delays.
- 4
Review authentication and identity mismatches
The Authentication tab surfaces SPF, DKIM, DMARC, and ARC verdicts, plus a side-by-side comparison of From, Reply-To, Return-Path, SPF identity, and DKIM signing domain.
- 5
Work through the findings
Findings are severity-grouped (Critical, Warning, Recommendation, Info) and explain both the observation and the typical cause.
- 6
Copy the incident note
The Summary tab produces a condensed, copyable incident note suitable for tickets, SOC notes, and deliverability investigations.
Common errors and fixes
Treating the bottom Received line as proof of origin
Upstream Received lines are written by the sending side. Only Received lines added by systems you trust are authoritative. Confirm origin with authentication (SPF/DKIM/DMARC), not with the oldest trace line alone.
Confusing Return-Path with the visible sender
Return-Path reflects the SMTP MAIL FROM / bounce address at delivery. It often legitimately differs from the visible From: for ESPs, mailing lists, and some one-way notifications. A mismatch is an input to the investigation, not a verdict on its own.
Assuming DKIM failure always means tampering
Mailing lists, forwarders, and content rewriters commonly break DKIM signatures by modifying message bodies. If DKIM fails but the message obviously came through a list or forwarder, look for ARC evidence and treat DKIM alone as partial signal.
Treating DMARC as a From-vs-Return-Path check
DMARC alignment checks whether the visible From: domain aligns with an authenticated identity (SPF MAIL FROM or DKIM d=). It is not a straight comparison against Return-Path, and the alignment mode (relaxed vs strict) affects the verdict.
Assuming all spam scores mean the same thing
SpamAssassin scores are additive points against a configurable threshold. Microsoft SCL is a 0–9 scale with its own documented meanings. Proofpoint, Mimecast, and Barracuda each use different scales. Read vendor documentation before comparing across receivers.
Missing ARC context on forwarded mail
Forwarded messages and mailing-list delivery routinely break SPF or DKIM at the final receiver. Presence of ARC headers with a passing chain usually explains the failure without implying fraud. Absence of ARC on a forwarded-looking path is a reason to look closer.
Frequently asked questions
Related
How can you trace the origin of an email using headers?
You trace an email’s path by reading the Received: chain together with the authentication evidence. Received: lines are added top-down as the message passes through mail servers, so the most recent (most trustworthy) hop appears at the top of the header block, and the oldest at the bottom.
The catch: only the hops added by systems you trust — typically your own infrastructure and the final receiving system — are authoritative. Hops added by upstream systems are only as reliable as those systems themselves. An attacker can forge whatever they want in a Received line their own server writes. For real origin confidence, combine the trace with SPF, DKIM, DMARC, and ARC results on the receiving side.
What is the difference between From, Reply-To, and Return-Path?
From: is the visible author the recipient sees in their mail client. It is a message header and can be set to any value by the sending software; authentication is what gives it credibility.
Reply-To:tells the recipient’s mail client where to send replies. It is legitimately used by support desks, mailing lists, and automated systems that want replies routed somewhere other than the From: address.
Return-Path: is stamped at delivery time from the SMTP MAIL FROM (the envelope sender / reverse path). It is the address delivery errors and bounces are sent to, and it is what SPF typically authenticates. ESPs, mailing lists, and bulk senders commonly use their own bounce domain here.
All three can differ from each other for legitimate reasons. The combination “From: a well-known brand, Reply-To: unrelated external domain, Return-Path: unrelated external domain, DMARC: fail” is the classic phishing pattern — but each signal on its own is just context.
SPF, DKIM, DMARC, and ARC explained
SPF (Sender Policy Framework) authenticates SMTP sending identities such as MAIL FROM and HELO. The sender’s domain publishes a list of authorised sending IPs; the receiver checks whether the connecting IP is on that list. SPF authenticates the envelope, not the visible From:.
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to the message. The signing domain (d= in the signature) publishes a public key at a DNS selector. The receiver verifies the signature, which proves the signing domain took responsibility for the message and that specific headers and body content were not modified in transit.
DMARC ties SPF and DKIM to the visible From: domain via alignment. DMARC passes when SPF or DKIM passes and the authenticated domain aligns with the From: domain under the configured alignment mode (relaxed or strict). A receiver uses DMARC alignment to decide how to handle the message when alignment fails.
ARC (Authenticated Received Chain) preserves the authentication state of a message as it passes through intermediaries that may legitimately modify it, such as mailing lists and forwarders. ARC is supporting evidence: trust the outermost authserv-id first, and use ARC to reconstruct what the message looked like upstream.
Warning sign → likely cause matrix
| Warning sign in headers | What it often means | Caveat |
|---|---|---|
| From differs from Return-Path | Bulk sender, marketing ESP, or intentionally different bounce address | Common and legitimate for ESPs. Worrying only when combined with DMARC fail and other mismatches. |
| Reply-To mismatch | Replies are being routed away from the visible sender domain | Legitimate for support, list reply handlers, and automated tools. Suspicious when paired with brand-impersonation From:. |
| SPF fail or softfail | Sending IP is not authorised by the envelope sender's domain | Forwarding and mailing lists often break SPF at the final receiver. Check for ARC pass. |
| DKIM fail | Signature did not verify; message may have been modified or forwarded | Mailing lists and content-rewriting forwarders break DKIM legitimately. Context matters. |
| DMARC fail | Visible From: domain does not align with an authenticated identity | Strongest single signal to treat the message as unverified. Forwarding can still cause legitimate failures. |
| Long delay between hops | Greylisting, queue pressure, or a distant relay handoff | Not necessarily a security issue. Deliverability investigations start here. |
| ARC present with forwarding signs | Message passed through a list or forwarder that preserved upstream auth | A valid ARC chain usually explains SPF/DKIM failure on the final hop. |
| High SCL or spam headers | Receiving filter decided the message was spam or phishing | Vendor-specific meaning. SCL 9 is high-confidence phish on Microsoft; SpamAssassin scores depend on the configured threshold. |
How to extract raw headers from common mail clients
Gmail
- Open the message.
- Click the ⋮ menu in the upper right.
- Choose Show original.
- Copy the raw header block at the top.
Outlook on the web / new Outlook
- Open the message.
- Click the ⋯ menu.
- Choose View → View message source.
- Copy the headers from the top of the source view.
Apple Mail
- Open the message.
- Choose View → Message → Raw Source (or All Headers).
- Copy the raw header block.
Local, private, and zero-upload in v1
Email headers frequently contain personal data, internal hostnames, routing details, and security metadata. This tool parses them in your browser. Nothing is sent to a server. That said, headers you paste may be subject to your organisation’s privacy, DLP, and incident-handling policies — continue to follow them before sharing results outside your team.