GDE-080 |
Email header analysis | |||||||
Digital forensics | ||||||||
October 2026 | ||||||||
01
What it is
An email header analyzer is a tool that turns the hidden header of an email into a readable record of the servers it passed through, the time at each hop and the SPF, DKIM and DMARC results. Read carefully, that record helps test whether a message came from where it claims.
Every email carries a header above the visible message. It normally holds a Received line added by each server that handled it, a Message-ID meant to be unique and the authentication results written by the receiving server. The From line a reader sees is set by the sender and can say anything. The lines your own provider adds are much harder to fake.
SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting and Conformance) are the three checks that test whether a domain authorised a message. Journalists use header analysis on leaked emails and tips from new sources; fraud researchers use it on phishing and invoice scams.
| When to use this guide
|
02
How do you use an email header analyzer?
Five free tools and seven steps take you from a suspect message to a documented view of where it came from.
All five tools are free, and none needs an account for the checks in this guide.
Google Admin Toolbox Messageheader: Free, no login. Google's parser for pasted headers. Lists each hop with its delay, identifies the approximate source of any delivery delay and summarises the SPF, DKIM and DMARC results.
Microsoft Message Header Analyzer: Free, no login. Microsoft's web parser for pasted headers. Breaks out the Received hops and the authentication and anti-spam headers, and is a useful second reading alongside Google's tool.
MXToolbox Email Header Analyzer: Free, no login for header checks. Parses a pasted header into a readable table of hops and delays, with the anti-spam and authentication results.
RIPEstat: Free, no login. Run by the RIPE NCC. Returns the network, autonomous system number (ASN) and registered holder for an IP address taken from a Received line.
ICANN Lookup: Free, no login. Returns a domain's registrar and creation date, so a lookalike sending domain registered days before the message stands out.
| Before you begin Stop at the login. Every tool here works without an account. Do not reply to the message, click its links or open its attachments; copy the header text and work only from that. Legal considerations. Headers can contain IP addresses and email addresses, which can be personal data under GDPR and UK GDPR. Store raw headers securely, publish only what the story needs, and remember that a forwarded leak can carry details that identify whoever passed it on. |
In Gmail, open the message, click More next to Reply and choose Show original. In new Outlook, choose More actions, then View, then View message details. Ask a source to export the original as an .eml file, or forward it as an attachment, rather than forwarding it inline, because an inline forward carries a new header that describes the forward.
Paste the full header into Google's Messageheader and into a second tool such as MXToolbox, and save both outputs. Two parsers that agree reduce the risk of misreading a malformed or wrapped line.
Each server adds its Received line at the top, so the lowest line is the earliest. Record each hop's server name, IP address and timestamp, and check the times run in order. Lines added by your own provider are the most reliable; anything below them was written before the message reached your provider and can be forged.
Find the Authentication-Results line written by your own provider. SPF shows whether the sending server was authorised for the envelope sender's domain, DKIM whether a domain's signature verified, and DMARC whether a passing SPF or DKIM result aligns with the domain in the visible From address. Gmail and Yahoo since February 2024, and Outlook.com since May 2025, require bulk senders to authenticate with SPF, DKIM and DMARC, so a bulk mailing from a large organisation that shows no DMARC result deserves a closer look.
Write the three addresses side by side. A Reply-To on a different domain from the From address is a common sign of impersonation and invoice fraud. A different Return-Path is routine when mail goes out through a sending service, so check who owns that domain before reading anything into it. A lookalike spelling in any of the three is a strong lead to follow.
Check the sending domain's creation date in ICANN Lookup and the first external IP address in RIPEstat. A domain registered days before the message, or an IP held by a network the claimed sender has no reason to use, needs an explanation.
Contact the organisation through details you find independently, never those in the message, and ask whether the date, sending address and Message-ID match their records. Header analysis supports a conclusion; on its own it rarely settles one.
|
03
Where email header analysis goes wrong
Most errors come from trusting a line the sender could have written, or reading one result as a verdict.
Forged Received lines read as the real route: Anything below your provider's first Received line was written by the sending side and can be invented, including fake hops that point at an innocent server. Verifying check: the hop you rely on was added by a server you trust, and its IP sits in that provider's network in RIPEstat.
Webmail server IP read as the sender's location: Large webmail services usually record their own servers rather than the sender's device, so the first external IP often points to Google or Microsoft, not to a person or a place. Verifying check: the IP belongs to a network the claimed sender plausibly controls before you draw any location inference from it.
SPF or DKIM pass read as a genuine sender: A pass shows that some domain authorised the message, and that domain may be a lookalike the sender registered last week. Verifying check: DMARC passes and the authenticated domain matches the domain in the visible From address, or shares its registered domain, rather than a lookalike.
Authentication failure read as forgery: Forwarding, mailing lists and security gateways can break SPF and DKIM on legitimate mail. Verifying check: rule out a forwarding hop or an ARC (Authenticated Received Chain) header that explains the failure before you call the message spoofed.
Forwarded email header read as the original: A forwarded message carries the forwarder's header, so every check describes the forward rather than the first send. Verifying check: you are working from the original message or its .eml export, and the sender's organisation confirms its Message-ID.
Chain of custody: The raw header is the evidence; tool output is your reading of it. Keep the original message file unchanged so an editor, lawyer or court can rerun every check and reach the same result.
Export the original message as an .eml file and record its SHA-256 hash
Save the raw header as plain text without editing or reformatting it
Save each tool's result with the tool name, date and time visible
Record every IP address and domain lookup with its source and timestamp
Log how the message reached you, including any forward, to protect the source chain
04
Go deeper
Two reference cards and one Methods tutorial for the infrastructure behind a suspect email.
CARD · DIG-002 · SIGNAL TIER
Geolocate, fingerprint and attribute IP infrastructure
IPinfo, Shodan and BGP.tools, taken from an IP address to cross-referenced, hashed documentation.
METHODS · T35 · SIGNAL TIER
Website infrastructure analysis: WHOIS, DNS and SSL
WHOIS, DNS history, certificate transparency and BuiltWith, mapped to ownership and hosting history.
CARD · DIG-001
WHOIS investigation: from domain name to attribution chain
ViewDNS, SecurityTrails and crt.sh, pivoted from a registrant email to mapped domain infrastructure.
Evidentiary standard
Signal & Shadow operates to the LST-001 evidentiary standard. All claims are graded against the LST-001 v1.0.3 confidence tiers (Confirmed, Corroborated, Reported, Alleged) per the canonical voice and structural specification.
About Signal & Shadow
Signal & Shadow is an independent forensic investigation and methodology practice publishing tutorials, reference cards, and forensic dossiers for working practitioners. Founded by Derek Bowler.