Phishing Analysis: From Raw Email to Verdict
Read the headers before the body
Phishing triage rewards a fixed order of operations. Start with the full headers: the From display name is cosmetic, so compare the From: header domain against the Return-Path (envelope sender), the Reply-To, and the domain in the Message-ID. A mismatch between From and Return-Path is a strong signal, but legitimate bulk senders also do this, so treat it as a lead, not a verdict. Next read the Received chain bottom-to-top: the bottom-most Received is the originating server. Check whether the topmost hop matches your own mail gateway and whether the public sending IP matches the claimed domain. Then evaluate authentication: SPF checks the envelope sender IP, DKIM validates a cryptographic signature over specified headers and body, and DMARC ties the visible From domain to SPF/DKIM alignment and tells you what to do on failure (p=none only monitors).
URLs and attachments
Defang and inspect every link: compare anchor text to the real href, check for punycode/homoglyphs, and look at the registered domain rather than subdomains (login.microsoft.com.evil.tld belongs to evil.tld). For attachments, note the file type from the actual extension and magic bytes, not the icon, and be wary of double extensions, password-protected archives, and .htm/.html smuggling. Extract hashes and URLs as IOCs.
Traps and a rule of thumb
Common traps: calling a message malicious purely because SPF failed (forwarding breaks SPF); ignoring that DKIM survives forwarding better than SPF; confusing Reply-To with Return-Path; and treating a display-name spoof as domain spoofing. Rule of thumb: a verdict needs at least two independent corroborating signals (e.g., failed DMARC alignment plus a newly registered lookalike domain in a link), and every IOC you cite should be reproducible from the evidence.