What Does Outlook's Report as Phishing Button Do?

When a user clicks Report as Phishing in Outlook, Microsoft collects the sender address, subject line, timestamp, reporting user identity, and relevant message headers -- including authentication results if your tenant processed the message. That report lands in Microsoft Purview under User Submissions and feeds into Microsoft Defender for Office 365. This is what your security team sees.

Here is what it does not tell you: whether that user clicked anything.

A sysadmin recently called an employee into a meeting to discuss clicking on phishing emails. The employee had only reported the emails using Outlook's phishing reporting button. The admin had conflated a phishing report signal with a user click signal. This mix-up is common enough that it is worth explaining exactly what the reporting workflow does -- and what it does not do.

---

What the Admin Portal Actually Shows for a Reported Email

When you open a phishing submission in Microsoft Defender for Office 365, the portal displays:

The sender address and domain
The subject line and delivery timestamp
Which user submitted the report
Whether that sender has been reported before across your tenant
Authentication results from the message headers: SPF pass/fail, DKIM pass/fail, DMARC pass/fail

This data tells you which emails your users are flagging and whether those senders have authentication problems. It is useful signal. It tells you what your users noticed.

It does not tell you what your users did with the email before reporting it.

---

What Reporting as Phishing Does NOT Do

Three limits worth knowing before you draw conclusions from a report.

It does not block the sender. A single user report has no automatic effect on whether that sender can reach other mailboxes. Microsoft may apply volume-based filtering across your tenant, but one report from one user does not create an instant block.

It does not remove the message from other recipients. If the same phishing email landed in ten inboxes and one user reports it, the other nine still have it. Retroactive removal requires a separate tenant-level policy configuration. Reporting alone does not trigger it.

It does not confirm the user interacted with the content. This is the one that causes the most misplaced blame. A user can read a phishing email, correctly identify it, and report it without ever clicking a link or opening an attachment. The report describes the email. It does not describe the user's behavior on the email.

The Defender portal alert says: "User X reported a phishing message." That is all it says. If you also see "User X clicked a malicious link," that is a separate event with a separate cause, and it requires separate data to confirm.

---

How to Separate a Phishing Report from a Phishing Click

The taxonomy:

A phishing report is a user-flagged signal. It means the user received an email, noticed something wrong, and submitted a report. High report volume from a specific user is usually a sign of a well-trained, vigilant employee.
A click event is a behavioral signal. It means a user actually clicked a link. This requires URL click tracking to be enabled in your Defender policies, and it shows up separately from the submission record.

When you review the portal, ask two questions before taking action:

1. Is there a phishing report for this user and this message?
2. Is there a separate click event logged for this user and this message?

If the answer to question one is yes and question two is no, the user correctly identified and reported a phishing attempt. They did not fall for it. They did exactly what your security program asked them to do.

---

Why Phishing Reports and DMARC Failure Reports Tell You Different Things

Here is the gap that user reports alone cannot fill: phishing reports only catch what your users noticed. If an email looks convincing enough that no one reports it -- but it fails DMARC authentication because the From domain does not match the SPF or DKIM domain -- your users will never flag it, and your Microsoft portal will never show it.

That is what DMARC failure reports are for.

When an email fails DMARC alignment, your mail server or DMARC aggregate report provider receives a structured report showing the sending source, the failure type, and the authentication result. These reports do not require a user to notice anything. They catch the authentication-layer problem regardless of whether the content looked suspicious.

DMARCFlow aggregates these failure reports across your inbound and outbound mail streams, giving you a structured feed of authentication failures that runs parallel to the user submissions in Microsoft Purview. Together, they cover two different failure modes: what your users noticed, and what your domain's authentication posture allowed through -- whether or not anyone reported it.

Neither signal replaces the other. Phishing reports without DMARC data miss the emails that no one reported. DMARC data without phishing reports misses the human judgment that catches phishing that authentication cannot detect.

---

FAQ: Common Questions About Phishing Reporting in Microsoft 365

Can I see whether a user clicked a link in a reported email?
Only if URL click tracking is enabled in your Defender for Office 365 policies. If it is enabled, click events appear as separate telemetry. A phishing report submission does not include click data.

Does reporting an email notify the sender?
No. The report goes only to your tenant's portal and may inform tenant-level filtering policies over time. The sender receives no notification.

If multiple users report the same sender, does that automatically block them?
Microsoft may apply filtering based on report volume across your tenant, but this is not immediate, not guaranteed, and configurable through anti-phishing policies in the security portal.

Why do some reported phishing emails show DMARC pass?
DMARC pass means the From domain aligned correctly with SPF and DKIM. Phishing emails can pass DMARC when the sender controls the domain they are sending from -- for example, a compromised legitimate domain or a convincing lookalike used through a compromised account. DMARC pass confirms the sender is who they claim to be. It does not confirm the content is safe.

Should I disable the Report as Phishing button to avoid confusion?
No. User reports are among the most useful signals for catching phishing that automated systems miss. Train your security team on what the data actually means instead. A user who reports phishing consistently is an asset, not a risk.

---

Bottom Line

The Report as Phishing button sends a user-flagged alert to your security portal. It identifies suspicious emails that your users noticed. It does not track user clicks, it does not block senders, and it does not automatically remove messages from other inboxes.

When a user report appears in the Defender portal alongside a security incident, check whether the report actually corresponds to a click event before drawing conclusions. Confusing a report for a click means blaming the wrong behavior -- and it means overlooking the users who are actually doing the security work your program depends on.

For a more complete picture, run your phishing user reports alongside DMARC failure data. User reports catch what your people noticed. DMARC failure reports catch what your authentication posture allowed through, whether or not anyone reported it. Used together, they give your security team coverage that does not depend on users catching everything.