Email header analysis forensics is not a passive reading exercise. Every field in a raw header block is either evidence of how a message traveled, or evidence that someone tried to hide how it traveled. Security analysts who treat headers as decoration miss the story entirely. This guide walks through the practitioner workflow: reconstructing the full delivery path from raw Received headers, correlating timestamps across hops, identifying forged fields, and translating originating IP addresses into actionable attribution.

What Raw Email Headers Actually Tell You

The anatomy of a header block: fields, order, and trust boundaries

An email header block is a stack of key-value fields, each on its own line, terminated by a blank line before the message body. Fields can span multiple lines via folding whitespace. The order matters forensically: RFC 5321 specifies that each Mail Transfer Agent (MTA) prepends a new Received header as it accepts the message, so the block accumulates from the bottom up. The top of the stack is newest; the bottom is oldest.

The forensic mindset: treat the header block as a chain of custody log. Some entries were written by infrastructure you control or trust. Others were written by infrastructure the sender controls, or fabricated entirely.

Which fields are written by whom, and which can be forged

Fields break into two trust classes.

MTA-injected fields are written by the receiving server at each hop. These include Received, DKIM-Signature, and Authentication-Results. Because they are prepended by the receiving MTA, they cannot be altered by the sender after the fact, at least not for hops your own infrastructure handled.

Sender-controlled fields are composed by the sending mail client or server and carried unmodified through the chain. These include From, Reply-To, Subject, Date, Message-ID, and X-Mailer. Any of them can be set to any value the sender chooses. From is not validated by SMTP itself, the protocol relies on MTA-injected fields to surface discrepancies.

This trust boundary is the foundation of every forensic technique that follows.

Reconstructing the SMTP Delivery Path from Received Headers

Reading Received headers in reverse: bottom-up path reconstruction

RFC 5321 §4.4 mandates that each MTA prepend a Received header on acceptance. The delivery path therefore reads in reverse when you scan top-to-bottom. Misreading this ordering, treating the top Received line as the origin, is the most common beginner error in forensic email analysis.

The correct workflow: number each Received header from top to bottom, then read them in reverse order (highest number first). The bottom-most Received line is the first hop, the message's point of origin as seen by the first receiving server. Work upward toward your own MTA's entry.

If your inbox shows three Received headers numbered 1 (top), 2 (middle), 3 (bottom), then hop 3 → hop 2 → hop 1 is the actual delivery sequence. You are reconstructing the path by reversing the prepend stack.

SMTP hop analysis: parsing 'from', 'by', 'with', 'for', and 'id' clauses

Each Received header follows a structured format defined in RFC 5321. Here is a real specimen:

Received: from mail.attacker.example (mail.attacker.example [203.0.113.42])
          by mx.victim.example (Postfix) with ESMTPS id A1B2C3;
          Sat, 5 Jul 2026 09:14:22 +0000 (UTC)

Annotated clause by clause:

  • from mail.attacker.example, the HELO/EHLO hostname the sending server announced. Self-reported and unverified.
  • (mail.attacker.example [203.0.113.42]), the parenthetical contains the PTR (reverse DNS) name and the literal IP address in brackets. The receiving MTA injects the bracketed IP from the actual TCP connection; the sender cannot forge it for this specific hop.
  • by mx.victim.example (Postfix), the receiving MTA's hostname and software, written by the receiving server itself.
  • with ESMTPS, the protocol used. ESMTPS means TLS was negotiated. ESMTP without the S means plaintext. SMTP indicates a legacy connection.
  • id A1B2C3, the local queue ID assigned by the receiving MTA, useful for correlating with server logs.
  • Sat, 5 Jul 2026 09:14:22 +0000 (UTC), the timestamp recorded by the receiving MTA at the moment of acceptance.

The IP address 203.0.113.42 sits in the RFC 5737 documentation range and is used here as an example. In a live investigation, that bracket IP is your primary attribution target.

For reading email headers to diagnose delivery failures, the same clause parsing applies, but the forensic lens shifts from delivery latency to injection point identification.

Received Header Timestamp Analysis: Correlating Hops and Spotting Anomalies

Timestamps are the forensic clock of the delivery chain. Each Received header carries the time the receiving MTA accepted the message. Comparing timestamps across hops gives you transit latency between servers, and anomalies in that latency expose problems.

Normalize to UTC first. Timestamps in Received headers include timezone offsets (+0530, -0700, +0000). Convert every timestamp to UTC before comparing. A timestamp reading 09:14:22 +0530 is actually 03:44:22 UTC. Comparing raw clock values without normalization produces phantom gaps.

Expected latency between hops is typically under 60 seconds for a direct relay. A gap of 5–30 minutes usually indicates a spam scanning queue or greylisting hold. Hours-long gaps can mean a deferred delivery queue. These are explainable and common.

Anomalies worth flagging:

  • A timestamp on a lower (older) hop that is later than the hop above it. Timestamps must increase as you move up the chain, a reversal indicates either a misconfigured server clock or a forged header inserted out of sequence.
  • A gap larger than several hours between two apparently direct relays with no MX-level explanation.
  • A Date header (sender-controlled) that predates the bottom-most Received timestamp. A message cannot have been written after it was received. Large discrepancies suggest the Date field was backdated.

Timezone spoofing is also used to obscure origin. An attacker can set a misleading offset in a sender-controlled Date field. The MTA-injected Received timestamps are more reliable, but even those depend on the clock accuracy of each relay, a server with a drifting NTP clock introduces noise into the timeline.

Identifying Forged Email Headers and Injection Points

The trusted boundary: where forgeries enter the chain

The trust boundary is the first Received header your own infrastructure wrote. Everything above that line was written by MTAs you operate or have contractual visibility into (your MX server, your filtering gateway). Everything below that line was written by the sender's infrastructure, or fabricated to look like it wasn't.

To locate the boundary: identify the by clause that names your own MX hostname. That line and everything above it is within your trust perimeter. The line immediately below it is the first untrusted hop, the last external server that handed off the message before your systems touched it.

Injection points show up as inconsistencies at or near that boundary:

  • Private-range IPs in a public hop. If a Received header shows [10.0.0.1] or [192.168.x.x] in a position that should represent a public internet relay, the header is fabricated. RFC 1918 addresses don't route on the public internet.
  • HELO name mismatch. The HELO hostname in the from clause does not match the PTR record for the bracket IP. A legitimate server's PTR should resolve back to a name consistent with its domain. A significant mismatch is a strong indicator of a misconfigured or deceptive sender.
  • Extra Received headers below the origin. Attackers sometimes prepend fake Received headers to simulate a longer, more legitimate-looking delivery chain. These fabricated headers appear below your expected origin hop and are often detectable by impossible IPs, implausible hostnames, or timestamps that break the chronological sequence.

Email spoofing detection via header inconsistencies

Email spoofing detection means comparing fields across trust classes. The classic example: a From header reading PayPal Security <[email protected]>, note the digit 1 substituted for the letter l. The display name reads as legitimate in most mail clients. The actual sending domain fails SPF and DMARC alignment. Analysts who read only the display name in their client miss the envelope mismatch entirely.

Common forged field patterns:

  • From vs. envelope sender mismatch. The RFC 5321 MAIL FROM envelope address (visible in Return-Path) differs from the RFC 5322 From header. DMARC alignment checks exactly this.
  • Reply-To hijacking. The From field shows a legitimate address; Reply-To redirects responses to an attacker-controlled inbox. The original sender appears legitimate; replies go elsewhere.
  • Display-name spoofing. A trusted brand name in the display field, with a completely unrelated actual address. Most consumer mail clients show only the display name.
  • Header injection via malformed input. In some legacy systems, newline characters injected into form fields allow an attacker to append arbitrary headers. The resulting message carries headers that appear MTA-injected but are not.

Correlating Authentication Results: SPF, DKIM, and DMARC as Forensic Signals

Reading Authentication-Results headers as a verdict chain

The Authentication-Results header is written by your receiving MTA and records the outcome of SPF, DKIM, and DMARC evaluation. It is MTA-injected, and therefore within your trust boundary, but only for the instance written by your own infrastructure. An Authentication-Results header appearing below your trust boundary was written by an external server and should not be treated as authoritative.

Read the header as a verdict chain:

  • SPF pass means the sending IP was authorized by the envelope domain's SPF record. softfail means the record discourages but does not prohibit that IP, forensically, this is a yellow flag, not a clear failure. hardfail (-all) means the IP is explicitly unauthorized.
  • DKIM pass means the signature verified against the public key in DNS for the signing domain. It says nothing about whether that domain is the one the user sees in From.
  • DMARC fail means the authenticated domain (from SPF or DKIM) does not align with the From header domain. This is the failure that directly addresses spoofing of the visible sender.

What a DKIM pass on a phishing email actually means

A DKIM pass in a phishing email is one of the most misread forensic signals. An attacker can register paypa1.example, configure valid DKIM signing, send a message signed under paypa1.example, and receive a DKIM pass verdict. The signature is cryptographically valid. The domain is not PayPal.

DKIM proves the message body and selected headers were not modified in transit by an unauthorized party, and that the signing domain controlled the private key at send time. It does not prove the signing domain matches the From domain the user sees. That alignment check belongs to DMARC.

ARC (Authenticated Received Chain) headers, standardized in RFC 8617, add a further layer: they preserve the original authentication results across forwarding hops. When a message is forwarded through a mailing list, the SPF record for the original domain typically fails because the forwarder's IP is not listed. ARC allows the final receiving MTA to see what the authentication state was before forwarding. Without ARC, a forwarded phishing email can appear to pass authentication at the final hop. With ARC, you can distinguish a legitimately forwarded message from one that was never authenticated at origin.

Email Header IP Tracing: From Raw IPs to Attribution

WHOIS, rDNS, and ASN lookups for originating IPs

Once you've identified the originating IP from the bottom-most untrusted Received header's bracket value, the attribution workflow follows three steps.

Reverse DNS (rDNS). Query the PTR record for the IP. A well-configured legitimate server returns a hostname consistent with its sending domain. A hosting provider's generic PTR (e.g. 203-0-113-42.host.example) tells you the provider but not the customer. No PTR record is itself a signal, many spam sources and compromised hosts have none.

WHOIS. Query the IP's WHOIS record to identify the Regional Internet Registry (RIR) block owner and the registrant. ARIN covers North American blocks, RIPE NCC covers Europe and the Middle East, APNIC covers Asia-Pacific, and LACNIC covers Latin America, each maintains its own WHOIS database. The registrant is often an ISP or cloud provider rather than the end user, but the abuse contact in the WHOIS record is the target for abuse complaints.

ASN lookup. Identify the Autonomous System Number. The ASN tells you which network operates the IP range. Bulk senders and botnets often operate from ASNs associated with bulletproof hosting providers, ASNs with persistently high abuse report rates are a known pattern in the threat intelligence community.

Cross-referencing the HELO hostname, PTR record, and WHOIS registrant for consistency is the key step. A sender claiming to be mail.bank.example in the HELO clause, with an IP owned by a residential ISP in a different country, and a PTR pointing to an unrelated host, presents three independent inconsistencies, each a forensic signal, collectively strong evidence of a forged or compromised origin.

Building a forensic timeline and evidence package

Compile findings into a sequenced timeline. For each hop, record:

  1. The Received header text (verbatim)
  2. The bracket IP and HELO hostname
  3. The receiving MTA hostname (by clause)
  4. The normalized UTC timestamp
  5. rDNS, WHOIS registrant, and ASN for the bracket IP
  6. Authentication verdicts (SPF, DKIM, DMARC) from the Authentication-Results header

Lay these out in delivery order (bottom-up from the raw headers, top-down in your timeline). Flag each hop where an inconsistency appears. The result is a coherent narrative: where the message originated, what path it took, where authentication broke down, and what the attribution evidence points to.

This timeline format serves directly as the basis for an abuse complaint to the originating ISP, an incident report for a security operations team, or evidence supporting a legal referral. Precision in the hop sequence and timestamp normalization is what separates a usable report from a narrative an abuse desk will dismiss.

Every technique in this guide is expanded in Chapter 7 of Email Decoded, the practitioner's reference for reading raw email evidence with precision, covering the full authentication protocol stack, MIME forensics, SMTP response code analysis, and a complete annotated header corpus.