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

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, 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 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 <analyst@recipient-org.example>
        (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 <analyst@recipient-org.example>;
        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 <analyst@recipient-org.example>;
        Thu, 10 Apr 2026 08:14:22 +0000 (UTC)

Return-Path: <bounces@attacker-smtp.example>
From: "IT Security Team" <security@legitimate-company.example>
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), defined in RFC 7208, 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:

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), defined in RFC 6376, applies a cryptographic signature to selected message headers and the body. The signing domain publishes its public key at <selector>._domainkey.<domain> 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), defined in RFC 7489, 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), defined in RFC 8617, 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 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" <random1847@domain.example>. 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 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 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:

1<a href="https://credential-harvest.example/login">https://payroll.yourcompany.com</a>

The 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) 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 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 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:

1dfir-cli phishing analyze suspicious.eml

Or via the API, which integrates cleanly into SOAR playbooks and automated triage pipelines:

1curl -X POST https://api.dfir-lab.ch/v1/phishing/analyze \
2  -H "Authorization: Bearer YOUR_API_KEY" \
3  -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 — no account required to start.