/analyzing-phishing-emails

name: analyzing-phishing-emails
description: Triage and forensically analyze reported phishing safely — extract the raw message, read the Received chain, verify SPF/DKIM/DMARC, detect display-name and lookalike spoofing, unwrap redirects and SafeLinks/URLDefense, decode quishing QR codes, triage attachments, and pull IOCs for hunting. Use when handed a reported phishing email, a suspicious .eml or .msg file, a set of email headers to analyze, a malicious attachment or link to triage, or a business email compromise or spoofing case.
verified: 2026-07-26

Analyzing Phishing Emails

An email is a stack of claims — who sent it, where it came from, that its links are safe — and phishing analysis is checking each claim against evidence the sender could not forge: the Received chain, the authentication results, and the true destination of every link and attachment. The From header is a display, not a fact. Anyone can type any address into it; your job is to find the evidence that agrees or disagrees.

When to Use

• A user reports a suspicious email and you need a verdict and IOCs
• You have a `.eml` or `.msg` file to analyze offline
• You are handed raw headers and asked whether a message is spoofed
• A message carries a link or attachment that needs safe triage
• A business email compromise, invoice-fraud, or vendor-impersonation case
• Confirming whether a domain or brand was spoofed against your users

When NOT to Use

• **You extracted an attachment and need to detonate it** — come here first to

safely extract and defang it, then hand the payload to `analyzing-malware`

• **The phish already succeeded and you are chasing the mailbox/OAuth

compromise in the tenant** — use `investigating-m365-entra`

• **You are building the phishing campaign, not analyzing one** — use

`performing-social-engineering`

• **The broader incident the phish kicked off** — use `responding-to-incidents`
• **Analyzing the callback traffic from a detonated payload** — use

`analyzing-network-traffic`

Safe Handling — Do This First

Treat every reported message as live. The failure mode is not misreading a header; it is clicking a link in a production mail client or double-clicking an attachment on your own host.

• Never open the message in a live client. Attacker-controlled remote images

fire a read beacon; one click on a link authenticates you to their harvester.

• Work from the raw source only — the `.eml`/`.msg`, not a forwarded copy.

Forwarding rewrites headers and strips the evidence you need.

• Defang every indicator before it touches a report, ticket, or chat:

`http` → `hxxp`, `.` → `[.]`, `@` → `[at]`. So `http://evil.com/login` becomes `hxxp://evil[.]com/login`. Defanging prevents an accidental click downstream and stops link-preview bots from detonating it for you.

• Extract and detonate only in an isolated VM with no host sharing and

simulated or monitored egress — see `analyzing-malware` for the build.

Getting the Raw Message

The visible email is a rendering. You need the source with all headers.

• **Outlook/Exchange**: save as `.msg`, or in OWA use "View message source".
• **Gmail**: "Show original" → Download Original gives a `.eml`.
• **`.msg` → readable**: `msgconvert sample.msg` produces a `.eml` (RFC822).
• **Inspect structure**: `emldump.py sample.eml` lists MIME parts and indices;

`emldump.py -s 4 -d sample.eml` dumps part 4 (an attachment) without opening it. A `.msg` is an OLE compound file — `oledump.py` (DidierStevens) lists its streams.

• **View full headers**: read the top block of the raw file directly, or paste

into Message Header Analyzer (MHA) / Google's `mha` / MXToolbox Header Analyzer for a parsed hop table.

Keep the original file hashed and untouched; work on copies.

The Received Chain

The `Received:` headers are added by each mail server the message passes through, newest at the top. Read them **bottom-up**: the bottom-most `Received` is the originating server — the earliest, least-forgeable hop.

Received: from mail.contoso.com (mail.contoso.com [203.0.113.9])
    by mx.recipient.com ... ; Tue, 21 Jul 2026 09:14:02 +0000   <- final hop
Received: from smtp.sketchy-vps.ru ([185.220.101.5])
    by mail.contoso.com ...   ; Tue, 21 Jul 2026 09:13:58 +0000  <- origin

• **Trace the originating IP**: the bottom hop's `[bracketed IP]`. Geolocate

and WHOIS it (`whois 185.220.101.5`), check reputation, and reconcile it against the claimed sender. A "From: ceo@contoso.com" that originates on a Russian VPS is your finding.

• **Spot forged hops**: attackers prepend fake `Received` lines to fabricate a

reputable origin. Only hops added by servers you trust are reliable — trust breaks at the first server outside your control. A hop that references a server not present in the next hop's `by` is invented.

• **Timezone and hop-time anomalies**: hop timestamps should increase upward by

seconds. Negative deltas, multi-hour jumps, or a mix of implausible timezones indicate forgery or relay through odd infrastructure.

• **Reconcile with the claimed sender**: the origin domain, its PTR/rDNS, and

the `From` domain should tell one coherent story. They usually do not in a phish.

Authentication Results

SPF, DKIM, and DMARC are the forgery-resistant checks. The receiving server records them in `Authentication-Results`. Read it, and re-verify rather than trusting a summary.

Authentication-Results: mx.recipient.com;
  spf=pass (sender IP is 185.220.101.5) smtp.mailfrom=bounce.sketchy-vps.ru;
  dkim=pass header.d=sketchy-vps.ru header.s=selector1;
  dmarc=fail (p=reject sp=reject dis=none) header.from=contoso.com

• **SPF** authenticates the *envelope* sender (`Return-Path` / `smtp.mailfrom`

/ `MAIL FROM`), **not** the visible `From`. Values: `pass` (IP is authorized for the envelope domain), `fail` (hard `-all` reject), `softfail` (`~all`, suspicious but delivered), `neutral`/`none` (no policy). Check the