Email Header Forensics: Your Guide to Reading the Raw Evidence

Another user-reported phish hits the queue. The display name says 'CEO Action Required' and the subject line screams urgency. Your first instinct is to check the sender's email address, but you already know that’s child’s play to forge. The real story—the verifiable, objective truth—isn’t in the body of the message. It's in the headers.

Most analysts give headers a quick glance, look for a 'pass' or 'fail', and move on. That's a mistake. The raw email header is the digital equivalent of a chain of custody document. It’s the single most under-read crime scene in information security, packed with evidence that can definitively prove or disprove an attack.

Reading them isn't black magic. It's a skill. And like any skill, it requires a repeatable method. Let’s walk through the exact process you can use to pull verifiable signals from the noise, fast.

Trace the Path: Read the Received Chain From the Bottom Up

This is the most critical rule, and the one most people get wrong. The headers in an email are listed in reverse chronological order. The first hop is at the bottom, and the final delivery to your inbox is at the very top. Always, always read a `Received:` chain from the bottom up to reconstruct the message's actual path through the internet.

Each Mail Transfer Agent (MTA) that handles the message prepends its own `Received:` header. Think of it like a postal worker stamping the letter as it leaves their facility. The first stamp is applied by the sender's own outbound server. The last stamp is applied by your organization's mail gateway right before it lands in the user's mailbox.

Each `Received:` line tells you who the server is (`by mail.your-company.com`) and who it received the message from (`from mail-sor-f41.google.com`). This `from` clause is where you find your first piece of hard evidence: the IP address and hostname of the server that handed off the message. Is the bottom-most entry from a server you trust? Does its IP belong to the purported sending organization? If you're analyzing an email from a business partner but the first hop is a residential IP in a different country, you’ve already got a massive red flag.

Authentication Isn't Just Pass/Fail—It's a Story

After establishing the path, your next stop is the `Authentication-Results` header. This is the receiving server’s consolidated report card on the email's legitimacy, and it's where the core email authentication protocols are judged.

SPF, DKIM, DMARC: The Pillars of Trust

SPF (Sender Policy Framework, RFC 7208) is an IP address allowlist. The domain owner publishes a DNS record saying, “Only servers at these IPs are authorized to send email for my domain.” DKIM (DomainKeys Identified Mail, RFC 6376) provides a cryptographic signature. It creates a hash of the email's body and key headers, then signs it with a private key. The receiving server uses a public key from the sender's DNS to verify the signature, proving the message hasn't been tampered with in transit.

DMARC (Domain-based Message Authentication, Reporting, and Conformance, RFC 7489) doesn't authenticate anything itself. It's the policy layer. A DMARC record tells the receiver what to do if SPF or DKIM checks fail: `p=none` (monitor), `p=quarantine` (send to spam), or `p=reject` (block entirely). Crucially, DMARC requires *alignment*. It’s not enough for SPF or DKIM to pass; the domain used for the passing check must match the domain in the user-visible `From:` header. This is what stops an attacker from sending a perfectly authenticated email from their own domain (`evil.com`) while spoofing your CEO's address (`your-company.com`).

Authentication-Results: mx.google.com; dkim=pass header.i=@corp-domain.com header.s=google header.b=abc123de; spf=softfail (google.com: domain of transitioning user@corp-domain.com does not designate 209.85.220.41 as permitted sender) smtp.mailfrom=user@corp-domain.com; dmarc=fail (p=REJECT sp=REJECT dis=NONE) header.from=corp-domain.com

Verdicts Tell You More Than Just 'Pass'

Pay close attention to the specific verdicts. An SPF `softfail` is very different from an SPF `fail`. A `softfail` (indicated by `~all` in the SPF record) is a weak negative signal, often used by organizations who aren't confident in their IP list. A `fail` (`-all`), however, is an explicit statement that the sending IP is unauthorized. Likewise, you might see `temperror` (temporary DNS lookup issue) or `permerror` (malformed DNS record). These point toward misconfiguration, not necessarily malice, but still erode trust in the message.

Forwarding Breaks Everything. ARC Tries to Fix It.

You're triaging an alert and see failing SPF and DKIM checks, but the email content seems benign. It’s a calendar invite from a vendor that was sent to a shared partner mailbox and then forwarded to the user. This is a classic failure mode. Intermediary mail servers, like forwarders or mailing list processors, are notorious for breaking standard authentication.

SPF breaks because the forwarding server's IP address isn't listed in the original sender's SPF record. Of course it isn't. DKIM often breaks because the intermediary adds a footer like '[External Email]' or rewrites the subject line, which changes the message body or headers and invalidates the cryptographic signature.

This is where the Authenticated Received Chain (ARC), defined in RFC 8617, comes in. ARC is designed to preserve the original authentication results across multiple hops. An ARC-compliant intermediary will evaluate the email's authentication upon receipt. It then creates a new `ARC-Authentication-Results` header that snapshots those original results. Finally, it creates an `ARC-Seal`, which is a DKIM-like signature that covers the previous ARC headers. Each subsequent hop adds its own seal, creating a trusted chain.

If you see failed DMARC but spot a series of `ARC-Seal` headers with `cv=pass` (chain validation passed), it's a strong indicator that the email was legitimate at its origin and was simply altered by a known intermediary. The final receiver can trust the ARC chain, see the original 'pass' verdict, and choose to deliver the message despite the final DMARC failure.

Anomalies That Reveal the Attacker's Hand

Beyond the formal authentication mechanisms, the headers themselves can contain telltale signs of deception. Attackers can be lazy, and their tools often leave artifacts that simple inspection will uncover.

Mismatched Domains and Return Paths

Business Email Compromise (BEC) thrives on the difference between the message's cosmetic `From:` header (`header.from`) and its envelope sender (`envelope.from`). The `From:` header is what the user sees in their client. The envelope sender is specified in the SMTP `MAIL FROM` command and is recorded in the `Return-Path` header. This is where bounces are sent.

In a typical BEC attack, an attacker will spoof the `From:` header to be `ceo@yourcompany.com` while the `Return-Path` points to `attacker@phishdomain.com`. Why? Because `phishdomain.com` has a valid SPF record for the attacker's server, allowing it to pass SPF authentication. DMARC alignment is designed to catch this, but if the target domain has a weak `p=none` policy, the check offers no protection. Always compare the `From:`, `Return-Path:`, and the `d=` domain in the DKIM signature. If they don't align, you have a problem.

Header Gaps and Injection Points

What if you see an email that appears to come from an external sender, but there's only one `Received:` header—the one from your own internal mail gateway? This is a huge red flag. It implies the message was injected directly into your mail flow, bypassing the normal internet delivery route entirely. This can happen via a compromised web server using an open relay configuration on your mail gateway, or an attacker using stolen credentials to authenticate to an API and inject mail.

The absence of evidence is evidence. A lack of external `Received:` headers means the trail starts inside your own walls. The investigation just pivoted from a phishing analysis to an internal compromise hunt.

A Repeatable Triage Workflow in Under Five Minutes

When the pressure is on, you need a process, not a research project. Here's a repeatable workflow you can execute on any raw email header to get to a confident disposition quickly.

First, find the first external `Received:` header by starting at the bottom. Examine the IP address and hostname. Does it make sense for the sender? Use a reverse DNS and GeoIP lookup to verify. This is your point of origin.

Next, jump to the `Authentication-Results` header logged by your own mail gateway (usually one of the top-most headers). Check the DMARC, SPF, and DKIM verdicts in that order. Did DMARC pass? If so, your job is likely done. If it failed, why? Was it a lack of alignment or an underlying SPF/DKIM failure? The details here guide your next step.

If authentication failed, scan the intermediate `Received:` headers for signs of a forwarder or mailing list. Look for keywords like 'forward' or server names like `listserv`. If you find them, immediately hunt for `ARC-Seal` headers. A valid ARC chain can explain the authentication failures and restore trust in the message.

Finally, perform a sanity check. Compare the domain in the `From:` header to the domain in the `Return-Path` and the DKIM signature (`d=`). Any mismatch not explained by a legitimate mailing list is highly suspicious. Check for obvious signs of spoofing, like typosquatting or homoglyph characters in the domain name. These simple checks flush out the majority of low-to-medium sophistication phishing attempts.

The takeaway

Reading email headers is a non-negotiable skill for any serious security analyst. It's the process of converting ambiguity into objective fact. It transforms the analysis from 'a user received a suspicious email' to 'I can prove this message originated from an unauthorized IP, failed DMARC alignment, and attempted to spoof our CFO.' That's the difference between guessing and knowing.

This manual process builds crucial muscle memory. Once you know what to look for, tools that automate email header forensics, like MailSleuth.AI, become exponentially more powerful by letting you focus on the verdict and its implications instead of spending your incident response time parsing text.