Most people read the “From” field and stop there. That’s exactly what fraudsters count on.

The visible sender address in any email client is one of the easiest things to fake in computing. But the headers hiding beneath that surface? Those tell a completely different story — one that’s much harder to fabricate and significantly easier to verify.

Email header analysis sits at the intersection of network forensics and fraud investigation. Whether you’re working a business email compromise case, a phishing investigation, or trying to establish whether a message was actually sent by the person who claims to have sent it, the header is your primary source of ground truth.

This guide walks through everything an examiner needs: how authentication protocols work, how to read routing headers, how to detect spoofing, and how to present email provenance findings in court.

What’s Actually Inside an Email Header

When you open a message in Gmail or Outlook, you see the cleaned-up version. Subject line, sender name, date, maybe a recipient field. The raw header is far more detailed.

Every email carries a stack of `Received:` lines — one added by each mail transfer agent (MTA) the message passed through. These stack in reverse chronological order. The bottom-most `Received:` line is where the message originated. The top line is where it arrived.

Beyond routing, modern headers include authentication results. This is where SPF, DKIM, and DMARC come in.

SPF: Sender Policy Framework

SPF lets a domain owner publish a list of IP addresses authorized to send mail on their behalf. That list lives in a DNS TXT record.

When a receiving mail server gets a message claiming to be from `billing@example.com`, it checks DNS: “Is the sending IP on example.com’s authorized list?” If not, SPF fails.

A passing SPF result looks like this in the header:

“`
Received-SPF: pass (google.com: domain of billing@example.com designates 192.0.2.10 as permitted sender)
“`

A failing result looks like:

“`
Received-SPF: fail (google.com: domain of billing@example.com does not designate 203.0.113.5 as permitted sender)
“`

The IP address in that failure is your starting point for tracing the actual sender. Run it through a WHOIS lookup — tools like MXToolbox make this fast — and you’ll see the registrar, organization, and often country of origin.

SPF has one significant limitation: it validates the envelope sender (the `MAIL FROM` address used during SMTP negotiation), not the `From:` header the user sees. This distinction matters. A message can pass SPF while still displaying a spoofed visible sender.

DKIM: DomainKeys Identified Mail

DKIM solves a different problem. Instead of checking where a message came from, it verifies the message wasn’t tampered with in transit.

When a mail server sends a DKIM-signed message, it generates a cryptographic signature of specific header fields and the message body. That signature gets attached to the email as a `DKIM-Signature:` header. The corresponding public key lives in DNS under a specific selector subdomain.

Any downstream mail server can fetch that public key and verify the signature. If the message body or signed headers were modified after sending, the signature breaks.

A valid DKIM result in headers:

“`
Authentication-Results: mx.google.com;
dkim=pass header.i=@example.com header.s=20210112 header.b=AbCdEfGh
“`

For forensic examiners, DKIM is particularly valuable because a valid signature means the message arrived exactly as the sending server dispatched it. No man-in-the-middle modification occurred. This is powerful testimony in cases where message integrity is disputed.

Pay attention to the `d=` tag (signing domain) and `i=` tag (signing identity) in the DKIM-Signature header. They should match the domain in the `From:` address. A mismatch — say, `From:` shows `ceo@bigcorp.com` but DKIM signature is from `d=bulk-mailer-service.net` — is a red flag worth documenting.

DMARC: Domain-based Message Authentication, Reporting, and Conformance

DMARC ties SPF and DKIM together and adds a policy layer. A domain’s DMARC record tells receiving servers what to do when SPF or DKIM fails: nothing (`p=none`), quarantine (`p=quarantine`), or reject (`p=reject`).

But for examiners, the more useful piece of DMARC is alignment. DMARC requires that either the SPF-authenticated domain or the DKIM signing domain aligns with the visible `From:` domain.

This is the check that catches display name spoofing. An attacker might send from a completely different domain, pass that domain’s own SPF, and still fail DMARC because the authenticated domain doesn’t match the visible sender.

Authentication-Results in a spoofed message:

“`
Authentication-Results: mx.google.com;
spf=pass (sender IP is 198.51.100.22) smtp.mailfrom=phishing-domain.net;
dkim=pass header.i=@phishing-domain.net;
dmarc=fail (p=REJECT sp=REJECT dis=REJECT) header.from=bigcorp.com
“`

That DMARC failure is your evidence. The message visually appeared to come from `bigcorp.com`. It did not.

Reading Received Headers to Trace Routing

Pull up a raw email header in any client. In Thunderbird: View → Message Source. In Gmail: three-dot menu → Show Original. In Outlook: File → Properties.

You’ll see a series of `Received:` lines. Here’s how to read them:

“`
Received: from mail.suspicious-domain.ru (mail.suspicious-domain.ru [185.220.101.45])
by mx.victim.com with ESMTP id xyz123
for ;
Mon, 14 Apr 2026 09:12:33 -0700
“`

This line tells you:

The IP in brackets is the only piece that matters for geolocation. The hostname before it is whatever the sending server claims to be — entirely self-reported and unverified.

Work backward through the stack. The earliest `Received:` line (bottom of the stack) is the message’s first hop. That’s your originating IP.

Time Zone Analysis

Every `Received:` header includes a timestamp with timezone offset. Collect them all and convert to UTC. Look for anomalies:

A forged `Date:` header is common in fraud cases. Compare it against the actual delivery timestamps in `Received:` lines. The mail servers added those — the sender couldn’t manipulate them.

Detecting Common Spoofing Techniques

Display Name Spoofing

The simplest attack. The attacker sets their display name to “CEO First Last” but sends from a completely different address. Most mail clients show only the display name by default.

In headers, look at the `From:` field carefully:

“`
From: “Jane Smith, CEO”
“`

That domain has nothing to do with the company. But most users never see it.

Cousin Domain Spoofing

Attacker registers a domain visually similar to the target: `bigc0rp.com`, `bigcorp-billing.com`, `bigcorp.support`. They can pass SPF and DKIM for their own domain, but DMARC alignment with `bigcorp.com` fails.

Reply-To Manipulation

The `From:` address looks legitimate. The `Reply-To:` address points to the attacker’s server. Responses go to the attacker, not the legitimate sender.

Check both fields every time.

Header Injection

Less common but worth knowing. An attacker manipulates form inputs to inject additional headers. Look for unexpected line breaks or unusual header fields that don’t belong to standard RFC 5322 structure.

Tools for Email Header Analysis

Thunderbird

Mozilla Thunderbird remains one of the most forensically useful free email clients. The raw message source view gives you clean, unmodified header display. Thunderbird also handles PST, MBOX, and EML files with appropriate add-ons, making it useful for examining archived mail exports.

For investigations involving exported email evidence, always examine headers in the raw format. Never trust the client’s display.

MXToolbox Email Header Analyzer

MXToolbox’s Email Header Analyzer is a web-based tool that parses raw headers and visualizes the routing path, timestamps, and authentication results. Paste the raw header, and it displays:

Useful for initial triage. For formal investigation, document your analysis separately — don’t rely on screenshots of third-party web tools as your primary exhibit.

EmailDossier and WHOIS Tools

Once you’ve identified a suspicious originating IP, WHOIS lookup identifies the registrant. American Registry for Internet Numbers (ARIN) handles North American IP space. RIPE handles Europe. APNIC handles Asia-Pacific.

Cross-reference IP with threat intelligence databases (AbuseIPDB, Spamhaus) to see if the address has prior fraud or spam history. A fresh registration with no prior activity is worth noting too — attackers frequently spin up new infrastructure.

Python `email` Library

For bulk analysis or when you need to process large volumes of messages, Python’s built-in `email` library parses headers programmatically. You can extract all `Received:` timestamps, authentication results, and `From:` fields across thousands of messages in minutes. This is particularly useful in business email compromise investigations where you’re mapping an attacker’s infrastructure across multiple victim accounts.

Building a Chain of Custody for Email Evidence

Before you touch any email evidence, document its source.

Native format first. If the email exists on a live server, request a forensic export in native format — EML for individual messages, MBOX for mailboxes. Never accept a printed copy or a screenshot as the primary exhibit. You cannot authenticate a screenshot.

Hash the files. SHA-256 hash every exported file immediately. Document the hash in your notes before any analysis begins. This is your proof the file hasn’t been modified since acquisition.

Document your access. Who exported the email, from what system, using what credentials, at what time. This forms the foundation of your authentication testimony.

Obtaining Headers from Different Platforms

Gmail: Three-dot menu → Show Original. Full raw header and body available for download.

Microsoft 365: Message trace in the admin portal gives server-side delivery records. Individual messages: File → Properties → Internet Headers in Outlook.

Apple Mail: View → Message → All Headers.

Server-side logs: If you have access to the mail server, SMTP logs contain delivery records that exist independent of the message itself. These are particularly valuable when the message may have been deleted.

Presenting Email Provenance in Court

Technical accuracy is necessary but not sufficient. Judges and juries need to understand what you found and why it matters. Your job is to make the complex simple without sacrificing accuracy.

The Three Questions to Answer

  1. Did this message come from who it claims to come from? (SPF, DKIM, DMARC results)
  2. Was the message modified after it was sent? (DKIM signature validation)
  3. When was this message actually sent and received? (Timestamp analysis across Received headers)

Exhibit Preparation

Side-by-side exhibits work well. Column A: the visible email as any recipient would see it. Column B: the raw header with your annotations. Use arrows or callouts to connect visible elements to their header counterparts.

Never just hand a judge a wall of raw header text and expect them to understand it. Walk through it. “This IP address here — 185.220.101.45 — is registered to a VPS provider in Russia. The message claims to come from your client’s CFO in Chicago. These two facts cannot both be true.”

Qualifying Your Opinion

Be precise about what the headers prove and what they suggest. Headers prove routing path and authentication results as processed by mail servers. They don’t prove who was sitting at the keyboard.

A DMARC fail proves the message didn’t originate from an authorized sender for the claimed domain. It doesn’t prove the defendant was the one who sent it — that requires additional evidence tying the originating IP or infrastructure to a specific person.

CCE and EnCE holders working email cases should expect opposing counsel to challenge your methodology on authentication protocol definitions. Know RFC 7208 (SPF), RFC 6376 (DKIM), and RFC 7489 (DMARC) well enough to discuss them without notes.

When Headers Have Been Stripped or Manipulated

Some mail services strip headers before delivery. Consumer webmail sometimes normalizes headers in ways that remove routing information. And in rare cases, sophisticated attackers manipulate headers to mislead investigators.

Signs of potential header manipulation:

When you suspect manipulation, the absence of expected data is itself significant. Document what should be present based on normal RFC 5322 message structure and what’s missing.

For cases where headers alone are insufficient, request server-side logs directly from the email provider via legal process. Those logs exist independent of the message and are much harder to manipulate after the fact.

Working Email Header Analysis Into Your Standard Process

Email cases are more common than examiners expect. Business email compromise, phishing, harassment, employment disputes, family court matters — all of them can turn on whether a particular email was sent when and by whom it claims.

Make header analysis a standard step in any investigation involving email evidence. The analysis itself takes minutes once you’re practiced. The documentation takes longer, but it’s that documentation that holds up when opposing counsel challenges your work.

Pull the raw headers for every significant message. Log the authentication results. Map the routing path. Note the originating IP. Cross-reference the timestamp against other timeline evidence.

The visible sender address is just a label. The headers are the proof.

For examiners looking to pair email analysis with full device examination, see our guides on [Outlook PST forensic parsing](/outlook-pst-forensic-parsing/) and [RAM capture for civil investigations](/ram-capture-civil-investigations/), which address how email evidence fits into broader digital forensic workflows.