Why Microsoft Outlook Marks Reported Phishing Emails as Clicked

The problem in plain terms

An employee receives a suspicious email, clicks the Report Phishing button in Outlook, and two days later their manager shows them a report saying they clicked a phishing link. They did not click anything. They reported the email.

This is a configuration problem, not a user failure. And it is more common than most IT teams realize.

When a user clicks the built-in Report Phishing button in Microsoft Outlook, Defender for Office 365 submits the message to Microsoft for analysis. Part of that analysis involves Microsoft visiting the URLs in the email to check whether they are malicious. That automated visit gets logged - and third-party phishing simulation platforms read it as a user click.

The result: employees who did everything right get flagged for doing something wrong.

What Defender actually does when someone reports a phishing email

Microsoft's automated analysis system visits URLs in reported messages. This is by design - it helps Microsoft build threat intelligence and identify malicious links. The problem is that phishing simulation platforms often cannot distinguish between Microsoft's automated link check and a real user clicking a link.

KnowBe4, Proofpoint, Cofense, and other platforms can log URL visits from reported messages as user clicks. KnowBe4's documentation notes that reporting a simulated phishing email should not trigger a click - but only when the reporting is routed through KnowBe4's system, not through Microsoft's default submission pipeline.

Proofpoint has similar behavior. Its system may log the Microsoft Defender user agent as a click, even though no human opened the link.

How to stop the false positives

The fix has two parts: route phishing reports to your own SOC instead of Microsoft, and make sure your phishing simulation platform is configured to ignore automated submissions.

Step 1: Set up a custom reporting mailbox

In the Microsoft Security portal, go to Settings > Email & collaboration > User reported settings. Change the destination from Microsoft to a custom mailbox that your SOC team manages. This way, reported messages go directly to your team instead of being submitted for Microsoft's automated analysis.

You need an Exchange transport rule to route messages reported through the built-in button to your custom mailbox. The rule checks for the Report Phishing submit action and redirects it before it reaches Microsoft's submission pipeline.

Step 2: Configure your phishing simulation platform

KnowBe4: In your KnowBe4 console, go to Simulation Settings and make sure the Microsoft Report Phishing integration routes reports to KnowBe4 rather than to Microsoft. When users click the Outlook add-in button, the report goes to KnowBe4's system, which recognizes it as a simulation and does not log a click.

Proofpoint: In Proofpoint's TAP console, check the User-Reported Messages settings. Make sure the integration with Microsoft does not treat reported messages as clicks. Proofpoint should distinguish between its own simulation clicks and external reporting events.

Intune: If you manage Outlook via Intune, you can control which reporting add-ins are available. Some organizations remove the Microsoft Report Phishing button entirely and deploy only their chosen third-party solution.

Step 3: Audit what your users are actually reporting

Before you change anything, check what your users are reporting. In the Microsoft Defender portal, go to Submissions. Look at the User Reported tab. You may find that a large percentage of reports are from users correctly identifying real threats - and that a smaller percentage are reports triggered by your own phishing tests.

This baseline tells you whether the problem is misconfigured reporting, a gap in user training, or simply that your simulation platform is picking up Defender's automated link checks.

Why this keeps happening: the spoofed internal email problem

The reason employees end up reporting so many phishing emails in the first place is often that attackers are sending them messages that appear to come from internal infrastructure - the company Exchange server, the IT department, the CEO. These are convincing enough that employees report them, and then get penalized for it.

This is exactly the attack that DMARC p=reject is designed to stop. When you publish a strict DMARC policy, external senders cannot impersonate your internal domain. Employees stop receiving fake internal phishing emails. They stop reporting them. Your simulation platform gets fewer false positives to deal with.

The connection to DMARC reporting is direct: DMARC aggregate reports show you exactly which external sources are attempting to send email as your domain. If you see a high volume of attempts from sources you do not recognize, that is a sign your domain is being actively spoofed - and your employees are likely receiving those spoofed emails and reporting them, which creates the exact confusion described here.

Tools like DMARCFlow make this easier by aggregating your DMARC reports and flagging unauthorized sending sources. If your own mail infrastructure is sending email that fails DMARC alignment, DMARCFlow surfaces that so you can fix it before it trains your users to ignore real threats.

FAQ

Q: Does clicking Report Phishing ever actually count as a click?
Only if the platform is misconfigured or the report is routed through Microsoft's default submission pipeline. With proper configuration, reporting should never trigger a click in your simulation platform.

Q: We use KnowBe4. Should we remove the Microsoft Report Phishing button entirely?
You can, but it is not necessary. The better approach is to keep both buttons and configure Microsoft to route reports to your SOC rather than to Microsoft. That way you get visibility into real threats that users encounter outside of simulation campaigns.

Q: Our employees are getting flagged for clicking links in emails they only reported. What do we tell them?
Show them the Defender submission logs in the Security portal. Point to the Microsoft user agent in the link visit records. This proves the click came from Microsoft's automated system, not from a human.

Q: Can we just disable URL checking in Defender submissions?
Not without reducing your security posture. Microsoft's URL analysis is useful threat intelligence. The right fix is to route submissions to your own SOC instead of Microsoft's, so you get the benefit without the false positive problem in your simulation results.

Q: How does this affect our phishing simulation results?
If you do not fix this, your click rates look higher than they actually are. This makes it hard to get an accurate picture of real vulnerability. After the fix, your baseline will be lower and more honest - which is better for measuring real security improvement over time.