Email Header Analyzer & Tracer
Paste full email headers and see the message's delivery path, SPF/DKIM/DMARC verdicts as recorded by the receiving server, a risk score, and per-hop server details. Surfaces phishing red flags including authentication failures, brand-impersonating display names (e.g. "PayPal Support" sent from an unrelated domain), and elevated risk scores — useful even when SPF/DKIM/DMARC technically pass.
Email Headers
0 characters • 1 lines
Trace Results
Email trace results will appear here
Paste email headers and click "Trace Email" to start
Understanding Email Tracing
What is email tracing?
Email tracing analyzes the path an email took from sender to recipient by examining the email headers, which contain information about each mail server the email passed through.
Authentication protocols:
- SPF: Verifies the sender's IP is authorized
- DKIM: Validates the email hasn't been tampered with
- DMARC: Combines SPF and DKIM for comprehensive validation
When to trace emails:
- Suspected phishing or spoofing attempts
- Investigating spam sources
- Troubleshooting email delivery issues
- Verifying email authenticity for legal purposes
- Security incident investigation
Privacy reminder: Email headers contain sensitive information. Handle trace results with care and follow your organization's data protection policies.
About Email Header Analyzer & Tracer
The Email Header Analyzer & Tracer parses the raw `Received:`, `Authentication-Results:`, and other headers from a real email and reconstructs the message's full delivery path: every hop, with timestamps, server hostnames, IPs, geolocation, and the delay since the previous hop. It also extracts SPF, DKIM, and DMARC verdicts as the receiving server computed them, so you can see exactly which checks passed or failed. Pairs with the SPF Checker, MX Lookup, and SMTP Test tools for end-to-end deliverability debugging.
Why use a Email Header Analyzer & Tracer?
When you suspect a phishing email, want to know why a legitimate email landed in spam, or need to prove an email's origin in a security investigation, the headers contain the answer — but they're nearly unreadable raw. This tool turns 50+ lines of cryptic `Received:` chains into a clean timeline and surfaces the auth results that actually mattered for delivery. Headers are sent to Toolsana's API for parsing and are not stored; for forensic-sensitive material, redact From / To / Subject before pasting.
Who is it for?
Security teams investigating phishing reports, IT support diagnosing 'why did this go to spam?' tickets, deliverability teams confirming SPF/DKIM/DMARC alignment on real production mail, compliance / legal teams gathering forensic evidence on questioned emails, journalists verifying the source of leaks, and developers debugging why their transactional mail's auth results vary between recipients.
How to use the tool
Open the email in your client and find the 'show original' / 'view source' / 'all headers' option (Gmail: ⋮ menu → Show original; Outlook: File → Properties → Internet headers; Apple Mail: View → Message → All Headers; Yahoo: ⋮ menu → View raw message)
Copy the entire header block — must include all `Received:` lines and the `Authentication-Results:` line
Paste into the analyzer's text area
Click 'Trace' to parse the headers
Review the delivery timeline — each hop shows hostname, IP, timestamp, location, and the delay since the previous hop
Check the Authentication panel — SPF, DKIM, DMARC verdicts as the receiving server computed them
Inspect the metadata strip — From, To, Subject, Date, Message-ID for the full message context
Check the risk score and any red flags, such as a display name that doesn't match the sender domain
Key Features
Full delivery-hop timeline
Reconstructs the chain of mail servers the message traversed, in chronological order, with timestamps and the delay since the previous hop. The total transit time is shown, and negative delays are labelled as clock skew.
SPF / DKIM / DMARC verdicts extracted from real headers
Parses the `Authentication-Results` header that the receiving server actually wrote — so you see the verdict that affected delivery, not a re-check that might differ. Each verdict is colour-coded pass / fail / softfail / neutral.
Server geolocation per hop
Each hop's IP is geolocated to country / region / city from a local IP database. Useful for spotting unexpected geography (a mail claiming to be from your bank that transited a server in an unrelated country).
Risk score
A 0-10 score computed by Toolsana from the SPF, DKIM, and DMARC results in the headers plus blacklist listings of the sending IPs. It is our own heuristic, not a score assigned by the receiving server, and it does not read SpamAssassin or X-Spam headers.
Hop delays
Shows how long each hop took relative to the previous one, which helps explain 'why did this email take 4 hours to arrive?'.
Server-side parsing
Headers are sent to Toolsana's API for parsing, IP geolocation, and blacklist checks of the hop IPs. The result is returned and the header text is not stored. For forensic-sensitive material, redact From / To / Subject before pasting.
Common Use Cases
Verifying a suspicious email is actually phishing
Scenario: You received an 'urgent' email claiming to be from your bank or CEO. Want to verify before clicking anything.
✓ Paste headers. If SPF or DKIM failed, or the originating server is in an unexpected country, or the From-domain doesn't match the SMTP envelope — you've got concrete evidence it's a phish. Forward to your security team with the analysis attached.
Diagnosing 'this email went to spam' tickets
Scenario: User reports a legitimate email from your service ended up in their spam folder.
✓ Ask them to forward it as attachment. Paste headers, see the risk score and which auth check failed. Fix the underlying issue (likely an SPF gap or DKIM signing problem) so it doesn't repeat.
Proving an email's authenticity in a dispute
Scenario: Legal / HR investigation needs to know whether an email was genuinely sent by the claimed sender.
✓ Header analysis shows the SPF/DKIM/DMARC verdicts at the time of delivery — strong evidence for or against authenticity. Preserves the forensic chain of custody better than just opening in an email client.
Debugging delivery delays
Scenario: Critical transactional email took 30 minutes to arrive and you need to know why.
✓ Timeline shows where the delay was — often greylisting at one hop, or a slow downstream MX. Tells you whether the delay was on your side, the recipient's side, or a transit hop.
Verifying DMARC alignment on production mail
Scenario: You implemented DMARC and want to confirm legitimate mail from your senders is actually aligning correctly.
✓ Send a test email from each of your sending sources, paste the headers from the receiving inbox, confirm DMARC pass. Catches misalignment between SPF/DKIM domain and From: header before you tighten the DMARC policy.
Reads the receiving server's actual Authentication-Results — the verdict that determined real delivery, not a re-check.
Only the headers you paste are sent to Toolsana's API for parsing. The email body, attachments, and unsent content stay on your device. The header text is not stored.
Requests go through Toolsana's Cloudflare edge to our API.
Frequently Asked Questions
Where do I find the email headers in my client?
Gmail web: open email → ⋮ menu → 'Show original'. Outlook desktop: File → Properties → Internet headers. Outlook web: ⋮ menu → View → View message source. Apple Mail: View → Message → All Headers (or ⌥⌘U for raw source). Yahoo: ⋮ menu → View raw message. Thunderbird: Ctrl+U for full source. Most mobile clients DON'T show full headers — forward the email to a desktop client first.
Why are the auth results different from what my SPF Checker shows?
The Email Header Analyzer shows the verdict the receiving server computed when the message was actually delivered. The SPF Checker shows the current state of the SPF record. They can differ if your SPF record changed between when the email was sent and now, or if the receiving server uses different lookup defaults (e.g., resolves includes from a different recursive DNS).
Can headers be forged?
The `Received:` headers added by trusted servers (especially the receiving server's own) cannot be forged after the fact. Headers added by upstream servers CAN technically be forged by a sufficiently determined attacker, but doing so without breaking auth (DKIM signs the message including some headers) is hard. The bottom-most `Received:` (your own MX) is the most trustworthy.
Why does the timeline show times in the future / past?
Each `Received:` header has its own timestamp from the server that added it. Server clocks may drift. Genuinely impossible orderings (e.g., a downstream hop with an earlier timestamp than an upstream one) are usually clock skew, not malice. The timeline is best-effort; a negative delay is labelled as clock skew.
Does this tool see my email content?
Only the headers you paste are sent to Toolsana's API for parsing. The body, attachments, and any quoted content you didn't paste are never transmitted. The header text is not stored; our logs record the request size, not the content. IP geolocation uses a local database on our server, and the hop IPs are also checked against DNS blacklists. For forensic-sensitive material, redact From / To / Subject / Message-ID before pasting.
What's the risk score?
A 0-10 number computed by Toolsana, not by your mail provider. It is based on the SPF, DKIM, and DMARC results in the Authentication-Results header and on whether the sending IPs are listed on DNS blacklists. Below 3 is low, 3-5 medium, 5 and above high. It does not read SpamAssassin, X-Spam-Score, or Microsoft SCL headers, so treat it as a quick signal rather than the verdict your provider used.
Why don't I see DKIM / DMARC results?
Either the sending domain doesn't have DKIM configured (so there's nothing to verify), or the receiving server didn't perform the check (some smaller mail servers don't). Most major receivers (Gmail, Microsoft, Yahoo) do all three checks and write the results to `Authentication-Results`.
Can I trace an email I haven't received?
No — the tool needs the actual headers, which exist only after delivery. To investigate spoofing of your domain, look at incoming complaints and your DMARC reports.
Technical Specifications
Supported Formats
- ✓RFC 5322 / RFC 6376 / RFC 7208 / RFC 7489 header formats
- ✓Authentication-Results parsing (SPF, DKIM, DMARC)
- ✓Received-chain reconstruction with per-hop delays and total transit time
- ✓IP geolocation per hop
- ✓Toolsana risk score (SPF/DKIM/DMARC results + blacklist listings)
Limits & Performance
- •File Size: Up to 100,000 characters of header text per analysis (30 traces per hour)
- •Validations: Parsed when you click Trace
- •Response Time: Typically a few seconds, depending on blacklist lookups
- •Browsers: All modern browsers
Pro Tips
- Read headers bottom-up. The bottom-most `Received:` is the first hop (where the message was sent from); each line above is added by the next server. The top-most was added by your own mail server when delivering to your inbox.
- The From: header can be forged trivially — DKIM and DMARC alignment are what matter for trust, not the From: address alone.
- If SPF passed but DMARC failed, check 'alignment' — the From: domain must MATCH the SPF return-path domain (relaxed alignment) or be exact (strict alignment). Misalignment is the most common DMARC failure.
- Keep a few sample headers on file (a known-good email from yourself, a known phish you reported, a known transactional email) — comparing against known-good speeds up future investigations.
- Forward suspected phish to your security team WITH HEADERS. Don't just screenshot — they need the parseable headers to confirm.
- When debugging delivery delays, look for hops with `delay=` annotations or large gaps between timestamps. Greylisting (fixed ~5-15 minute delay between specific hops) is the most common cause.
- Don't worry about every X-header — most are vendor-specific noise. Focus on `Authentication-Results` and `Received`.
Share This Tool
Found this tool helpful? Share it with others who might benefit from it!
💡 Help others discover useful tools! Sharing helps us keep these tools free and accessible to everyone.