Email Header Forensics in 2026: How Investigators Read SPF, DKIM and DMARC

Why Email Header Forensics Matters in 2026

Email remains the dominant phishing plus business email compromise (BEC) attack vector in 2026. Vendor-impersonation scams (where attackers pose as a known supplier plus request payment redirection) cost Canadian mid-market organizations material amounts annually. Internal incident response teams investigate suspected phishing messages, legal counsel reviews BEC fraud cases plus law enforcement traces the messages back to attacker infrastructure. In every case the message header content is the primary forensic record.

The investigation question is consistent: does the sender claim in the From header match what the authentication protocols actually verified? When the answer is no, the gap reveals attacker tradecraft. When the answer is yes, the message is genuinely from the claimed sender (which can be the attacker themselves when an internal account is compromised). The protocol-level forensic record is the load-bearing evidence in either case.

SPF: The IP Address Authorization Check

The Sender Policy Framework (RFC 7208) is the protocol that lets domain owners publish a list of mail server IP addresses authorized to send mail for the domain. The domain owner publishes a TXT record at the domain DNS containing the SPF policy. Receiving mail servers fetch the SPF record at message receipt plus compare the connecting IP address against the published list.

The investigator reads the Received-SPF header (or the SPF result inside Authentication-Results) to confirm the outcome. SPF pass means the connecting IP was in the authorized list. SPF fail means the IP was explicitly rejected. SPF softfail means the IP was outside the authorized list but the domain owner used a soft policy (~all rather than -all). SPF neutral means the policy did not assert an opinion. SPF none means no SPF record was published.

For forensic interpretation the SPF result alone does not establish authenticity because SPF only checks the envelope sender (the Return-Path) which can differ from the visible From header. Phishing messages routinely pass SPF for the attacker-controlled bounce domain while spoofing the From header to display the victim's vendor. SPF tells investigators where the message was relayed from at the SMTP layer; it does not confirm the From header sender.

DKIM: The Cryptographic Content Signature

DomainKeys Identified Mail (RFC 6376) addresses the SPF limitation by cryptographically signing message content with a domain-controlled key. The domain owner publishes a DKIM public key in DNS plus the outbound mail server signs each outgoing message with the private key. The signature covers selected header fields plus the message body. The receiving mail server fetches the public key plus verifies the signature.

The investigator reads the DKIM-Signature header to extract the signing domain (the d= field), the selector (the s= field which identifies which key was used) plus the canonicalized fields list (the h= field). The Authentication-Results header records the DKIM verification outcome: dkim=pass means the signature verified, dkim=fail means it did not, dkim=neutral or dkim=temperror or dkim=permerror cover other states. A passing DKIM signature establishes that the message body plus signed headers have not been modified since the signing point plus that the signing domain controlled the key at the time of signing.

For forensic interpretation a passing DKIM signature on the From header signing domain is the strongest authenticity signal. A failing DKIM signature on a message claiming to come from a known sender is a high-confidence indicator that the message has been modified in transit or that the From header was spoofed by an unauthorized sender. A missing DKIM signature on a message from a domain that historically signs all outbound mail is also an indicator that warrants investigation.

DMARC: The Policy That Ties SPF and DKIM Together

Domain-based Message Authentication, Reporting and Conformance (RFC 7489) is the policy layer that tells receiving mail servers what to do when SPF or DKIM fails. The domain owner publishes a DMARC policy in DNS specifying whether failing messages should be rejected, quarantined or passed through plus where authentication failure reports should be sent. DMARC requires that the From header domain match the SPF or DKIM signing domain (alignment) which closes the SPF From-header gap.

The investigator reads the DMARC result inside Authentication-Results. dmarc=pass means the message satisfied DMARC alignment with at least one of SPF or DKIM. dmarc=fail means it did not. The DMARC policy itself (p=reject, p=quarantine, p=none) tells the investigator what enforcement action the receiving mail server took.

For forensic interpretation a DMARC fail combined with a p=reject policy plus message delivery to the inbox is itself an artifact: the receiving organization configured its mail server to ignore the publishing domain's reject directive or the receiving mail server failed to enforce the policy correctly. Either case is a finding that affects the broader investigation plus the remediation recommendations.

Reading the Received Header Chain

Beyond the authentication headers the Received header chain documents the message journey from the sending mail server through every intermediate hop to the receiving mail server. Each Received header records the previous hop, the receiving server name, the timestamp plus often the TLS state. The chain reads bottom-up: the bottom Received header is the original send, the top Received header is the final delivery hop.

For forensic reconstruction the Received chain identifies the originating IP address (in the bottom Received header), the routing path plus any third-party mail security gateways (Microsoft Defender for Office 365, Mimecast, Proofpoint, Barracuda) that processed the message. Anomalies in the Received chain (out-of-order timestamps, missing hops, mismatched server names) often reveal attacker infrastructure or interception attempts.

How Investigators Read Modern Phishing Headers

Modern phishing messages use several patterns that investigators encounter routinely. The compromised legitimate account pattern: attacker sends from a real compromised account at a legitimate domain. SPF passes (because the connection is from the legitimate mail server), DKIM passes (because the legitimate server signs the message) plus DMARC passes (because everything aligns). The header analysis does not flag the message; the investigation pivots to the account compromise timeline plus the unusual sending behavior of the account.

The lookalike domain pattern: attacker registers a domain that visually resembles the target (replacing letters with similar-looking Unicode characters, adding common typos). SPF plus DKIM plus DMARC all pass for the lookalike domain because the attacker controls the DNS plus the keys. The header analysis flags the From header domain as not the expected domain; the investigation focuses on the domain registration history plus the connection between the attacker domain plus the impersonated entity.

The spoofed From header pattern: attacker sends from an unrelated mail server with a forged From header. SPF fails or softfails for the From header domain because the connecting IP is not in the authorized list. DKIM fails because the sender does not control the From header domain key. DMARC fails the alignment check. The header analysis flags the authentication failures plus the investigation focuses on the originating infrastructure identified in the Received chain.

Where Sherlock Email Analyzer Fits

The Sherlock Email Analyzer parses email message headers plus exposes the authentication header analysis in a structured forensic report format. The tool extracts the SPF, DKIM plus DMARC results from Authentication-Results, parses the DKIM-Signature plus Received chain headers plus produces a per-message forensic summary. For organizations handling phishing investigations or BEC reconstruction at scale the tool provides the structured workflow that examiners need.

For litigation contexts the Sherlock Email Analyzer output pairs with the underlying message file (typically EML or MSG format) plus the chain of custody documentation needed for evidence submission. Canadian civil litigation plus regulator notification contexts both accept message header forensic analysis as the load-bearing technical evidence for sender authenticity claims.

Email is the dominant phishing vector in 2026 plus the dominant BEC fraud vector. Header forensics is the foundational technical skill for investigators in either case.