A phishing email lands in an inbox, someone reports it, and now what? For most people, "investigating" a suspicious email means glancing at the sender's name and deciding whether it feels right. For a security team or an incident responder, that's nowhere near enough. A proper phishing investigation follows a repeatable process — one that turns a gut feeling into evidence you can act on, document, and if necessary, hand off to law enforcement or legal counsel.
This guide walks through that process from start to finish: what to check first, how to safely examine the parts of an email that actually matter, and where dedicated tooling earns its keep once a single suspicious message turns into dozens or hundreds.
Step 1: Preserve the Evidence Before You Touch Anything
The first instinct when a phishing email is reported is often to open it, click around, and see what's inside. Resist that. The moment an investigation starts, the email itself becomes evidence, and evidence needs to be preserved in its original state before any analysis begins.
In practice, this means exporting the full email — including headers — rather than just reading it in a webmail client. Most providers let you download the raw message as an .eml or .msg file, which captures the complete header trail, not just the friendly "From" name displayed on screen. Losing the headers at this stage means losing the single most useful piece of evidence in the whole investigation.
If the email arrived in a corporate environment, it's also worth checking whether other employees received the same or a similar message. A phishing attempt rarely targets just one person; understanding the blast radius early shapes how urgently the rest of the investigation needs to move.
Step 2: Read the Headers, Not Just the Message
The visible parts of an email — subject line, sender name, body text — are the easiest things for an attacker to fake. The headers are harder to spoof convincingly, which is exactly why they're where a real investigation starts.
Trace the "Received" chain. Each mail server that handled the message adds a "Received" header, building a chronological path from sender to recipient. Reading this chain from bottom to top shows the actual route the email traveled — and whether that route makes sense given who it claims to be from.
Check SPF, DKIM, and DMARC results. These three authentication mechanisms exist specifically to verify that a message actually came from the domain it claims to. A failed SPF or DKIM check doesn't automatically prove malicious intent — legitimate misconfigurations happen — but a failure combined with a suspicious "Received" chain is a strong signal worth escalating.
Compare the Reply-To address against the From address. A common phishing tactic is to display a trusted sender name while quietly routing replies to an entirely different address. This mismatch is invisible in most inbox views but sits plainly in the header.
Look at the originating IP address. Once you've identified the server that first introduced the message into the mail system, that IP can be checked against threat intelligence databases and geolocated. An email that claims to be from your company's finance department but originated from an IP in an unexpected region deserves a much closer look.
Step 3: Examine Links Without Clicking Them
Links are the most common phishing payload, and they're also the easiest part of an investigation to get wrong by testing them the obvious way — clicking.
Instead, extract the underlying URL from the link text (most email clients show this on hover, or it can be pulled directly from the raw HTML) and inspect it in an isolated environment: a sandboxed browser, a virtual machine with no connection to production systems, or a dedicated URL analysis tool. Pay attention to a few things:
- The actual domain, not the subdomain or path dressed up to look legitimate. accounts.microsoft.com.secure-login.net is not a Microsoft domain — the real domain is secure-login.net, with everything before it just window dressing.
- URL shorteners, which hide the destination entirely until expanded through a safe unshortening tool.
- Redirect chains. Some phishing links pass through several intermediate redirects before landing on the actual credential-harvesting page, specifically to evade simple filtering.
Step 4: Handle Attachments With Extreme Caution
If the email includes an attachment, that file needs to be treated as a live threat until proven otherwise. Never open a suspicious attachment on a standard work machine, even "just to look."
A proper attachment analysis usually happens in an isolated sandbox environment where the file can be detonated safely and its behavior observed — what it tries to connect to, what it tries to write to disk, whether it attempts to escalate privileges. At minimum, hashing the file and checking that hash against known-malware databases is a fast first check that requires no execution at all.
Pay particular attention to file types that shouldn't normally be sent as business documents: executables, script files, and macro-enabled Office documents are disproportionately represented in phishing campaigns, precisely because they can run code the moment someone opens them.
Step 5: Document Everything as You Go
An investigation that lives only in someone's memory isn't much use to anyone else, and it's certainly not usable as evidence. Every finding — the header analysis, the domain checks, the sandbox results — should be captured as you go, not reconstructed afterward from memory.
Good documentation includes timestamps, the exact indicators found (IP addresses, domains, file hashes), and a plain-language summary of what happened and why it matters. This matters twice over: it lets other analysts pick up the investigation without starting from scratch, and it creates a record that holds up if the incident escalates to a legal or regulatory matter.
When One Email Becomes a Hundred
Everything above works well for a single reported email. It breaks down fast when a phishing campaign hits an entire organization at once and a hundred near-identical reports land in the security team's queue within an hour.
At that scale, manually repeating headers checks, link extraction, and attachment analysis for each message isn't realistic. This is where purpose-built email forensics software becomes less of a nice-to-have and more of an operational requirement. Rather than an analyst working through each email by hand, these tools can ingest bulk evidence across dozens of mail providers, automatically flag suspicious sending infrastructure and malicious URLs, cluster related messages from the same campaign, and generate structured reports that document findings consistently across the entire batch.
That consistency is the real advantage. A tired analyst on report ninety-seven doesn't scrutinize headers with the same care they gave report three. Automated tooling doesn't have that problem, and it produces a paper trail that's uniform from the first message to the last — which matters enormously if the investigation later needs to demonstrate exactly how a campaign was identified and contained.
Building a Repeatable Process
The goal of any phishing investigation isn't just to determine whether one email is malicious — it's to build a process reliable enough that the answer doesn't depend on who happens to be looking at it that day. Preserve evidence first, work through headers before anything else, treat links and attachments as hostile until proven otherwise, and document as you go rather than after the fact.
For individual reports, that manual discipline is enough. For anything approaching campaign scale, pairing that same discipline with dedicated forensic tooling is what keeps an investigation from collapsing under its own volume — and what turns a pile of suspicious emails into a clear, defensible account of what actually happened.
Tags : .....
