This chapter covers email header analysis for phishing detection, a critical skill for the CS0-003 Security Operations domain (Objective 1.2: Analyze indicators of compromise and formulate an appropriate response). Approximately 10-15% of exam questions involve analyzing logs or email headers to identify phishing or other malicious activity. You will learn the structure of email headers, how to trace the path of an email, how to interpret authentication headers (SPF, DKIM, DMARC), and how to spot common phishing indicators. This knowledge is essential for security analysts who must triage reported phishing emails and determine if they are malicious.
Jump to a section
Analyzing an email header is like examining a physical envelope that arrived at your office. The envelope has a postmark (timestamp), a 'From' address (sender), a 'To' address (recipient), and a route stamp showing every postal facility it passed through. But here's the twist: the sender can write anything they want in the 'From' field—just like a letter can have a fake return address. The real path is revealed by the postmarks and facility stamps. In email, the 'Received' headers are those stamps. Each mail server that handles the message adds its own 'Received' line, showing the IP address of the previous server, the timestamp, and its own identity. By reading these in reverse order (bottom to top), you trace the actual path the email took. The 'Return-Path' header is the envelope's return address—it's set by the sending mail server, not the user. SPF, DKIM, and DMARC are like trusted seals and signatures that verify the envelope wasn't tampered with. A phishing email often has a forged 'From' address, but the 'Received' chain reveals the true origin. The analogy breaks down because email headers contain many more fields (Message-ID, MIME boundaries, authentication results), but the core idea of tracing the physical path through stamps is directly analogous to tracing the server-to-server path through 'Received' headers.
What is an Email Header?
An email header is a structured block of metadata that accompanies every email message. Defined by RFC 5322, the header contains fields such as From, To, Subject, Date, Message-ID, and most importantly for analysis, Received and Authentication-Results headers. The header appears before the body and is not normally visible to end users; analysts view it through email client options (e.g., 'Show original' in Gmail, 'View message source' in Outlook).
Why Headers Matter for Phishing Detection
Phishing emails often spoof the From address to impersonate a trusted entity. The header reveals the true origin through the chain of Received headers and authentication checks. By analyzing headers, you can:
Determine the actual sending server (IP address).
Verify whether SPF, DKIM, and DMARC checks passed or failed.
Identify discrepancies between the displayed From and the envelope sender (Return-Path).
Detect suspicious routing, such as multiple hops through unexpected servers.
Structure of an Email Header
An email header is a series of lines, each starting with a field name followed by a colon and a value. Common fields: - From: Display name and email address (can be forged). - To: Intended recipient(s). - Subject: Subject line. - Date: Timestamp from the sending client. - Message-ID: Unique identifier generated by the sending mail server. - Received: Added by each mail server that processes the message, in reverse chronological order (most recent at top). - Return-Path: Envelope sender address (used for bounces). - Authentication-Results: Contains SPF, DKIM, DMARC verdicts. - DKIM-Signature: Contains the DKIM signature and selector. - SPF: (Not a header; SPF check results appear in Authentication-Results). - DMARC: (Policy applied; results in Authentication-Results). - X- headers: Custom headers added by mail servers or security gateways (e.g., X-PhishScore, X-Spam-Flag).
How to Read Received Headers (Tracing the Path)
The Received headers form a chain. The bottommost Received header is the first hop (originating server), and the topmost is the last hop (recipient's mail server). Each Received header typically includes: - from: The hostname or IP of the server that sent the message to this server. - by: The hostname of the receiving server. - with: The protocol used (ESMTP, SMTP, etc.). - id: A unique identifier for the transaction. - for: The recipient address. - timestamp: Date and time.
Example:
Received: from mail.example.com (192.168.1.1) by mx.recipient.com (Postfix) with ESMTPS id ABC123 for <recipient@example.com>; Mon, 1 Jan 2024 10:00:00 +0000To trace the path, start at the bottom and work upward. Look for IP addresses that are inconsistent with the claimed sender. For example, if the From address is @bank.com but the originating IP is in a country known for phishing, that's a red flag.
SPF (Sender Policy Framework)
SPF allows domain owners to specify which servers are authorized to send email on their behalf. Defined in RFC 7208. The sending domain publishes an SPF record (TXT record) listing permitted IP addresses. The receiving server checks the envelope sender domain (Return-Path) against the SPF record.
SPF Check:
Receiving server extracts the domain from the Return-Path.
It queries DNS for the SPF record of that domain.
It compares the source IP of the SMTP connection against the rules in the SPF record.
Result: pass, fail, softfail, neutral, none, temperror, or permerror.
SPF Mechanisms:
- ip4 / ip6: Allow specific IPs.
- include: Include another domain's SPF record.
- a: Allow the domain's A record.
- mx: Allow the domain's MX servers.
- all: Catch-all; -all (fail), ~all (softfail), ?all (neutral).
Example SPF record:
v=spf1 ip4:192.0.2.0/24 include:_spf.google.com ~allFor phishing, a fail result indicates that the sending server is not authorized. However, spammers can use domains with permissive SPF records or none.
DKIM (DomainKeys Identified Mail)
DKIM allows the sender to digitally sign the email using a private key. The public key is published in DNS as a TXT record under a selector. Defined in RFC 6376. The signature covers specific headers and the body, ensuring integrity.
DKIM Signature Header:
- v=: Version (usually 1).
- a=: Algorithm (rsa-sha256).
- c=: Canonicalization (simple/relaxed).
- d=: Domain (signing domain).
- s=: Selector (used to locate the public key).
- bh=: Body hash.
- h=: Headers signed (list of headers).
- b=: Signature.
DKIM Verification:
Receiving server extracts the domain (d=) and selector (s=).
It queries DNS: <selector>._domainkey.<domain>.
It retrieves the public key and verifies the signature.
Result: pass, fail, neutral, none, temperror, permerror.
A fail means the signature is invalid (tampering). Phishing emails often lack DKIM or have a fail result.
DMARC (Domain-based Message Authentication, Reporting & Conformance)
DMARC builds on SPF and DKIM. Defined in RFC 7489. The domain owner publishes a DMARC policy (TXT record at _dmarc.<domain>) specifying what to do if both SPF and DKIM fail: none (monitor), quarantine (spam), or reject. It also provides for reporting.
DMARC Check:
Receiving server performs SPF and DKIM checks.
It checks that the domain in the From header (the one the user sees) aligns with the SPF-authenticated domain or DKIM domain. Alignment can be strict (exact match) or relaxed (organizational domain match).
If both fail and no alignment, DMARC policy is applied.
Result: pass, fail, none, temperror, permerror.
DMARC Record:
v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@example.com; pct=100For phishing, a DMARC fail with a reject policy means the email should be rejected; if it lands in the inbox despite a fail, it's suspicious.
Other Important Headers
Reply-To: Can be different from From; used to redirect replies to an attacker.
X-Mailer: Identifies the email client used; can be spoofed.
Content-Type: MIME type; phishing often uses multipart/alternative with HTML.
X-Priority: Often set to high in phishing to create urgency.
Common Phishing Indicators in Headers
Mismatched From and Return-Path: The From shows a trusted domain, but Return-Path is a different domain.
SPF/DKIM/DMARC fail: Especially if the domain has a strict policy.
Suspicious Received chain: Originating IP from a known bad country or anonymous proxy.
Unusual Message-ID: Contains random strings or doesn't match the domain.
Missing or malformed headers: Phishers may omit headers to avoid detection.
Tools for Header Analysis
Online analyzers: MXToolbox, Google Admin Toolbox Messageheader.
Manual inspection: Use cat or less on raw email files; in Python, use email library.
SIEM integration: Parse headers with regex to extract IPs and authentication results.
Command-Line Header Extraction
On a Linux mail server, you can view raw headers of a specific email:
postcat -q <queue-id> | head -50In Python:
import email
with open('email.eml', 'r') as f:
msg = email.message_from_file(f)
print(msg['Received'])Obtain the Raw Email Headers
The first step is to retrieve the full email headers from the email client. In Gmail, open the email, click the three dots, and select 'Show original'. In Outlook, open the email, go to File > Properties, and look in 'Internet headers'. In Thunderbird, press Ctrl+U. The raw headers will appear as text, starting with 'Received: from ...' and ending with the email body after a blank line. Save this text to a file or copy it to an analyzer. On a mail server, you can use commands like `postcat` (Postfix) or `mailq` to view queued messages.
Identify the Received Header Chain
Locate all 'Received' headers. They appear in reverse chronological order: the topmost Received is the last hop (your server), and the bottommost is the first hop (originating server). Count them to understand the number of hops. Each Received header typically contains the sending server's IP (from), the receiving server's hostname (by), the protocol (ESMTPS, SMTP), a transaction ID, and a timestamp. Write down the IP addresses in order from bottom to top to trace the path. If there are many hops (e.g., >5), it may indicate routing through multiple intermediaries, possibly to hide the origin.
Examine the From and Return-Path Headers
Compare the 'From' header (the one displayed to the user) with the 'Return-Path' header (the envelope sender). In legitimate email, these often match or are from the same domain. In phishing, the From may be spoofed (e.g., 'support@bank.com') while the Return-Path is a different domain (e.g., 'phisher@evil.com'). Also check the 'Reply-To' header; if it differs from From, replies go to the attacker. Note any discrepancies. Also look at the 'Sender' header if present; it can override the From for some mailing lists.
Analyze Authentication Results
Look for the 'Authentication-Results' header. This is added by the receiving mail server and contains the results of SPF, DKIM, and DMARC checks. Example: `Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com`. If any of these show 'fail', it's a strong indicator of phishing. Note that a 'pass' can also be spoofed if the attacker uses a domain with a permissive SPF record. Also check the 'DKIM-Signature' header to see which headers were signed; if critical headers like From or Subject are not signed, it's a weakness.
Correlate Indicators and Make a Determination
Combine all findings. If the From domain is a well-known brand but SPF/DKIM/DMARC fail, and the originating IP is from a suspicious location, it's likely phishing. If the email claims to be from a colleague but the Reply-To is external, it's a spear phishing attempt. Also check the 'Message-ID' for anomalies (e.g., contains random characters). Look at 'X- headers' from security gateways; they may have already flagged it. Document the indicators (IPs, domains, authentication results) for further investigation or blocking. Finally, decide whether to delete, quarantine, or escalate.
Scenario 1: Corporate Email Gateway Triage
A large enterprise uses Microsoft Exchange Online with Advanced Threat Protection (ATP). The security team receives a user report of a suspicious email claiming to be from the CEO. The analyst extracts the raw headers from the quarantine portal. The Received chain shows the email originated from an IP in Nigeria (197.210.0.0/16), but the From header reads 'ceo@company.com'. The Return-Path is 'attacker@tempmail.com'. Authentication-Results shows spf=fail, dkim=fail, dmarc=fail (policy=reject). The analyst confirms it's a spear phishing attempt. The security team blocks the IP range and updates the DMARC policy to p=reject. They also add a mail flow rule to quarantine any email with a mismatch between From and Return-Path. This scenario is common; misconfigured DMARC (p=none) can allow such emails to reach inboxes.
Scenario 2: SOC Analyst Investigating a Phishing Campaign
A SOC analyst is investigating a wave of credential harvesting emails targeting employees. Using a SIEM, they pull raw email headers from the email logs. They notice that all emails have a common pattern: the Message-ID contains 'phishcampaign2024', and the X-Mailer is 'Microsoft Outlook 16.0' (but the real sender uses a Linux server). The Received headers show a consistent originating IP range from a bulletproof hosting provider. The SPF check fails because the domain's SPF record does not include that IP. The analyst creates a YARA rule to detect the Message-ID pattern and updates the firewall to block the IP range. They also recommend adding the domain to the blocklist. This scenario highlights the importance of correlating multiple header fields to identify patterns.
Scenario 3: Incident Response for Business Email Compromise (BEC)
A company falls victim to a BEC attack where the attacker spoofed the CFO's email. During incident response, the forensic analyst retrieves the original email from the victim's mailbox. The headers show that the email passed SPF and DKIM because the attacker used a compromised domain that had valid SPF/DKIM records. However, the DMARC check failed because the From domain did not align with the SPF-authenticated domain (the attacker used a lookalike domain like 'c0mpany.com'). The DMARC policy was p=none, so the email was delivered. The analyst recommends implementing DMARC with p=reject and training users to scrutinize the actual email address, not just the display name. This scenario underscores that SPF/DKIM alone are insufficient; DMARC alignment is critical.
What CS0-003 Tests on Email Header Analysis
The CySA+ exam (Objective 1.2) expects you to analyze indicators of compromise from email headers. Specifically, you must be able to:
Identify phishing indicators in headers (mismatched From/Return-Path, suspicious Received IPs, failed authentication).
Interpret SPF, DKIM, and DMARC results from Authentication-Results headers.
Trace the email path using Received headers to determine the true origin.
Understand the difference between envelope sender (Return-Path) and header From.
Common Wrong Answers and Why Candidates Choose Them
'The email is safe because SPF passed.' Candidates assume SPF pass means the email is legitimate. However, SPF only checks the envelope sender domain, which can be different from the From domain. An attacker can use a domain with a permissive SPF record. DMARC alignment is needed to ensure the From domain matches.
'The email is from the displayed domain because the From header says so.' Candidates forget that the From header can be easily spoofed. The true origin is in the Received chain and Return-Path.
'DKIM pass means the email is authentic.' DKIM only verifies that the email hasn't been tampered with and came from a server with the private key. But the signing domain may be different from the From domain. DMARC alignment checks this.
'The email is malicious because it has many Received headers.' Multiple hops can be legitimate (e.g., through mailing lists, forwarding). The number of hops alone is not an indicator; the specific IPs matter.
Specific Numbers and Terms on the Exam
SPF mechanisms: ip4, include, all with qualifiers -all (fail), ~all (softfail), ?all (neutral).
DKIM selectors: Default is often default or google.
DMARC policy values: none, quarantine, reject.
Alignment modes: strict (exact match) vs relaxed (organizational domain match).
Authentication results: pass, fail, softfail, neutral, none, temperror, permerror.
Edge Cases the Exam Loves
Forwarded emails: The Received chain may show the forwarding server's IP, not the original sender. The original IP is at the bottom.
Mailing lists: They often modify headers, causing SPF/DKIM failures. DMARC may still pass if alignment is relaxed.
Bounce messages: The Return-Path may be empty or contain a different domain.
Internationalized email addresses: They may contain non-ASCII characters that are encoded.
How to Eliminate Wrong Answers
If the question asks 'What is the most likely indicator of phishing?' look for a mismatch between From and Return-Path, or a failed DMARC check.
If the question provides a header snippet, focus on the Authentication-Results header for the verdict.
Remember that SPF and DKIM alone are not sufficient; DMARC alignment with the From domain is key.
When tracing the path, start from the bottommost Received header to find the originating IP.
Email headers contain metadata; the Received chain traces the server-to-server path from bottom (origin) to top (destination).
The From header can be spoofed; the Return-Path (envelope sender) is used for SPF checks and bounces.
SPF verifies that the sending IP is authorized for the envelope domain; DKIM provides digital signature for integrity; DMARC aligns the From domain with SPF/DKIM results.
Common phishing indicators: mismatched From and Return-Path, failed SPF/DKIM/DMARC, suspicious originating IPs, and unusual Message-ID patterns.
DMARC policy values: none (monitor), quarantine (spam folder), reject (block delivery).
When analyzing headers, always check the Authentication-Results header for the verdicts.
A single authentication pass (e.g., SPF pass) does not guarantee legitimacy; all three (SPF, DKIM, DMARC) should be considered with alignment.
Tools like MXToolbox and Google Admin Toolbox can parse headers automatically.
Command-line tools: `postcat` for Postfix, `mail` command, or Python's `email` library.
Edge cases: forwarding may break SPF; mailing lists may modify headers causing DKIM failures.
These come up on the exam all the time. Here's how to tell them apart.
SPF (Sender Policy Framework)
Checks envelope sender domain (Return-Path).
Uses DNS TXT records to list authorized IPs.
Verifies the sending server's IP is allowed.
Does not provide integrity protection for the email body.
Vulnerable to forwarding: SPF may fail when email is forwarded.
DKIM (DomainKeys Identified Mail)
Signs the email with a private key, verified via public key in DNS.
Uses a selector to locate the public key.
Provides integrity: detects tampering with signed headers and body.
Does not check the sender's IP; only the signature.
Survives forwarding if the signature is preserved (but may break if headers are modified).
Mistake
The From header is always the true sender.
Correct
The From header can be easily forged. The true sender is determined by the Return-Path (envelope sender) and the IP addresses in the Received chain. SPF checks the Return-Path domain, not the From header.
Mistake
If SPF passes, the email is legitimate.
Correct
SPF only verifies that the sending server is authorized to send mail for the envelope domain. The From header may be a different domain. DMARC alignment checks that the From domain matches the SPF-authenticated domain.
Mistake
A DKIM signature guarantees the email is authentic.
Correct
DKIM ensures the email hasn't been tampered with and comes from a server with the private key. However, the signing domain may be different from the From domain. DMARC alignment is needed to link the signature to the From domain.
Mistake
Multiple Received headers always indicate malicious routing.
Correct
Multiple hops are common for legitimate emails (e.g., through mailing lists, forwarding, or security gateways). The specific IPs and the chain's consistency matter more than the count.
Mistake
DMARC fail means the email is definitely malicious.
Correct
DMARC fail can occur for legitimate emails if the domain's policy is misconfigured or if the email was forwarded (which may break SPF). However, combined with other indicators, it strongly suggests phishing.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Open the email, click the three vertical dots (More) in the top right, and select 'Show original'. A new tab opens with the full headers and raw message. You can also download the .eml file. The headers appear at the top, with the body after a blank line. Look for 'Received', 'Authentication-Results', 'DKIM-Signature', and 'Return-Path'.
The 'From' header is displayed to the user and can be easily forged. The 'Return-Path' is set by the sending mail server (the envelope sender) and is used for bounces. SPF checks the domain in the Return-Path. In phishing, the From may be a trusted domain while the Return-Path is a malicious domain.
Start at the bottommost 'Received' header (the first hop) and read upward to the topmost (the last hop). Each Received header shows the IP and hostname of the server that sent the email to the next server. Write down the IPs in order to see the route. If the originating IP is unexpected (e.g., from a country known for spam), it's suspicious.
SPF fail means the sending server's IP is not authorized by the domain's SPF record to send email on behalf of that domain. This is a strong indicator of spoofing. However, some legitimate emails may fail if the domain's SPF record is misconfigured or incomplete.
DMARC alignment checks that the domain in the From header matches the domain authenticated by SPF or DKIM. In strict alignment, the domains must be identical. In relaxed alignment, the organizational domain (e.g., example.com) must match. If alignment fails, DMARC policy is applied.
Yes. An attacker can use a compromised domain with valid SPF/DKIM records, or use a domain they control. However, DMARC may still fail if the From domain doesn't align. Also, the user sees the From header, which can be different from the authenticated domain.
The Message-ID is a unique identifier generated by the sending mail server. It can be used to correlate emails in logs. Phishing emails often have randomly generated Message-IDs that don't follow the pattern of the claimed domain. It's not a definitive indicator but can be part of the analysis.
You've just covered Email Header Analysis for Phishing — now see how well it sticks with free CS0-003 practice questions. Full explanations included, no account needed.
Done with this chapter?