Why Your Phishing Reporting Button Disappears on Mobile (And What Your Rollout Checklist Is Missing)

The Scenario That Happens More Than It Should

An enterprise security team deploys KnowBe4's phishing reporting add-in to their Microsoft 365 environment. The deployment dashboard shows 94% success. The team marks the project complete and moves on.

Six months later, a finance executive receives a convincing DocuSign spoof on their iPhone. The executive is traveling, reads the message on Outlook mobile, recognizes something is off, and tries to tap the "Report Phishing" button. It is not there. They spend two minutes searching for a report option, give up, and delete the email. Six hours later, three colleagues receive the same message. One clicks through. The security team has no idea any of this happened.

This is not a hypothetical. It is a recurring pattern in enterprise phishing reporting deployments, and the reason it keeps happening is that almost nobody tests the mobile path before declaring victory.

Why Desktop Deployment Success Does Not Mean Mobile Is Working

Phishing reporting add-ins like KnowBe4 and Microsoft's built-in reporting tool use the Outlook add-in API. On desktop Outlook, add-ins are installed per-user through the Exchange admin center or Intune, and they load into Outlook on the desktop application directly.

Outlook mobile does not run the same Outlook desktop application. It connects to Exchange or Microsoft 365 using REST-based APIs, and add-in availability on mobile depends on a separate set of policies that are easy to overlook.

Specifically:

- Desktop add-in assignment is managed through the Exchange admin center under Add-ins. Mobile add-in availability requires that the same add-in is deployed to mobile clients via Intune or a separate mobile policy assignment.

- Some add-ins show "deployed" in the admin center but have mobile compatibility flags that are not checked by default.

- If a user's mailbox is on an Exchange Server version that predates REST API add-in support, the add-in may load on desktop but fail silently on mobile.

The result is that the admin center shows a green deployment status, the user gets the add-in on their laptop, and nobody discovers the mobile gap until an actual phish lands in a mobile inbox and cannot be reported.

This is a testing problem, not a product defect. The tools work correctly on desktop because that is the path IT teams naturally test. Mobile is invisible until it matters.

How to Test Your Phishing Reporting Rollout Before You Have an Incident

Add this to your phishing tool deployment checklist before you close the ticket:

1. Enroll a test device with Outlook mobile on iOS. Use a real user mailbox, not a shared test account, because add-in assignment is per-user.
2. Connect the test device to the same Microsoft 365 tenant as your production users.
3. Send a test phishing message to the enrolled test user from your testing platform.
4. Open the message on the test iPhone and confirm the Report Phishing button is visible and responsive.
5. Repeat steps 1-4 on an Android device running Outlook mobile.
6. Repeat steps 1-5 with a second test user to rule out a profile-specific caching issue.
7. Log the test result in your deployment sign-off record alongside the desktop confirmation.

If the button is missing on mobile in step 4, you have found a gap that affects every mobile user in your organization. Do not close the deployment ticket until you have resolved it.

What to Do When the Report Button Is Missing on Mobile

If testing reveals the mobile gap, here is where to look:

Check the add-in assignment scope in the Exchange admin center. When you deploy an add-in, you choose which users get it. The assignment panel has separate toggles for "desktop" and "mobile." The mobile toggle is easy to miss. Verify that the relevant user population is included in the mobile assignment.

Verify the add-in is marked as mobile-compatible. In the Exchange admin center, go to Add-ins > the specific add-in > Edit. Some older add-in versions do not advertise mobile compatibility. If the add-in has a "mobile" tab in its settings, confirm it is enabled there.

Check whether your Intune mobile app protection policies are blocking add-in activation. Intune app protection policies (also called MAM policies) can restrict what add-ins can do inside Outlook mobile. If your security team has deployed a strict data loss prevention policy to Outlook mobile, it may be blocking the reporting add-in from loading.

Test with a fresh Outlook mobile profile. If the add-in works on desktop and on some mobile devices but not others, cached credentials or a corrupted local profile can cause inconsistent behavior. Have the affected user remove the Outlook mobile account, restart the app, and re-add the account.

If all else fails, open a support ticket with the add-in vendor. Provide the specific Outlook mobile version, OS version, and the results of your testing checklist. Mobile add-in compatibility issues are often fixable with a configuration change on the vendor side.

What Email Authentication Logs Can and Cannot Tell You About Unreported Phishing

This is where DMARC aggregate reports come in, and it is worth being clear about what they do and do not show.

DMARC reports tell you which emails passed or failed authentication checks at the border. If a phishing message arrives and your DMARC policy is set to reject or quarantine, the report will show the authentication failure. But DMARC reports do not tell you whether your users successfully reported the message through your phishing reporting tool.

This means a domain with a strong DMARC reject policy can still have users who encounter phishing in their inbox and cannot report it. The authentication layer caught the phish at the border. The reporting layer failed because the mobile path was broken. You have no visibility into the second part if you are only looking at DMARC aggregate reports.

DMARC monitoring tools like DMARCFlow cannot tell you whether your executive successfully used the Report Phishing button on their phone. But they can tell you something the reporting button cannot: which sending sources are consistently failing DMARC alignment against your domain. A spike in DMARC failures from a particular sending infrastructure, combined with low user report rates, is a pattern that suggests phishing is reaching inboxes through an unauthenticated path while your reporting layer has a coverage gap.

Specifically, DMARCFlow aggregate reports can flag when a third-party mailing service your organization uses is sending mail that fails DMARC alignment. This matters for the reporting gap because if a vendor is spoofing your From domain without your knowledge, and your users cannot report the phish on mobile, you may never see evidence of the compromise in your reporting tool. DMARC authentication monitoring catches the authentication-layer signal that your user reporting layer missed.

The practical implication: treat your phishing reporting tool's mobile deployment status as a security metric, not an IT logistics concern. The percentage of mobile users who can successfully report phishing is a number your security team should know. And run DMARCFlow alongside your reporting tool so you have authentication-level signals to fall back on when the user reporting path is broken.

Frequently Asked Questions

Does Microsoft's built-in Report Message add-in work on Outlook mobile by default?

Not automatically. It must be deployed to mobile users through the same add-in assignment process as third-party tools. The deployment dashboard in the Microsoft 365 admin center shows combined deployment status, which can obscure mobile-specific gaps.

Our dashboard shows 95% deployment but mobile users say the button is missing. Why?

The 95% figure almost always reflects desktop-only reporting. The Microsoft 365 add-in deployment view does not break out mobile vs. desktop by default. You need to check the specific add-in assignment panel and verify that mobile assignment is enabled for your target population.

Can I deploy phishing reporting to mobile devices through Intune or mobile device management?

Yes, but the method depends on your setup. If you use Microsoft Defender for Office 365, the Report Message add-in can be deployed through Intune app configuration. For KnowBe4 or other third-party tools, check whether they have an Intune deployment guide. Intune MAM policies can also block add-in behavior, so test after deployment rather than assuming the policy allows the add-in to function.

If a phish bypasses DMARC and lands in a user's mobile inbox, how do I know it happened?

DMARC aggregate reports show authentication results including aligned SPF/DKIM pass or fail, and they show the sending infrastructure. If the phish came from an external domain that failed DMARC, your reports will show it. DMARCFlow's aggregate report monitoring flags DMARC failures and sends alerts when suspicious sources are failing authentication, including when a vendor or third-party service is sending mail that fails alignment against your domain.

This is authentication intelligence, not user reporting data. The two monitoring layers are complementary: when mobile reporting is broken and a phish slips through, DMARC reports may catch the authentication anomaly even when your user reporting tool has no data for the incident.