Handling a reported phishing email in Microsoft 365, end to end

A user clicks Report in Outlook and the message lands in your queue. It might be harmless marketing, a real phishing campaign aimed at dozens of colleagues, or the first sign of an account that is already compromised. The difference between a five-minute ticket and a serious incident is how quickly you find out who else received it and who interacted with it.

This walkthrough follows that order: analyze the message, scope the campaign, check for clicks, clean up, and close the loop.

Step 1: analyze the reported message

User reports appear in the Microsoft Defender portal under Actions & submissions → Submissions, on the User reported tab (Microsoft Learn). Open the message and look at four things before anything else:

• The real sender: the address in From, the Reply-To if it differs, and whether the domain is a lookalike of one you trust.
• Authentication results: SPF, DKIM and DMARC. Failures do not prove phishing, and passes do not prove safety, since attackers can send from domains they own or from compromised accounts. But a failed DMARC check on a message claiming to be from your own domain is a strong signal.
• Links: hover, do not click. Note the real destination and whether it imitates a sign-in page. Detonate suspicious URLs in a sandbox rather than in your own browser.
• The ask: credentials, payment, a file to open, or a call to a phone number. Requests to change bank details point toward business email compromise rather than credential phishing.

Step 2: find every copy of the campaign

One report rarely means one recipient. In advanced hunting, search by sender and subject to find every copy that was delivered:

EmailEvents
| where Timestamp > ago(7d)
| where SenderFromAddress =~ "billing@contoso-invoices.example"
    or Subject has "Overdue invoice 4471"
| project Timestamp, NetworkMessageId, RecipientEmailAddress, SenderFromAddress,
    Subject, DeliveryAction, LatestDeliveryLocation, ThreatTypes
| order by Timestamp desc

LatestDeliveryLocation tells you where each copy is now, for example the inbox, junk folder or quarantine. Attackers often vary the subject line or the sending address within a campaign, so also try the sending domain, the link domain or the attachment name if the first search looks incomplete. Threat Explorer offers the same pivots in a graphical view.

Step 3: find out who clicked

Safe Links records clicks on URLs in email. Join the campaign's messages to those click records:

let campaign = EmailEvents
    | where Timestamp > ago(7d)
    | where SenderFromAddress =~ "billing@contoso-invoices.example"
    | project NetworkMessageId;
UrlClickEvents
| where Timestamp > ago(7d)
| where NetworkMessageId in (campaign)
| project Timestamp, AccountUpn, Url, ActionType, IsClickedThrough, IPAddress
| order by Timestamp asc

ActionType shows whether the click was allowed or blocked, and IsClickedThrough shows whether the user continued past a Safe Links warning page. Anyone who reached the page is now part of the investigation.

Step 4: remove the messages and block the source

Once you have confirmed the message is malicious, remove every delivered copy, not only the reported one. From Threat Explorer or the advanced hunting results, select the messages and use Take action to move them to deleted items or delete them (Microsoft Learn). The action is tracked in the Action center.

Then stop the next wave: add the sender, domain or URL to the Tenant Allow/Block List. Block the most specific thing that covers the campaign; blocking a whole domain used by a legitimate service, such as a file-sharing platform, will cause more trouble than it solves.

Step 5: close the loop

1. Tell the reporter

   In the Submissions page, mark the reported message and notify the user. People who get feedback keep reporting; people who never hear back stop.

2. Document the campaign

   Record the sender, subject, link domains, number of recipients, who clicked and what you removed, with timestamps. These details become indicators for future hunts.

3. Decide whether it is an incident

   A blocked campaign with no clicks can usually be closed. A click followed by a sign-in from an unfamiliar location is an incident and should be escalated under your incident response process.

What good looks like

A well-handled phishing report answers three questions with evidence: who received it, who interacted with it, and whether every copy is gone. Saving the two KQL queries above with the sender and subject as parameters turns the next report into a few minutes of work.