Email Header Analysis: Reading the Route
How RFC-5322 routing hops, cryptographic authentication signals (SPF, DKIM, DMARC), and server timestamps separate genuine origin from spoofing.
A printed screenshot or PDF of an email body omits the most important technical evidence: the full RFC-5322 message header. While display names and "From" lines are trivially forged, the transit headers recorded by receiving mail servers preserve a bottom-up chronological ledger of how the message actually traveled.
In our OSINT and forensic reviews, we examine headers in context rather than treating a single field as conclusive:
- Transit Hops (Received Lines): Reading from bottom to top to trace the message path across originating clients, relay hosts, and recipient MX gateways, while accounting for webmail or API-based submission where client IPs may be masked.
- Cryptographic Authentication: Evaluating SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) cryptographic signatures, and DMARC alignment to determine whether a domain genuinely authorized the transmission or if header spoofing/modification occurred in transit.
- Timestamp & Timezone Skew: Normalizing UTC offsets across server hops to spot fabricated chains, delayed relays, or backdated local client clocks.
Whether evaluating a disputed business communication, a phishing pretext, or an alleged threat message, proper header analysis establishes what the technical routing record actually proves—and where carrier or provider logs are needed to complete attribution.