Most phishing emails look convincing on the surface.
Headers are where the story breaks.
They show how a message actually traveled, who sent it, and which systems trusted it.
For practitioners, headers are often the fastest way to confirm suspicion without opening links or attachments.
They do not prove intent on their own.
They reveal inconsistencies that phishing depends on.
What email headers really are
Email headers are routing and authentication records added by mail systems.
They include:
1. Sending and receiving servers
2. Authentication results
3. Timestamps
4. Message IDs
5. Transport paths
Every hop leaves a trace.
Phishing often leaves messy ones.
Key header fields attackers struggle to fake
From vs Return-Path
Phishing emails often rely on display names.
From: Finance Team <finance@company.com>
Return-Path: alerts@external-mailer.net
Mismatch here is common.
The user sees the “From” name.
Mail systems rely on Return-Path.
Received headers (the delivery path)
Each mail server adds a Received: line.
Received: from unknown (185.234.x.x)
by mail.company.com
Reading these bottom to top shows the real origin.
Red flags include:
1. Hosting providers unrelated to the sender
2. Residential IP ranges
3. Unexpected geographies
SPF results
SPF checks whether the sending server is allowed to send for a domain.
Received-SPF: Fail (domain of company.com does not allow 185.234.x.x)
A fail does not always block delivery.
Attackers rely on that.
DKIM signatures
DKIM proves a message was signed by a domain.
DKIM-Signature: v=1; d=external-mailer.com;
Key detail:
The signing domain (d=) may not match the visible sender.
This is common in phishing using third-party mailers.
DMARC alignment
DMARC ties SPF and DKIM to the visible sender domain.
Authentication-Results:
dmarc=fail (p=none)
A “fail” with p=none means the message is allowed anyway.
This is one of the most abused gaps.
Unusual message identifiers.
Message identifiers tend to have a regular format.
Message-ID:<random123@localhost>
Signs of problems with the Message ID:
1. localhost;
2. generic host names;
3. Domain does not reference where the message originates.
Usually means that tools and scripts are being utilized incorrectly.
Methods for evaluating headers:
An Evaluation through Manual Review
Most email Clients allow a full Viewing of the Headers.
You should look for:
1. Domains that do not match the sender's,
2. Authentication Failure,
3. Relay Servers that are unexpected.
Develops your intuition very quickly.
Google Admin Toolbox – Messageheader
Useful for fast parsing.
What it highlights:
1. SPF / DKIM / DMARC results
2. Source IP reputation
3. Routing path summary
Good for triage and screenshots.
mailparser and command-line tools
For bulk analysis.
mailparser -f suspicious.eml
Helpful when handling:
1. Incident response
2. SOC escalations
3. Training datasets
SWAK for reproduction testing.
This allows email flow assumptions to be tested.
swaks --to user@company.com \
--from finance@company.com \
--server mail.company.com
SWAK helps understand why a spoof was able to work.
Threat Intelligence enrichment
The headers contain both an IP and domain.
The information can be cross-referenced against
1. AbuseIPDB
2. VirusTotal
3. Passive DNS Services
These links are often associated with known email campaigns.
Phishing examples with practical applications
Example 1: finance@company.com fake email request from company finance department.
The email header has these indications:
1. Finance department received an email from finance@company.com
2. DKIM was authenticated by an external mailer (external-mailer.com)
3. SPF failure (failed) and no DMARC record.
This email was never sent on a company's email infrastructure.
Example 2: company impersonating vendor.
The email header has these indications:
1. Vendor domain was correct in from field
2. Return-Path was from lookalike (impersonated vendor) domain
3. Received headers from cheap VPS provider.
A look alike (impersonated) domain was used to bypass casual checks.
Example 3: internal email thread hijacked.
The email header has these indications:
1. DKIM signed in the headers with a DKIM signature
2. SPF signed in the headers with an SPF signature
3. The originating IP address belongs to a compromised partner mailbox.
The email originated from a trusted, but compromised third party.
Common mistakes when reading headers
1. Trusting “DKIM pass” alone
2. Ignoring alignment (who signed vs who claims to send)
3. Reading Received headers top-down
4. Assuming internal-looking emails are internal
Attackers rely on partial understanding.
How defenders use headers effectively
Experienced teams:
1. Triage phishing in under minutes
2. Identify campaign infrastructure quickly
3. Explain incidents clearly to non-technical staff
4. Improve DMARC enforcement decisions
Headers turn opinions into evidence.
Email headers do not make phishing obvious.
They make it explainable.
They show where trust was misplaced, not just that it was abused.
For practitioners, they remain one of the most reliable tools for separating real communication from carefully crafted fraud.
