Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.
Introduction
Every email carries far more metadata than the sender and subject line shown to the recipient. The full header block records the exact chain of mail servers that handled the message, the authentication checks the receiving mail system ran against the sender’s claimed domain, and often the originating IP address of the sending client — all of it added before the message reaches an inbox and largely outside a phishing actor’s control. For a SOC analyst triaging a user-reported phish, header analysis is usually the fastest way to move from ‘this looks suspicious’ to a defensible verdict.
Phishing remains one of the most common initial-access vectors in real intrusions, and most organizations receive far more reported or quarantined phishing email than any team can deeply investigate by hand. A repeatable header-and-content triage process — checking authentication results, tracing the Received chain, and extracting URLs and attachments for automated analysis — lets an analyst clear the bulk of reports quickly while reliably escalating the ones that matter.
Attack Prerequisites
Header analysis is a defensive triage technique; it depends on the analyst having:
- The raw message source, not just what the mail client renders —
.eml/.msgexport or ‘view source’/’show original’ from the mail client, since headers are stripped from the normal reading view. - A receiving mail system that performs and stamps authentication results — SPF, DKIM, and DMARC checks with an
Authentication-Resultsheader added by the recipient’s own MTA (Gmail, Microsoft 365, etc.), which is far more trustworthy than anything in the message body. - Sandboxed analysis tooling for any linked URLs or attachments — a browser-isolation or dedicated analysis VM, URL detonation service (e.g. urlscan.io), or a malware sandbox — never opened directly on an analyst workstation.
- Access to threat intel / reputation lookups — VirusTotal for hashes and URLs, WHOIS/passive DNS for domain age and infrastructure history.
How It Works
The Received: header chain is added, top-down, by every mail server the message passes through, so it must be read bottom-to-top — the bottom-most Received line is closest to the true origin, and each successive line above it represents one more hop toward the recipient. Crucially, only the hops added by servers you trust (your own organization’s mail gateway and the servers immediately upstream of it) are reliable; an external sender can forge Received lines that claim to originate earlier in the chain, which is why analysts anchor on the first hop their *own* infrastructure recorded rather than trusting the whole chain.
SPF (Sender Policy Framework) checks whether the sending IP is authorized to send for the domain in the MAIL FROM (envelope sender, often different from the visible From:). DKIM verifies a cryptographic signature added by the sending domain, proving the message (or at least the signed headers/body) was not altered in transit and did originate from a server holding that domain’s private key. DMARC ties the two together by requiring that the domain in the visible From: header *align* with the domain that passed SPF and/or DKIM, and tells receivers what to do on failure (p=none, p=quarantine, p=reject). The combined outcome is stamped into an Authentication-Results header by the receiving system — this is the single fastest field to check first.
A common and effective phishing technique bypasses none of these checks technically: display-name spoofing sets a friendly display name ("IT Support" <random123@freemail.example>) that most mail clients show prominently while truncating or hiding the actual address, and look-alike domains (micros0ft-support.com, paypal-secure.net, or Unicode homoglyph domains) register their own legitimate SPF/DKIM/DMARC records, so they pass every technical check while still being fraudulent — which is why header analysis must always be paired with manual review of the actual sending domain, not just a pass/fail glance at authentication results.
Practical Example / Configuration
A representative Authentication-Results header on a failed/spoofed message, and how to read each field:
Authentication-Results: mx.recipient-org.com;
spf=fail (recipient-org.com: domain of billing@paypal.com does not
designate 203.0.113.45 as permitted sender) smtp.mailfrom=billing@paypal.com;
dkim=none (message not signed) header.d=none;
dmarc=fail (p=REJECT sp=REJECT dis=none) header.from=paypal.com
# Reading this:
# - spf=fail : the sending IP (203.0.113.45) is NOT authorized for paypal.com
# - dkim=none : no valid signature present at all
# - dmarc=fail : From: claims paypal.com but neither SPF nor DKIM aligned to it
# - p=REJECT : paypal.com's own DMARC policy says receivers SHOULD reject this
# -> if your gateway delivered it anyway, that's a control gap
A triage checklist to apply in order for a reported email:
- Check
Authentication-Resultsfirst —dmarc=failon a domain publishingp=reject/p=quarantineis close to a definitive verdict on its own. - Compare
From:,Reply-To:, andReturn-Path:— a mismatch between the visible sender and where replies/bounces actually go is a strong spoofing/BEC indicator even when authentication technically passes (i.e. the phishing domain owns its own valid DKIM/SPF). - Read the
Received:chain bottom-up from your own gateway’s first-trusted hop to identify the originating sending IP and compare it against the claimed sender’s known infrastructure. - Extract and detonate URLs in isolation (urlscan.io, a sandboxed browser) rather than clicking directly, and check final redirect destinations, not just the first link.
- Hash and submit attachments to a sandbox/VirusTotal before any local interaction.
Walkthrough / Exploitation
Given a reported .eml file, a practical triage pass looks like this:
# Extract headers and body cleanly from the raw .eml with Python's email lib
python3 -c "
import email, sys
msg = email.message_from_file(open(sys.argv[1]))
for h in ['From','Reply-To','Return-Path','Authentication-Results','Received']:
for v in msg.get_all(h, []):
print(f'{h}: {v}\n')
" reported_phish.eml
# Pull all URLs out of the body for offline review / sandbox submission
python3 -c "
import email, re, sys
msg = email.message_from_file(open(sys.argv[1]))
body = msg.get_payload(decode=True) if not msg.is_multipart() else b''.join(
p.get_payload(decode=True) or b'' for p in msg.walk() if p.get_content_type()=='text/html')
print(set(re.findall(rb'https?://[^\s\"\'<>]+', body)))
" reported_phish.eml
For the originating sending IP found in the first trusted Received line, run a WHOIS/passive-DNS check against the claimed sender’s real infrastructure, and check the registration age of any look-alike domain found in From: or the extracted URLs — a domain registered days before the campaign is a strong, easily obtained indicator.
Note:
Return-Pathis the envelope sender used for bounce delivery and is what SPF actually validates against — it is frequently different from the visibleFrom:header even in legitimate mail (mailing lists, marketing platforms), so a mismatch alone is not proof of phishing; combine it with the DMARC alignment result before drawing a conclusion.
Opsec / Analyst tip: Never interact with a suspected phishing link or attachment from a standard analyst workstation — use an isolated VM with no access to credentials or internal resources, or a purpose-built detonation service, since some phishing kits fingerprint and behave differently for automated scanners versus real victims.
Detection and Defense
Header-analysis triage is most effective layered on top of enforced authentication controls at the gateway:
- Publish and enforce DMARC at
p=rejectfor your own domains once SPF/DKIM alignment is confirmed clean, closing off direct spoofing of your brand. - Configure the mail gateway to act on
Authentication-Results, not just log it — quarantine or reject hard SPF/DMARC failures rather than relying on user reporting. - Enable URL rewriting and attachment sandboxing at the gateway (time-of-click protection) so malicious links are re-evaluated even if the destination is weaponized after initial delivery.
- Provide and encourage a one-click ‘report phishing’ button feeding directly into the SOC triage queue with headers intact.
- Track look-alike domain registrations for your brand via a domain monitoring service to catch infrastructure before a campaign launches.
Real-World Impact
Phishing consistently ranks among the top initial-access vectors in industry breach reporting, and Business Email Compromise built on spoofed or look-alike sender domains remains one of the highest-dollar-loss categories of cybercrime reported to law enforcement. Because authentication-technically-valid look-alike domains routinely defeat naive SPF/DKIM/DMARC pass/fail checks, manual header and domain review by a trained analyst remains necessary even in organizations with mature email authentication enforcement.
Conclusion
Email headers carry evidence a phishing actor cannot fully control: authentication results, the trusted portion of the Received chain, and sender/reply-to/return-path relationships. A disciplined triage order — authentication results first, then sender consistency, then the Received chain, then sandboxed URL and attachment analysis — turns a large volume of user-reported email into a small number of confidently escalated incidents.
You Might Also Like
If you found this useful, these related deep-dives cover adjacent techniques and their defenses:
Comments