How should users report suspected phishing emails?

A one-click "Report Phishing" button in the mail client, sending the original with headers to the SOC mailbox. Forwarding by hand strips the headers. Don't rely on it.

What tools are essential for phishing analysis?

Email header analyzer. URLScan.io for links, Any.Run or Joe Sandbox for files, VirusTotal and AbuseIPDB for reputation. A SOAR platform ties it together for automated phishing analysis, so the analyst reviews a verdict instead of pasting hashes between tabs.

How do we handle user credentials submitted to a phishing site?

Reset the password now and force MFA re-enrollment. Pull sign-ins since the submission time and look for unfamiliar IPs. Attackers who get into a mailbox often add a forwarding rule to read replies quietly, so check for one. Then call the user; an email from IT right after a phishing incident looks suspicious.

Should we respond to every reported phishing email?

Yes. Even a false alarm deserves a thank-you, because users who hear nothing stop reporting. Automate the first pass so volume doesn't swamp the team.

How do we track phishing campaign trends?

Log sender domains, payload types, who was targeted and what happened. Look at it monthly. You will see things single tickets hide, like the same invoice lure landing on finance every payroll week, and that tells you which email controls to tighten.

Phishing Analysis Playbook

Overview

A user forwards an email that "looks off". Usually it is spam or a clumsy marketing blast. Sometimes it is the first message of a campaign that landed in many other inboxes at the same moment, and nobody else reported it. Phishing is still how most intrusions start, so each report deserves a proper look. Below is the phishing email analysis routine we would hand a new SOC analyst: headers, links, attachments, IOC extraction, containment.

Analysis Workflow

Get the reported email as an attachment (.eml or .msg) so the headers survive, and keep an untouched copy
Read the headers bottom-up to find where the message really came from
Inspect URLs without clicking: expand shorteners, then load the page in a sandbox or URL scanner
Check sender domain and IPs against threat intelligence and blocklists
Detonate attachments in a sandbox, never on an analyst laptop
Extract IOCs: sender domains, IPs, URLs, file hashes, subject lines
Work out the goal. Credential harvesting, malware delivery, BEC and reconnaissance each need a different response
Search the mail platform for other recipients of the same or similar message; the reporter is rarely the only one
Contain: block domains, quarantine matching mail, reset credentials for anyone who entered a password
Document findings and close the ticket with the IOCs attached

Header Analysis Fields

Header field	What to check	Red flags
Return-Path	Where bounces go, which is the envelope sender used for the SPF check	Domain unrelated to the From address
Received	The chain of mail servers and the originating IP	Unknown relays, or a first hop on residential or cloud hosting space
Authentication-Results	SPF, DKIM and DMARC results recorded by your own gateway	Failures on a sender that claims to be a bank, supplier or internal team
X-Originating-IP	Client IP of the sender, when the platform adds it	Known malicious ranges, VPN exits or hosting providers
Reply-To	Where a reply will actually land	A different domain from From, a classic BEC setup
Message-ID	Identifier created by the sending system	Domain that does not match the sender; weak alone, since many mailing services set their own

URL and Link Analysis

Never click links directly. Copy the URL, defang it in your notes, and run it through URLScan, VirusTotal or your SOAR platform.

Spoofed domains come in a few shapes. Typosquats swap letters (rnicrosoft). Homoglyphs borrow lookalike characters from Cyrillic or Greek. Subdomain abuse puts the brand on the left of an attacker's domain, as in paypal.com.account-check.example. Then check domain age through WHOIS or RDAP: a domain registered last week that sends invoice reminders is close to a verdict by itself.

Expand shorteners first. Compare the link text with the real href. Follow the redirects to the end, since phishing kits like to bounce through a compromised WordPress site or an open redirector on a trusted domain, and some serve the credential page only to visitors from the target country while showing everyone else a blank page.

Attachment Analysis

Sandbox first. Nobody opens the attachment on a workstation, including the analyst
Hash it and check VirusTotal and your threat intelligence; zero detections means unknown, not clean
Metadata is worth a minute: an invoice from a Mumbai supplier authored by a user named "admin" in a tool the supplier does not use is a tell
Office documents: embedded macros, OLE objects, and external template references that fetch a payload when the file opens
PDFs: embedded JavaScript, launch actions, form fields that submit to an outside URL
Archives (ZIP, RAR, 7z): a password in the email body is there to blind the gateway scanner. Open it in the sandbox and look for nested payloads like an LNK or ISO

Containment and Response

When the verdict is malicious, act before writing anything up. In Microsoft 365 that means Threat Explorer or a content search; in Google Workspace, the security investigation tool. Search by sender, subject or a distinctive phrase from the body, because campaigns rotate subjects. Purge every copy. Then block the sender domain and the URLs at the gateway and web proxy.

Anyone who clicked or opened the attachment is a possible compromise until you show otherwise. Reset their credentials, scan the endpoint, and check for new inbox rules, OAuth app consents and sign-ins from places they have never logged in from. Push the IOCs to your threat intelligence platform so the campaign's next wave is blocked without anyone reporting it.