Email Header Forensics: Tracing a Message and Spotting Spoofing
Phishing emails survive on one assumption: nobody reads headers. The visible From: name is trivially forgeable, but every hop a message takes through the mail system is stamped into the header block — and those stamps are hard to fake consistently. Reading them is a learnable, mechanical skill.
Read Received headers bottom-up
Each server that touches the message prepends a Received: header. The newest hop is therefore at the top and the originating server is at the bottom. Start at the last Received: and walk upward, asking of each hop:
- Did the from host resolve to an IP you would expect for the claimed sender (their corporate mail range, their ESP, not a residential VPS)?
- Does the by host actually belong to the receiving organisation, or to an unknown relay?
- Are the timestamps monotonic? A hop dated before the hop beneath it signals a forged or replayed header.
- Does a hop use TLS? Look for (using TLSv1.3 with cipher …) — mail that supposedly came from a bank but travelled unencrypted across three hops is suspicious.
The X-Originating-IP (or the client IP inside webmail-generated Received lines) tells you which machine first injected the message. A login from an unexpected country is itself a finding.
Authentication-Results: trust the verifier, not the sender
Receiving servers prepend an Authentication-Results: header with their verdict on SPF, DKIM and DMARC. What matters is the alignment question:
- SPF pass but DMARC fail: the mail came from a server the envelope domain authorised, but that domain is not the one in the visible From: header — a classic forwarding or spoofing pattern.
- DKIM signed by a random domain: attackers sign their own spam to make it “authenticated”; only alignment with the From: domain means anything.
- No Authentication-Results at all: either the receiving chain stripped it, or the message was injected locally — both worth investigating.
Two commands cover the DNS side of the same investigation:
dig +short TXT example.com dig +short TXT _dmarc.example.com
A practical spoofing checklist
- Compare the Return-Path (envelope sender) domain with the visible From: domain; a mismatch alone is not proof of fraud, but a mismatch plus DMARC failure is.
- Check Reply-To: — phishing kits routinely set it to an unrelated address so replies leave the compromised thread.
- Look at Message-ID: a Gmail-format ID arriving via a random Qmail server is a red flag.
Header analysis is tedious by hand — the hops interleave, lines wrap, and some servers emit two Received blocks per hop. Paste the full raw header into the email header analyzer and it will parse the hop chain, extract the authentication verdicts and originating IPs, and lay the route out so the anomaly jumps out instead of hiding in wrapped text. Keep the raw message when you investigate: forwarders mangle headers, and the untouched original is the only copy worth analyzing.