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, spam 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 spam 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 how long each hop took. 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 parsed server-side on our edge proxy and are never persisted; 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

1

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)

2

Copy the entire header block — must include all `Received:` lines and the `Authentication-Results:` line

3

Paste into the analyzer's text area

4

Click 'Trace' to parse and visualize

5

Review the delivery timeline — each hop shows hostname, IP, timestamp, location, and time-since-previous-hop

6

Check the Authentication panel — SPF, DKIM, DMARC verdicts as the receiving server computed them

7

Inspect the metadata strip — From, To, Subject, Date, Message-ID for the full message context

8

Use the search field to find specific headers (X-Spam-Score, List-Unsubscribe, custom X-headers)

Key Features

Full delivery-hop timeline

Reconstructs the chain of mail servers the message traversed, in chronological order, with timestamps and time-between-hops. Long delays between hops are flagged.

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 / city. Useful for spotting unexpected geography (a mail claiming to be from your bank that transited a server in an unrelated country).

Spam score extraction

Reads SpamAssassin / X-Spam-Score / X-Spam-Status headers and shows the rating that determined where the message landed.

Header search

Live filter across every parsed header — find a specific X-header, list-management directive, or custom annotation in seconds.

Long-delay flagging

If a hop took unusually long (e.g., greylisting at the recipient), the timeline highlights it. Helps explain 'why did this email take 4 hours to arrive?'.

Server-side parsing — no persistence

Headers are sent to our edge proxy for parsing and IP geolocation lookups. The result is returned and the headers are not stored or logged. 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 spam 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.

Accuracy

Reads the receiving server's actual Authentication-Results — the verdict that determined real delivery, not a re-check.

Privacy

Only the headers you paste are sent to our edge proxy for parsing. The email body, attachments, and unsent content stay on your device. Headers are not persisted or logged after parsing.

Uptime

Globally distributed edge infrastructure for low-latency parsing and geolocation lookups.

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 with explicit warnings when timestamps disagree.

Does this tool see my email content?

Only the headers you paste are sent to our edge proxy for parsing. The body, attachments, and any quoted content you didn't paste are never transmitted. The headers are not persisted or logged — only parsed and returned. IP geolocation lookups happen during processing (so an IP from a Received: hop is queried against a geo database). For forensic-sensitive material, redact From / To / Subject / Message-ID before pasting.

What's a 'spam score'?

Anti-spam systems (SpamAssassin, Microsoft SCL, etc.) compute a numeric score based on dozens of signals: auth results, content patterns, sender reputation, etc. Higher score = more likely spam. The tool extracts the score from headers like `X-Spam-Score`, `X-Spam-Status`, or `X-Microsoft-Antispam`. Threshold for 'spam folder' varies by provider but typically 5+ on the SpamAssassin scale.

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 + DMARC RUF aggregate reports (which include header summaries from receivers).

Technical Specifications

Supported Formats

  • RFC 5322 / RFC 6376 / RFC 7208 / RFC 7489 header formats
  • Authentication-Results parsing (SPF, DKIM, DMARC, ARC, BIMI partial)
  • Received-chain reconstruction with timestamp normalization
  • IP geolocation per hop
  • SpamAssassin / Microsoft / generic spam-score extraction
  • Live header search / filter

Limits & Performance

  • File Size: Practical limit ~500 KB of header text per analysis
  • Validations: Live parsing on every change
  • Response Time: Sub-second after geolocation cache warms
  • 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`, `Received`, and any `X-Spam-*` lines.

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.

Support This Project

Buy Me a Coffee