Phishing triage: a step-by-step playbook for reported emails

Phishing triage is the routine a small team follows when a user reports a suspicious email: collect the original message, check who really sent it, inspect links and attachments safely, find everyone else who received it, and act on what you learn. Doing it the same way every time makes it fast, defensible and easy to hand over between analysts.

Why a repeatable phishing triage process matters

User-reported email is one of the most valuable detection sources a small team has. Filters miss messages, and the person who spots one is often the first to see an attack that is still spreading. If every report is handled differently, some get a quick reply and others sit in a mailbox for days, and users learn that reporting does not change anything.

A written playbook turns each report into the same short sequence of decisions. It also gives you a record of what was checked and why, which helps when a manager, an auditor or an incident responder asks later. The technique itself is well catalogued: MITRE ATT&CK describes phishing as technique T1566, covering malicious attachments, links and messages sent through services.

Step 1: Collect the original message, not a screenshot

A screenshot shows what the email looked like, but it hides almost everything you need. Ask users to report through a report button or to forward the message as an attachment, so the original file with its full headers arrives intact. Forwarding as plain text rewrites parts of the message and can strip the evidence.

The full headers record the path the message took between servers, the real sending address, the reply-to address and the authentication results that the receiving server recorded. Keep the original message as a file in a case folder or ticket, because the mailbox copy may be deleted in the cleanup step later.

Save the raw message (for example an .eml file) with its attachments untouched.
Record who reported it, when it was received and which mailbox received it.
Note whether the user clicked, opened an attachment or replied. Ask this early and without blame.

Step 2: Check sender authentication results

Three standards help receiving servers judge whether a message really came from the domain it claims. SPF checks whether the sending server is allowed to send for a domain. DKIM checks a cryptographic signature that is attached to the message. DMARC ties the two to the visible From address and tells receivers what to do when checks fail.

Read the authentication results in the headers and compare the domains involved. A message can pass SPF and DKIM for an unrelated domain while the visible From address belongs to a brand it is imitating, so alignment matters as much as the pass or fail result. Passing authentication does not make a message safe either, since attackers can send from domains they control or from accounts they have already compromised.

Compare the From address, the Reply-To address and the return path.
Look for lookalike domains: swapped letters, extra words or a different top-level domain.
Treat a failed check as a signal to investigate further, not as proof on its own.

Step 3: Inspect links and attachments safely

Never open a suspicious link or file on a normal work machine. Use an isolated analysis environment, a sandbox service or a dedicated virtual machine that has no access to your corporate network or credentials.

For links, read the destination without visiting it where you can. Hover or expand the URL, check for redirects and URL shorteners, and compare the real host with the one the text displays. Look up the domain in your threat intelligence tools and check whether it is newly registered. For attachments, look at the file type and whether it is an archive, an Office document asking to enable macros, a disk image or a script. Calculate the file hash and search it in reputation services before deciding on a detonation.

Common patterns worth recognising include fake sign-in pages that harvest passwords, messages that push the reader to approve a multi-factor prompt, and requests that impersonate an executive or a supplier to redirect a payment. The UK National Cyber Security Centre explains how to spot and report these in its phishing guidance, which is also useful material for user awareness.

Step 4: Find other recipients and remove the message

One report usually means more recipients. Use your mail platform’s message trace or search tools to look for the same sender, subject, attachment hash or link across all mailboxes. Searching on more than one attribute catches variants where the attacker changed the subject line but kept the same infrastructure.

Once you have confirmed the message is malicious, remove it from the mailboxes where it landed and block the sender, domain and any malicious URLs at the mail gateway and web proxy. Before deleting, export the matches so the evidence is preserved and you know exactly who received it.

List every recipient and mark who opened, clicked or replied.
Check web proxy, DNS and endpoint logs for visits to the malicious link.
Check sign-in logs for the targeted accounts for unfamiliar locations, new devices or new mailbox rules.

Step 5: Respond when someone clicked

If a user entered credentials or opened a malicious file, treat the account and possibly the device as compromised until shown otherwise. Speed matters more than certainty here.

Reset the password and revoke active sessions and tokens for the account.
Review multi-factor registrations and remove any method the user does not recognise.
Look for inbox rules that forward or hide mail, delegated access and newly granted application permissions.
Isolate and scan the endpoint if an attachment was opened, and escalate to your incident response process if anything suspicious is found.

Phishing is also a common first step for ransomware intrusions, which is one reason CISA’s ransomware guide lists phishing defences among its prevention advice. Keep your triage notes ready to hand over if a report turns into a wider incident.

Step 6: Feed findings back into filtering and user feedback

Each triaged email should improve your defences. Add confirmed malicious senders, domains and URLs to blocklists, tune mail filtering rules for the pattern you saw, and consider tightening policy on external senders that impersonate internal names. If a lookalike of your own domain was used, review your own SPF, DKIM and DMARC configuration.

Close the loop with the person who reported it. A short reply that says whether the message was malicious, what you did and what to look for next time keeps users reporting. Share sanitised examples with staff without naming the person who clicked. Count reports, time to first response and time to removal so you can see whether the process is getting faster.

Keeping the process sustainable for a small team

Small teams do not need a large toolset to do this well. A shared mailbox or report button, a ticket template with the steps above, a safe place to detonate files and a documented way to search all mailboxes cover most of the need. Write down who decides to remove a message from every mailbox, and agree in advance what counts as an emergency so analysts are not waiting for approval while a campaign spreads.

Triage is also a good place to apply risk-based thinking. If a reported email carries a link to a vulnerable service or an exploit, the same prioritisation logic you use for patching applies: see our explainer on patch prioritization with CVSS, EPSS and KEV for how to weigh severity against likelihood of exploitation.

What defenders can do

Give users a one-click way to report suspicious email, and make sure reports arrive as original messages with full headers.
Write a short playbook with the steps in this article and keep it where every analyst can find it.
Set up a safe analysis environment for links and attachments that is separated from the corporate network.
Learn to read SPF, DKIM and DMARC results and check domain alignment, while remembering that a pass is not a verdict.
Make sure you can search and remove a message across all mailboxes quickly, and export evidence before you delete.
When a user clicked, reset credentials, revoke sessions, check multi-factor methods and mailbox rules, and scan the device.
Turn every confirmed case into blocklist entries, filter changes and a short note back to the reporter.
Review your own domain’s email authentication so attackers find it harder to impersonate you.

Explainers on Cyber Strike News

What is CVSS? – how severity scores are built and what they miss
What is EPSS? – the probability a flaw will be exploited soon
What is the CISA KEV catalog? – vulnerabilities known to be exploited in the wild
What is a CVE? – how vulnerabilities are identified and numbered

Sources

Spotted an error or outdated detail? Email contact@cyberstrikenews.com with the article link. We correct and note every change. Read our Editorial Policy.