Why Microsoft Marks Reported Phishing Emails as Clicked

"When users click the Microsoft Report Phishing button in Outlook, Microsoft Defender automatically scans the links in the reported email. Phishing simulation platforms then register this as a user click -- creating false positives that get employees in trouble and skew security metrics. Here is why it happens and how to fix it.

The Confusion: "I Only Reported It, Why Am I Flagged for Clicking?"

It starts with a phishing simulation. KnowBe4 sends a simulated phishing campaign to the company. One employee receives the test email, recognizes it as suspicious, clicks the Microsoft Report Phishing button, and moves on. Forty-eight hours later, the security team gets an alert: that employee clicked a phishing link.

The employee is baffled. They never opened the email body. They never clicked anything inside the message. They only reported it.

This plays out in IT departments worldwide. Employees lose trust in security awareness training. Admins waste time investigating false positives. And the metric that is supposed to measure human risk becomes meaningless.

The root cause is almost always the same: the Microsoft Report Phishing button.

What Microsoft Actually Does When You Report a Phishing Email

When a user clicks the Microsoft-built "Report Phishing" button in Outlook -- the shield icon with an exclamation mark -- the email is submitted to Microsoft Defender for analysis.

What many admins do not realize is what happens next. As part of the analysis pipeline, Microsoft Defender visits and scans every URL in the reported email. This is intentional. Microsoft uses the scans to assess whether the message is malicious, to update its threat intelligence, and to feed its machine learning classifiers.

The destination server logs this automated visit the same way it logs any web request -- IP address, user agent, timing pattern.

How Phishing Simulation Platforms Misread This as a Click

Phishing simulation platforms like KnowBe4 and Proofpoint track clicks by monitoring which recipients visit the links in their simulation emails. They detect this through web server logs -- looking for incoming requests from employee IP addresses.

When Microsoft Defender scans a reported email, it visits those same links from an Azure IP address. The simulation platform sees a request from Microsoft servers -- not from the employee's device. Many platforms either count this as a user click anyway or flag it without explaining the source. The result is a false positive in the simulation report, caused by a feature working exactly as Microsoft designed it.

The Key Difference: The Microsoft Button vs. Third-Party Add-In Buttons

Not all "Report Phishing" buttons behave the same way.

The Microsoft-built button submits the email to Microsoft Defender. This triggers the automated URL scanning described above.

Third-party add-in buttons -- such as the KnowBe4 Phishing Alert Button, Cofense Reporter, or the GoPhish user reporting plugin -- bypass Microsoft Defender entirely. The email goes directly to the organization's own simulation or SOC platform. No Microsoft URL scanning occurs.

For organizations running phishing simulations, using a third-party add-in button eliminates the false positive problem. The tradeoff is losing Microsoft's automated analysis. Many organizations run both: a third-party button for simulation and SOC reporting, and the Microsoft button for general submissions to Defender.

How to Route Reported Emails to Your SOC Instead of Microsoft

The most direct fix is to change where reported emails go. Microsoft Purview lets you configure "User Reported Settings" to route reported messages to a custom mailbox instead of, or in addition to, Microsoft.

Step 1: In the Microsoft Purview portal, go to Solutions > Threat protection > Submissions. You need the appropriate admin role.

Step 2: Under "User reported settings," select Edit settings.

Step 3: For "Mailbox to route reported messages to," enter your SOC shared mailbox address.

Step 4: Choose your Microsoft submission preference. Select "Submit to Microsoft only if the mailbox is not available" to route to your SOC first.

Step 5: Choose the user notification style. The default "Thank you for reporting" notification is fine.

Step 6: Save. Changes take effect within minutes.

After this, reported emails go to your SOC first. Your team reviews them, escalates real threats, and forwards to Microsoft only when needed. This also gives your SOC visibility into what employees are actually encountering.

Note that this configuration applies only to the Microsoft-built reporting button. Third-party add-in buttons have their own routing, managed in the add-in admin console.

For Phishing Simulation Admins: Calibrating Your Platform Correctly

If you cannot change the reporting button configuration, you can exclude Microsoft-related IP ranges from your click tracking.

In KnowBe4, add Microsoft's Azure IP ranges to an exclusion list so that visits from Microsoft servers are not counted as employee clicks. Proofpoint has a similar allowlist feature. Tell your simulation platform to ignore web traffic from Microsoft's cloud infrastructure.

Before you do this, confirm with your Microsoft admin that the scanning IP ranges are consistent. Azure IP ranges for Defender analysis can change, so you may need to update the exclusion list periodically.

As a longer-term approach, work with your simulation vendor to import user-reported emails from the Microsoft button as "reported -- not clicked" events through an API integration with Microsoft Purview. This gives you accurate metrics without sacrificing the Microsoft Defender analysis pipeline.

FAQ: Common Questions About the Report Phishing Button

Does the Microsoft Report Phishing button work differently on mobile?

No. Outlook mobile uses the same built-in reporting mechanism and triggers the same Microsoft Defender URL scanning pipeline.

Will disabling the Microsoft Report Phishing button cause problems?

It depends on your security posture. The button is a valuable early warning system. If you disable it without an alternative in place, you lose visibility into what employees are encountering. Redirect it to your SOC instead.

Does the scanning only happen with the built-in Outlook button?

Yes. The URL scanning behavior is specific to the Microsoft-built reporting workflow. Third-party add-in buttons that route directly to your SOC or simulation platform do not trigger Microsoft scanning.

Can Microsoft see the content of emails reported by my users?

Yes. Messages submitted through the built-in button are processed by Microsoft Defender, including the email body, headers, and URLs. If your organization has data residency requirements, review Microsoft's data processing terms for Defender submissions.

My simulation platform shows the IP as Microsoft. Why is it still counted as a click?

Some platforms count any visit to a simulation link as a click, regardless of the source IP. You need to configure an explicit exclusion rule for Microsoft's Azure IP ranges. Check your platform documentation for "IP allowlisting" or "click exclusion rules."

Bottom Line

The Microsoft Report Phishing button is doing exactly what it is designed to do. The side effect is that its automated scans look like user clicks to phishing simulation platforms.

The fix is straightforward. Route reported emails to your SOC first. Calibrate your simulation platform to ignore Microsoft server traffic. Or deploy a third-party add-in button for your simulation-related reporting. Any one of these eliminates the false positive and restores the integrity of your phishing simulation metrics.

Proper DMARC enforcement also plays a role. When your domain has strong DMARC policies, attackers cannot easily impersonate your administrators in the first place -- reducing the volume of phishing that reaches users and needs to be reported.