Knowing how to analyze phishing emails is a core competency for anyone working in a SOC or incident response role. A phishing email rarely looks suspicious at a glance — the danger is in what you cannot see: the delivery path, authentication failures, and mismatches buried in the raw headers. This guide walks through every step of a structured [email header analysis](/wiki/email-header-analysis), from reading `Received` chains to verifying SPF, DKIM, and DMARC, detecting spoofing indicators, and scaling the process with automation. --- ## Understanding Email Headers Email headers are defined in [RFC 5322](https://datatracker.ietf.org/doc/html/rfc5322) and contain structured metadata that travels with every message. Unlike the visible `From` name and subject line a recipient sees, headers record the technical truth of how a message was constructed and routed. Key header fields include: - **From / To / Cc / Bcc** — addressing fields, which can be freely forged by a sender - **Subject / Date / Message-ID** — message metadata - **Received** — added by each Mail Transfer Agent (MTA) that handled the message - **Return-Path** — the envelope sender address used by SMTP (distinct from the `From` header) - **Authentication-Results** — SPF, DKIM, and DMARC verdicts recorded by the receiving MTA - **DKIM-Signature** — the cryptographic signature attached by the signing domain - **ARC-* headers** — Authentication Results Chain headers used in forwarding scenarios Most email clients hide this data behind a "View Source" or "Show Original" option. In Gmail, click the three-dot menu → "Show original". In Outlook, open the message → File → Properties → Internet headers. Once you have the raw text, analysis begins. --- ## Step 1: Trace the Delivery Path ### Reading Received Headers Each MTA that handles a message prepends a `Received` header. Because each hop prepends rather than appends, the headers are in reverse chronological order: **the topmost `Received` header is the most recent hop** (typically your own mail server), and the bottommost is the origin. Reading top-to-bottom shows newest hop first; to reconstruct the delivery path chronologically, read bottom-to-top. Here is an example header set from a real phishing simulation: ``` Received: from mail.recipient-org.example (mail.recipient-org.example [198.51.100.42]) by mx.recipient-org.example with ESMTPS id x7si123456abc for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384); Thu, 10 Apr 2026 08:14:33 +0000 (UTC) Received: from suspicious-relay.example (unknown [203.0.113.88]) by mail.forwarding-service.example with ESMTP id a9bc4321xyz for ; Thu, 10 Apr 2026 08:14:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by attacker-smtp.example (Postfix) with ESMTP id 1A2B3C4D5E for ; Thu, 10 Apr 2026 08:14:22 +0000 (UTC) Return-Path: From: "IT Security Team" Reply-To: attacker@gmail.com Authentication-Results: mx.recipient-org.example; spf=fail (domain of attacker-smtp.example does not designate 203.0.113.88 as permitted sender) smtp.mailfrom=bounces@attacker-smtp.example; dkim=fail header.i=@legitimate-company.example; dmarc=fail (p=reject) header.from=legitimate-company.example ``` Reading the `Received` chain bottom-to-top: the message originated from `attacker-smtp.example` running on `localhost`, passed through `suspicious-relay.example` at `203.0.113.88`, and arrived at the recipient's MX. The IP `203.0.113.88` is worth pivoting on — run it through threat intelligence feeds and check whether it belongs to a known bulletproof hosting provider or has prior abuse reports. ### What to Check - **Timestamp consistency**: Each hop should be slightly later than the previous. Timestamps that go backwards or have unexplained gaps suggest header injection or manipulation. - **IP/hostname consistency**: The connecting IP in a `Received` header should resolve to the hostname claimed via PTR record. Mismatches are a red flag. - **Unexpected relay hops**: Legitimate corporate email typically flows through a small number of known mail servers. A sudden relay through a residential ISP or unfamiliar cloud region warrants investigation. --- ## Step 2: Check Authentication ### SPF [SPF (Sender Policy Framework)](/wiki/spf), defined in [RFC 7208](https://datatracker.ietf.org/doc/html/rfc7208), lets a domain declare which IP addresses are authorized to send mail on its behalf using a DNS TXT record. The check is performed against the **envelope sender** (the `MAIL FROM` SMTP command, reflected in the `Return-Path` header) — not the visible `From` header. SPF qualifiers: | Result | Qualifier | Meaning | |---|---|---| | Pass | `+` | IP is authorized | | Fail | `-` | IP is not authorized; reject | | SoftFail | `~` | IP is probably not authorized; accept but mark | | Neutral | `?` | No assertion made | | None | — | No SPF record found | | PermError | — | SPF record is invalid (e.g., exceeds 10 DNS lookup limit) | | TempError | — | Transient DNS failure during lookup | The **10 DNS lookup limit** is a critical operational constraint. SPF evaluation may trigger a chain of lookups via `include:`, `a`, `mx`, and `redirect` mechanisms. Exceeding 10 lookups results in a `PermError`, which many receivers treat as a fail. Attackers sometimes craft records to deliberately trigger this as an evasion technique. SPF alone is not sufficient: it only validates the envelope sender, which is invisible to the end user. An attacker can pass SPF on their own domain while displaying a completely different `From` address. ### DKIM [DKIM (DomainKeys Identified Mail)](/wiki/dkim), defined in [RFC 6376](https://datatracker.ietf.org/doc/html/rfc6376), applies a cryptographic signature to selected message headers and the body. The signing domain publishes its public key at `._domainkey.` as a DNS TXT record. The receiving MTA fetches this key and verifies the `DKIM-Signature` header. Key fields in a DKIM signature: - `d=` — the signing domain - `s=` — the selector, used to locate the public key in DNS - `h=` — the list of signed headers - `bh=` — the hash of the message body - `b=` — the actual cryptographic signature A `dkim=pass` result means the message content (for signed headers) has not been tampered with in transit, and the signing domain controls the key. However, note that DKIM signing domain (`d=`) does not have to match the visible `From` domain unless DMARC alignment is enforced. ### DMARC [DMARC (Domain-based Message Authentication, Reporting and Conformance)](/wiki/dmarc), defined in [RFC 7489](https://datatracker.ietf.org/doc/html/rfc7489), ties SPF and DKIM together and adds **alignment**: the authenticated domain must match the `From` header domain. DMARC passes if at least one of the following is true: - SPF passes **and** the `Return-Path` domain aligns with the `From` domain - DKIM passes **and** the `d=` signing domain aligns with the `From` domain Alignment can be **relaxed** (organizational domain match, e.g., `mail.example.com` aligns with `example.com`) or **strict** (exact domain match only). DMARC policies: - `p=none` — monitor only; no action taken - `p=quarantine` — route to spam/junk - `p=reject` — refuse delivery outright In the header example above, `dmarc=fail (p=reject)` means the receiving server should have rejected the message. If it still arrived, the receiving domain may not be enforcing DMARC policy, or the message was handled by a gateway that strips verdicts. ### ARC [ARC (Authenticated Received Chain)](/wiki/arc-authentication), defined in [RFC 8617](https://datatracker.ietf.org/doc/html/rfc8617), addresses a specific problem: forwarded messages (mailing lists, email forwarding rules) legitimately break SPF and sometimes DKIM. ARC preserves the original authentication results at each hop using a chain of three headers: `ARC-Seal`, `ARC-Message-Signature`, and `ARC-Authentication-Results`. Receiving servers can use a validated ARC chain to make trust decisions even when SPF/DKIM fail due to forwarding. From an analysis perspective: if a message shows `spf=fail` and `dkim=fail` but has a valid ARC chain from a trusted intermediary (e.g., a major mailing list provider), it may be legitimate. Conversely, an ARC chain from an untrusted or unknown intermediary provides no assurance. --- ## Step 3: Detect Spoofing Indicators ### From / Reply-To Mismatch The `From` header controls what a mail client displays as the sender. The `Reply-To` header, if present, redirects any reply to a different address. In the example above, `From` shows `security@legitimate-company.example` while `Reply-To` is `attacker@gmail.com`. A user who hits reply sends their response directly to the attacker without realizing it. This is one of the clearest [email spoofing](/wiki/email-spoofing) indicators and one of the easiest to miss in a busy inbox. ### Display Name Tricks Even without touching the email address, attackers set the display name to something trusted: `"PayPal Security" `. Many mobile clients and simplified mail apps show only the display name, hiding the actual address entirely. Always inspect the raw address, not just the display name. ### Homoglyph Domains [Homoglyph attacks](/wiki/homoglyph-domains) substitute visually identical or similar Unicode characters for ASCII letters: `pаypal.com` (with a Cyrillic `а`) looks identical to `paypal.com` at a glance. Unicode Technical Standard [UTS #39](https://unicode.org/reports/tr39/) defines a confusable character set and recommends detection mechanisms for this class of attack. Detection steps: 1. Extract the domain from the `From` address 2. Convert to punycode (ACE form) using `idn2` or equivalent — a homoglyph domain will reveal a non-ASCII encoding 3. Compare the punycode representation to legitimate domains 4. Check WHOIS for recent registration dates — homoglyph domains are typically registered days before a campaign --- ## Step 4: Analyze URLs and Attachments ### Link-Display Mismatch Phishing emails routinely show a trustworthy URL as anchor text while the actual `href` points elsewhere. For example: ```html https://payroll.yourcompany.com ``` The [link-display mismatch](/wiki/link-display-mismatch) is invisible in rendered HTML. Always extract URLs from raw source or use a tool that parses both the display text and the actual destination. Expand shortened URLs (bit.ly, t.co, etc.) and trace redirect chains fully before categorizing — intermediate hops often pass through legitimate services to evade URL reputation filters. ### QR Code Phishing [QR code phishing (quishing)](/wiki/qr-phishing) embeds a malicious URL inside a QR code image rather than a clickable link. This bypasses URL-scanning at the email gateway layer entirely, since the gateway sees only an image attachment. The embedded URL is only decoded when a user scans with their phone — which is typically off the corporate network and outside EDR visibility. Mitigation: extract QR code content using a decoder (e.g., `zbar`, `pyzbar`) as part of your attachment analysis pipeline, then submit the extracted URL to your standard URL analysis workflow. ### Attachment Analysis For attachments, record the file hash (SHA-256), MIME type, and extension. Extension/MIME type mismatches are common: a file presented as `invoice.pdf` that is actually a `.html` file with credential harvesting content. Submit to a sandboxing environment for dynamic analysis before opening. --- ## Step 5: Automate Your Analysis Manual header analysis is thorough but does not scale. A single [phishing analysis](/wiki/phishing-analysis) across From/Reply-To/Return-Path alignment, full SPF/DKIM/DMARC evaluation, timestamp consistency, IP reputation, URL extraction, QR code decoding, and attachment triage can take 20-30 minutes per sample. SOC teams processing dozens of reported phishing emails per day need automation. ### DFIR Lab Phishing Checker The **Phishing Email Checker** at [platform.dfir-lab.ch](https://platform.dfir-lab.ch) accepts raw `.eml` files or pasted RFC 5322 headers and runs 26+ analysis modules automatically — covering the full chain from delivery path reconstruction through authentication verification, spoofing detection, URL extraction, and QR code scanning. From the CLI: ```bash dfir-cli phishing analyze suspicious.eml ``` Or via the API, which integrates cleanly into SOAR playbooks and automated triage pipelines: ```bash curl -X POST https://api.dfir-lab.ch/v1/phishing/analyze \ -H "Authorization: Bearer YOUR_API_KEY" \ -F "file=@suspicious.eml" ``` The API returns structured JSON covering authentication verdicts, extracted IOCs, detected spoofing patterns, and a composite risk score — making it straightforward to build automated escalation rules based on thresholds. The free tier includes 100 credits/month. Use code **LAUNCH50** for 50% off a paid plan. --- ## Conclusion Effective phishing email analysis is methodical, not intuitive. The delivery path tells you where a message actually came from. SPF, DKIM, and DMARC together tell you whether the sending infrastructure is authorized and whether the visible `From` domain has been spoofed. Spoofing indicators in the addressing headers reveal social engineering techniques that authentication alone won't catch. URL and attachment analysis closes the loop on the payload. At scale, this process must be automated. No SOC can sustain manual triage at volume without burning out analysts or letting samples slip through. **Ready to run your first analysis?** Upload a suspicious `.eml` file or paste raw headers at [dfir-lab.ch/phishing-check](https://dfir-lab.ch/phishing-check) — no account required to start.

How to Analyze Phishing Email Headers: A Complete Guide for SOC Analysts

How to Analyze Phishing Email Headers: A Complete Guide for SOC Analysts