Master email header forensics — tracing the true sending path through the Received chain, decoding every SPF/DKIM/DMARC result and bypass technique, pivoting from a single IOC to a full campaign infrastructure map, and producing structured threat intelligence output ready for SIEM ingestion and cross-organisation sharing.
Email Header Forensics
Email headers are the forensic record of a message's journey from sender to recipient. They contain timestamps, server IPs, authentication results, and routing decisions that expose the true origin of a phishing email even when the visible sender is convincingly spoofed. Advanced analysis goes beyond reading the Received chain — it involves correlating infrastructure across campaigns, decoding spoofing bypass techniques, and building a complete IOC set for threat intelligence.
Email remains the primary initial access vector for most breach investigations. The ability to quickly and accurately triage a suspicious email — extracting its true origin, validating authentication results, and mapping its infrastructure — is one of the highest-value analytical skills in a Security Operations Centre. A well-analysed header often provides more actionable intelligence in five minutes than hours of post-compromise log review.
Why Email Analysis Skills Are Foundational
Email-based threats — phishing, spear-phishing, business email compromise, and malware delivery — represent the initial access technique in the majority of ransomware incidents, data breaches, and financial fraud cases. The ability to analyse an email header quickly and correctly determines whether your organisation detects a campaign in its first hour or its first week. Early, accurate analysis enables blocking at the mail gateway, enrichment of SIEM alerts, and threat intelligence sharing that protects other organisations from the same infrastructure.
Every letter sent through the postal system accumulates postmarks and handling stamps as it passes through sorting facilities. The visible address on the envelope is what the sender wrote — it can be anything. The postmarks are added by each sorting facility and cannot be retroactively forged. An investigator reconstructing a letter's true journey reads the postmarks from last to first, because each facility stamps when it received the item, not when it sent it. Email Received headers work identically — each mail server stamps when it received the message, building a trail from the final destination back to the true origin that the sender cannot falsify.
Reading the Received Chain
Received headers are added in reverse — the bottom header is where the email originated. Read bottom to top to trace the path from attacker infrastructure to victim mailbox. Each Received header follows the format: "from [sending host] by [receiving host] with [protocol]; [timestamp]".
# Third hop -- your server received from: Received: from mail.corp.com by mx.corp.com with ESMTP # Second hop: Received: from relay.sendgrid.net [167.89.123.45] by mail.corp.com # First hop -- true origin at the BOTTOM: Received: from unknown [185.234.12.44] by relay.sendgrid.net # 185.234.12.44 is the true sending IP -- look up in threat intel # "unknown" hostname = attacker didn't configure reverse DNS (common IOC)
What to Extract from Each Received Header
Each hop in the Received chain tells you something specific. Practising systematic extraction of four data points from every hop is the foundation of efficient header analysis:
- Sending host/IP: The IP address in brackets is the actual connection source. The hostname before it is what that IP claims to be (may be falsified). Discrepancy between the two is immediately suspicious.
- Receiving server: Confirms the message path through your expected mail infrastructure. Unexpected servers appearing in the chain may indicate mail relay abuse or compromised infrastructure.
- Protocol and encryption: ESMTPS indicates TLS-encrypted relay (expected for legitimate mail). Plain SMTP without TLS on an internal hop is a quality finding. ESMTPA indicates authenticated SMTP — useful for tracing abuse of legitimate mail services.
- Timestamp: Each timestamp should be chronologically later than the one below it. A timestamp that is earlier than the previous hop indicates header injection or tampering and is a significant red flag.
SPF, DKIM, and DMARC Deep Dive
SPF Checks if sending IP is authorised by domain's DNS TXT record PASS = authorised | FAIL = not in SPF record | SOFTFAIL = ~all qualifier Bypass: attacker uses subdomain or cousin domain with no SPF configured DKIM Cryptographic signature on message body and selected headers PASS = message unaltered, signature valid for signing domain FAIL = modified in transit, key revoked, or forged Bypass: sign with attacker's own domain -- passes DKIM, fails DMARC alignment DMARC Policy requiring SPF or DKIM to align with the visible From domain PASS = at least one aligns | FAIL = neither aligned with From domain p=none = monitoring only, email still delivers despite fail Bypass: target domain has p=none policy -- enforcement disabled
Understanding Each Result in Detail
The Authentication-Results header is the single most important header for rapid triage. Understanding what every possible combination of SPF/DKIM/DMARC results means — including the subtle cases — is essential for accurate analysis:
| SPF | DKIM | DMARC | Interpretation | Action |
|---|---|---|---|---|
| pass | pass | pass | Legitimate mail from authorised, unmodified source. Lowest phishing probability. | Baseline — still check sending IP and content |
| fail | fail | fail | Unauthenticated mail claiming to be from a domain. Classic spoofing attempt. | High confidence phishing — examine full chain |
| pass | pass | fail | DKIM passes for attacker's domain (not From domain). Sophisticated bypass — attacker has their own signing key. | DMARC alignment failure despite passing checks — BEC indicator |
| softfail | pass | pass | SPF ~all qualifier — sending IP not in record but not hard-failed. DKIM alignment saves DMARC. | Investigate sending IP — may be forwarded or relayed mail |
| pass | none | pass | SPF aligns and passes. DKIM not configured. DMARC passes on SPF alone. | Note DKIM absence — recommend adding. Otherwise legitimate. |
| fail | pass | pass | Forwarded or legitimately relayed mail where original SPF breaks but DKIM survives forwarding. | Check if forwarding is expected. DKIM alignment confirms legitimate origin. |
p=none means the domain owner has set up monitoring only — emails that fail DMARC are still delivered. When you see dmarc=fail action=none in Authentication-Results, the email passed through despite the failure. This is one of the most common configurations in mature phishing campaigns targeting domains whose owners haven't enforced DMARC: the attacker knows the email will deliver regardless. Note this prominently in your analysis — it is a finding worth reporting to the targeted domain's administrators.Header Analysis in Practice
The display name matches a trusted person but the actual address belongs to an attacker domain — victims who only see the name in their mail client are deceived.
# What the user sees in their mail client: From: CEO John Smith <ceo@corp.com> # What the raw header actually contains: From: "CEO John Smith" <j.smith@corp-invoices.net> whois corp-invoices.net: registered 3 days ago VirusTotal: 8/90 engines -- phishing # Attacker-registered lookalike domain used for BEC attack
The sending IP often hosts multiple phishing domains — pivoting from a single IP reveals the full campaign infrastructure and additional IOCs for blocking.
# Origin IP from bottom Received header: 185.234.12.44 whois 185.234.12.44 ASN: AS45839 -- Shinjiru Technology (bulletproof hosting) curl "https://api.abuseipdb.com/api/v2/check?ipAddress=185.234.12.44" abuseConfidenceScore: 94 -- 847 reports: phishing/spam/malware # Passive DNS pivot -- other domains on this IP: corp-invoices.net payroll-secure.com hr-portal-login.net # All three are campaign infrastructure IOCs
A valid DKIM signature for the wrong domain passes DKIM but fails DMARC — a sophisticated bypass technique used in targeted BEC campaigns.
DKIM-Signature: d=corp-invoices.net; s=mail; (valid signature) Authentication-Results: dkim=pass header.d=corp-invoices.net (valid -- but not corp.com) dmarc=fail header.from=corp.com (From domain does not align) # DKIM passes for attacker's domain -- DMARC correctly catches this # If target has p=none DMARC policy, email still delivers despite fail
Many mail tools add X-headers exposing the sending software and server path — often inadvertently revealing the phishing kit in use, which is useful OSINT for tracking campaigns.
X-Originating-IP: 185.234.12.44 X-Mailer: PHPMailer 6.6.4 X-PHP-Originating-Script: 1000:mailer.php X-Source-Args: /var/www/html/phishing-kit/mailer.php # PHPMailer-based phishing kit on a rented server # /phishing-kit/ directory name is a useful threat intel search term
A thorough header analysis produces a structured IOC set ready for sharing and blocking across security tooling.
IP Addresses 185.234.12.44 (sending infrastructure) Domains corp-invoices.net, payroll-secure.com, hr-portal-login.net Email j.smith@corp-invoices.net URL http://company-secure-login.xyz/verify?token=abc123 File Hash sha256:3a4f8b2c... (attachment if present) MITRE ATT&CK T1566.001 Spearphishing Attachment T1598.003 Phishing for Information
What You Need to Know
Email Spoofing Taxonomy — Every Technique and How to Detect It
Attackers use multiple distinct email spoofing techniques with different detection profiles. Understanding the full taxonomy means you can identify which technique was used from the headers alone, which informs both your detection rule and the attacker's likely sophistication level.
Sets the display name to a trusted person while using a completely different sending address. Exploits mail clients that show only the name, not the address.
Detection: From header raw value. The display name ("CEO John Smith") differs from the email address domain. No authentication failure — this is not a protocol-level spoof.
Example: "CEO John Smith" <ceo@attackerdomain.com>
Claims to be from the exact target domain (e.g., corp.com) without authorisation. Blocked by SPF+DMARC enforcement but succeeds against p=none domains.
Detection: SPF fail + DMARC fail. Authentication-Results clearly shows misalignment.
Example: From: ceo@corp.com sent from an unauthorised IP
Registers a visually similar domain (corp-invoices.net, c0rp.com, corp.co) and sends from it. Passes all authentication checks — the domain is legitimate, just not the expected one.
Detection: Authentication-Results show pass for all three protocols. Threat is the domain similarity, not auth failure. Requires domain comparison analysis.
Uses a subdomain (mail.attacker.com, secure.attacker.com) that may not be covered by the parent domain's SPF policy. If the attacker controls that subdomain, DKIM passes for their key.
Detection: Sending domain is a subdomain not matching the From address domain. DMARC will catch this if the alignment is strict. Check if subdomain has its own DMARC record.
When all authentication checks pass, the threat analysis shifts to domain similarity detection. A systematic workflow catches lookalike domains that evade all protocol-level filters.
# Email passes all authentication -- looks legitimate at first glance: Authentication-Results: spf=pass, dkim=pass, dmarc=pass From: "Finance Team" <accounts@corp-payments.com> # Step 1: WHOIS the sending domain for age and registrant: whois corp-payments.com Creation Date: 2026-05-01 (6 days ago -- extremely suspicious) Registrant: Privacy Protected # Step 2: VirusTotal domain reputation: curl "https://www.virustotal.com/api/v3/domains/corp-payments.com" malicious: 12 vendors flagged as phishing # Step 3: dnstwist similarity check against legitimate domain: dnstwist --registered corp.com corp-payments.com MX:configured REGISTERED ← active mail infrastructure corppayments.com -- available corp-pay.com -- available # Domain age + threat intel flag + similarity = confirmed BEC infrastructure
Campaign Infrastructure Analysis — From Single Email to Full Picture
A single phishing email is rarely an isolated incident — it is a data point within a larger campaign using shared infrastructure. The most valuable output of header analysis is often not the analysis of the specific email but the infrastructure map it enables: all other domains, IPs, and campaigns sharing the same infrastructure as the one you're investigating.
The Pivot Chain
Infrastructure pivoting follows a chain: the sending IP leads to the hosting provider and other domains on that IP. Those domains lead to registration patterns (registrar, registrant email format, nameservers). The nameservers may cluster related campaign domains. The DKIM signing key selector may appear in other domains. Each pivot reveals more of the attacker's operational infrastructure.
Starting from a single suspicious email, a systematic pivot chain reveals an active phishing-as-a-service operation targeting multiple organisations simultaneously.
# Starting point: sending IP 185.234.12.44 # Pivot 1: Passive DNS -- all domains ever hosted on this IP: curl "https://api.securitytrails.com/v1/ips/185.234.12.44/domains" corp-invoices.net payroll-secure.com hr-portal-login.net bankofamerica-verify.com microsoft-365-login.net (14 total) # Pivot 2: DKIM selector reveals key reuse across domains: DKIM-Signature: d=corp-invoices.net; s=selector1 dig selector1._domainkey.payroll-secure.com TXT Same public key -- all domains share one DKIM signing infrastructure # Pivot 3: VirusTotal graph -- registration pattern: All 14 domains registered at same registrar, 2-week window All using nameservers: ns1.bullethosting.ru / ns2.bullethosting.ru # Common nameserver = single actor operating all 14 phishing domains # Result: 14 domains added to mail gateway blocklist # Shared infrastructure IOCs reported to sector ISAC for distribution
STIX/TAXII — Sharing What You Find
The IOC set produced by header analysis is most valuable when shared. STIX (Structured Threat Information eXpression) is the standard format for threat intelligence, and TAXII (Trusted Automated eXchange of Intelligence Information) is the protocol for sharing it. Most enterprise SIEMs and threat intelligence platforms support STIX/TAXII ingestion, allowing IOCs you produce to be automatically propagated to blocking controls across your toolstack and shared with sector information sharing communities (ISACs) to protect other organisations targeted by the same campaign.
Email Security Controls — Closing the Gaps Header Analysis Reveals
Header analysis is a reactive capability — it helps you understand attacks after they arrive. The partner capability is proactive hardening of your own domain's email authentication posture and your organisation's inbound filtering, so that the attacks you're analysing don't reach end users in the first place.
- DMARC p=reject: The single most impactful outbound control. Prevents exact domain spoofing of your domain. Requires SPF and DKIM to be correctly configured first. Transition through p=none → p=quarantine → p=reject with monitoring at each stage.
- Brand Indicators for Message Identification (BIMI): Displays your organisation's logo in supported mail clients for authenticated messages, making it visually obvious when a lookalike domain is used instead.
- Inbound mail gateway with reputation filtering: Check sending IP reputation against threat intelligence feeds in real time. Quarantine or block from known phishing infrastructure before content scanning even begins.
- Domain age filtering: Domains registered in the last 30 days are statistically far more likely to be phishing infrastructure than legitimate senders. A mail gateway rule quarantining all mail from recently-registered domains for manual review catches a significant proportion of BEC campaigns.
- Lookalike domain monitoring: Run dnstwist or similar against your primary domains weekly. Alert on newly registered lookalikes with MX records configured — proactive identification of BEC infrastructure before attacks begin.
Core Concepts Summary
You've covered the theory. Now apply it hands-on in the simulated environment.
Start Lab — Email Header Analysis→← Return to all labs