User-reported phishing is one of the most valuable threat intelligence signals your organization generates. When an employee flags a suspicious email and submits it for review, they're potentially giving your security team early warning of a campaign that hasn't reached blocklists yet, a targeted attack that bypassed automated detection, or an internal account compromise that's already in progress.
The problem is operational volume. A mid-market organization with 2,000 mailboxes can realistically generate 30–80 user-reported phishing submissions per week — and the majority of those are legitimate emails the reporter misidentified, newsletters, cold sales outreach, or last month's security awareness training simulation. Processing that queue manually, one by one, is a reliable path to analyst burnout and slow MTTR on the real threats buried in the noise.
This playbook is a practical triage framework for IT teams that don't have a dedicated SOC but need to handle user-reported phish professionally. It covers intake, automated pre-processing, human triage prioritization, disposition actions, and reporter feedback. The goal is to cut analyst time per ticket while improving detection fidelity on the cases that actually matter.
Step 1: Standardize the Reporting Mechanism
The first operational dependency is a consistent, low-friction way for employees to report. If reporting requires forwarding to a specific email address with a prescribed subject line format, many employees won't do it — or will do it inconsistently, making programmatic intake impossible.
The options are an Outlook add-in button (Microsoft's Report Phishing add-in, or a custom add-in that submits to your ticketing system), a Gmail equivalent for Workspace environments, or a dedicated report@[yourdomain] address with an auto-reply confirming receipt. The add-in approach is preferable because it preserves the original message headers as an attachment in .eml format, which is essential for later header analysis. A forwarded email loses the original DKIM signature and Received headers.
Whatever the mechanism, establish a clear auto-response: confirm receipt, set expectation for response time (24 hours for non-urgent reports is reasonable for a small IT team), and reassure the reporter that submitting reports even for uncertain cases is correct behavior. You want high reporting rates, even at the cost of more noise, because the alternative is real threats going unreported.
For M365 environments, the Microsoft Report Phishing add-in submits directly to Microsoft for their threat intelligence corpus and optionally to your custom inbox. If you're also running a supplemental inspection layer via Microsoft Graph API, you can configure your reporting add-in to submit to a shared mailbox that your inspection pipeline monitors for immediate triage processing.
Step 2: Automated Pre-Processing Before Human Eyes Touch It
The highest-value investment in triage efficiency is automated pre-processing that enriches each report before a human analyst opens it. Manual triage that starts from a raw forwarded email requires the analyst to do all the enrichment work themselves — every time, for every ticket. Automated pre-processing runs the same checks on every submission in seconds.
The automated checks that provide the most triage value:
- Sender domain age and registration date: WHOIS lookup for the sending domain. A domain registered within the past 30 days elevates the priority significantly. This is a single API call and takes under a second.
- SPF / DKIM / DMARC validation result from original headers: Parse the
Authentication-Resultsheader. Authentication failure (especially DMARC fail) on a message that your mail gateway passed through is a signal worth surfacing prominently. - URL extraction and reputation check: Extract all URLs from the reported email body and check each against VirusTotal, URLhaus, or your threat intelligence subscription. Known-bad URL = immediate escalation. Unknown URL with a fresh domain = flag for detonation.
- Attachment hash lookup: If there's an attachment, hash it and check against VirusTotal. Known-malicious hash = immediate escalation and check for other recipients in your environment who received the same attachment.
- Duplicate detection: Has this exact email (same Message-ID) already been reported? If yes, add it to the existing ticket rather than creating a new one. Ten reports of the same phishing email are one incident, not ten.
- Internal recipient cross-check: Has this message been delivered to other mailboxes in your organization beyond the reporter? Query your mail logs. If 40 employees received the same message and only 1 reported it, that's an active exposure requiring immediate action even if the email looks borderline.
The output of automated pre-processing should be a structured enrichment record attached to each ticket: sender domain age, auth results, URL verdict summary, attachment verdict, duplicate count, and recipient count. An analyst looking at this record can make a triage decision in 30 seconds rather than 5 minutes.
Step 3: Triage Prioritization Tiers
With automated enrichment in hand, categorize each report into one of three tiers before any manual investigation.
Tier 1 — Immediate Response (target: same business day, ideally within 2 hours): Known-malicious verdict from URL or attachment checks. Multiple recipients within the organization who haven't yet reported. Auth failures (DMARC fail, spoofed display name). Domain age under 7 days. Any indication of an active wire transfer request, credential request, or data exfiltration attempt in the body. If the automated processing flags any Tier 1 indicator, it goes to the top of the queue regardless of when it was submitted.
Tier 2 — Standard Investigation (target: within 24 business hours): Unknown URLs with suspicious domain characteristics (fresh domains, lookalike patterns). Social engineering indicators in the body (urgency + authority combinations, out-of-character requests from known contacts). First-time senders from external domains that aren't major platforms.
Tier 3 — Likely Benign, Confirm and Close (target: batch processing, twice daily): Known legitimate senders with a tracking pixel or marketing platform header. Automated notifications from known SaaS platforms. Security awareness training simulations from your own platform. These represent the majority of the queue at most organizations and can be batch-reviewed and closed quickly.
A 2,000-mailbox organization might see 50 reports per week break down roughly as 3–5 Tier 1, 10–15 Tier 2, and 30–35 Tier 3. Tier 1 and 2 require real analyst attention; Tier 3 can be handled by a junior team member with clear criteria or batched into a 30-minute daily queue review.
Step 4: Disposition Actions and Their Scope
For each confirmed or suspected malicious report, the disposition actions need to be clearly defined and executable quickly. Fumbling through multiple consoles during an active incident response wastes time that may matter.
Standard dispositions and their scope:
- Quarantine / delete from all mailboxes: In M365, this is the
Search-Mailboxor Compliance Center Content Search + Purge flow, or the Threat Explorer Investigate + Remediate path in Defender Plan 2. In Google Workspace, this is a Gmail API search and delete operation. Scope: all mailboxes in your tenant that received the message (identified in the automated pre-processing recipient cross-check). - Block sending domain: Add the sending domain to your tenant block list. In M365, this is a Transport Rule or the Blocked Senders list in the anti-spam policy. Effective immediately for future messages from that domain; doesn't retroactively affect already-delivered mail.
- Block URL: Add the malicious URL to your URL block policies. In M365, this is the Tenant Allow/Block List. For supplemental inspection layers, this feeds back into the URL blocklist for the platform.
- Credential reset for clicked employees: If any recipient clicked a link or opened an attachment before the report was processed, treat their credentials as compromised until verified otherwise. Force password reset, revoke active sessions (M365:
Revoke-AzureADUserAllRefreshToken; Google Workspace: Admin SDK Directory API), and review their account activity for the previous 24–48 hours for signs of mailbox rule creation or forwarding setup (common post-ATO persistence moves).
Step 5: Reporter Feedback Closes the Loop
Closing the reporter feedback loop is operationally important for two reasons. First, it maintains reporting culture — employees who report and hear nothing back stop reporting, which degrades your intelligence collection over time. Second, it provides brief, accurate education at the moment it's most relevant: right after a report is triaged.
The feedback message doesn't need to be elaborate. For confirmed malicious reports: "Thank you for reporting this email. We've confirmed it was a phishing attempt and removed it from all mailboxes. No action required on your part." For benign reports: "Thank you for reporting. We've reviewed this message and it appears to be [legitimate marketing / automated notification / etc.]. Reporting anything suspicious is always the right call." Never make an employee feel foolish for reporting a false positive — false positives are the cost of a high-reporting-rate culture, which is worth more than a low-noise queue.
We're not saying you need a custom reporter portal or elaborate feedback templates. A templated email response sent from your IT ticketing system is sufficient. What matters is that the feedback is consistent and sent for every closed report, not just the interesting ones.
Measuring Triage Performance
The key metrics for evaluating your triage process against operational goals:
- MTTR for Tier 1 reports: Mean time from report submission to completed remediation (quarantine + block + credential review if needed). Target under 2 hours for active campaigns. Mandiant M-Trends research consistently shows that dwell time reduction is one of the highest-leverage variables in limiting breach impact.
- Analyst time per ticket by tier: If Tier 3 tickets are taking 15 minutes each, your automated pre-processing isn't doing enough of the classification work. Target under 5 minutes for Tier 3 batch review, 10–20 minutes for Tier 2 investigation, 30–90 minutes for Tier 1 full remediation.
- Reporter false positive rate: Track what percentage of reports are Tier 3 (likely benign). A very high false positive rate (above 80%) may indicate your security awareness training is making employees hypervigilant about safe email rather than calibrating them on actual threat indicators.
- Time-to-detection improvement: Track cases where user reports preceded automated detection. These are your early warning success stories — employee saw something the automated stack missed, reported it, and the threat was remediated before it spread. These cases justify the investment in reporting infrastructure and triage process.
The platform's triage queue provides automated pre-processing enrichment and confidence scoring for each report, reducing analyst work for Tier 2 and Tier 3 tickets substantially. The social engineering indicators article covers the specific body-language signals that triage scoring surfaces for Tier 1 escalation.