Phishing Report Button Missing from Outlook Mobile

Your phishing report add-in shows as deployed in the Microsoft 365 admin center. The status card is green. Every license check passes. And yet, when an executive opens Outlook on their phone, the report button is not there.

This is not a rare bug. It is a structural gap between what the M365 admin portal measures and what actually happens inside an Outlook mobile session. Here is what causes it and how to fix it.

The Disconnect Between Deployed and Working

The M365 admin portal shows which add-ins are assigned to which users, which platforms are supported, and whether the add-in is enabled. That view is accurate as far as it goes.

It does not show whether the add-in actually loads inside Outlook mobile for a given user session. That depends on Conditional Access policy settings, Intune app protection rules, and whether the add-in is marked as available inside the Outlook mobile app. These layers sit outside the admin center's visibility.

A user can have a fully assigned, fully enabled add-in and still never see the report button in Outlook mobile.

Why Conditional Access Policies Block Outlook Add-Ins on Mobile

Conditional Access is the most common culprit. Three CA policy settings specifically prevent Outlook add-ins from loading on mobile:

Block grants on the Outlook mobile app. If your CA policy has a block action for the Outlook mobile app, the session never starts and the add-in never loads. Easy to create during a lockdown cycle and easy to forget to scope narrowly.

Compliant device requirements applied to the wrong user groups. If your CA policy requires Intune enrollment or a specific device compliance state, users on personal devices or non-compliant hardware get an Outlook mobile session but an add-in execution context that is restricted. The app opens and mail arrives, but the add-in pane is absent.

Session policies that restrict web content. Outlook mobile loads add-ins inside a webview. If your CA policy includes session controls that block web content from loading inside the app, the add-in may be silently blocked from initializing even though the session is otherwise valid.

To check this: open the Azure AD sign-in logs, filter for Outlook mobile sign-in events for an affected user, and check which CA policy applied. Look at the CA result code, not just the sign-in success indicator. A compliant-device requirement can show as "success" at authentication while still restricting add-in execution.

How Intune App Protection Policies Interfere

Intune app protection policies (MAM) control what Outlook mobile can do with data and what actions are available inside the app. They operate independently from device enrollment and are easy to overlook when troubleshooting add-in availability.

When an Intune app protection policy restricts organizational data to managed apps only, or limits what the app can read from the current message context, the phishing report add-in can lose access to the selected email. The add-in pane may open but show a blank message. The user taps Report, the action fails silently, and the phish sits in the inbox.

The key setting to check in your Intune app protection policy for Outlook mobile is the data transfer policy. If it is set to managed apps only or blocks clipboard access, it can break the message context the add-in needs to construct the report.

How to Diagnose the Missing Button

Work through these four checks in order:

1. Check add-in status in M365 admin for mobile availability. Navigate to Settings > Add-ins in the M365 admin center. Open the specific add-in and look at platform support. Confirm that iOS and Android are listed as enabled platforms, not just Windows and Mac. Some add-ins have separate toggles for desktop and mobile.

2. Test directly inside Outlook mobile. Have the affected user open Outlook mobile, long-press on a test message, and open the three-dot menu. If an add-in is available, it appears in that menu. If the phishing report add-in does not appear, it is not loading for that session.

3. Review Conditional Access policy grants in the sign-in logs. Use the Azure AD sign-in logs to find the user's Outlook mobile sessions and check which CA policy applied and what the result was. The sign-in log shows the CA result code separately from the authentication result.

4. Check Intune MAM policy assignments for the user group. In the Intune admin center, confirm that Outlook mobile is covered by the app protection policies assigned to the user. Policies scoped to specific app groups may exclude users whose accounts are not in the assignment.

How to Fix It

Once you know which layer is causing the gap:

Adjust Conditional Access to allow add-in execution in Outlook mobile. Create a separate CA policy for the Outlook add-in scenario if needed. Use grant controls that allow the Outlook mobile session while optionally requiring compliant devices for groups where that is appropriate. The key is to avoid a blanket block or compliance requirement that applies to all users regardless of their device state.

Enable the add-in for mobile in the M365 admin portal. Confirm the mobile platform toggle is on for the add-in. This is a separate setting from user assignment. If the mobile toggle is off, the add-in will not load regardless of CA policy.

Align add-in assignment with Outlook mobile user groups. The add-in must be assigned to the same users who have Outlook mobile active. If your add-in is assigned to a security operations group that is excluded from your Outlook mobile CA policy, the add-in will never appear on mobile for those users even though it is assigned to them.

Test the full phishing report workflow from a mobile device after making changes. Do not rely on the admin center. Have a real user follow the exact steps: open the email, tap the three-dot menu, select the phishing report add-in, and confirm the report. If that path completes without errors, the fix is confirmed.

When Forwarding to Security Email Is the Only Mobile Option

If you cannot resolve the mobile add-in gap quickly, configure a security@ alias as a fallback. Users can forward suspicious emails from Outlook mobile to that address, bypassing the add-in requirement entirely.

The tradeoff is evidence quality. Forwarded mail often arrives stripped of full headers, with the original message repackaged in a new envelope. Your security team's forensic analysis is degraded compared to a proper add-in submission that captures the full RFC 822 message and original delivery path.

This is where DMARC aggregate reports become directly relevant. Even when your phishing reporting workflow is unavailable on mobile, DMARC reports show you which external domains are sending mail that fails authentication for your domain. A new sending domain that appears in aggregate reports with consistent failures is a signal worth investigating, regardless of whether your phishing queue captured the same messages through direct reports.

DMARCFlow collects and parses these aggregate reports and surfaces authentication failures that may indicate spoofing or vendor misconfiguration. When your mobile reporting path is broken, those reports are often the only structured signal you have that something unauthorized is being sent using your domain.

How to Test Your Reporting Path End-to-End

Set up a monthly mobile test as part of your security operations validation:

Send a test phish from a known external address to an executive account on your domain
Have the executive attempt to report it from Outlook mobile using your configured method
Confirm the report arrives in your security queue with enough context to analyze
If the report does not arrive, document the failure and open a remediation ticket

Most organizations discover the mobile reporting gap only after a real incident surfaces a detection failure. A monthly test catches the gap before it costs you.

FAQ

Why does M365 admin say the add-in is deployed but it does not appear in Outlook mobile?

The admin center measures assignment and platform support. It does not measure whether the add-in actually loads inside the Outlook mobile session for a given user. Conditional Access policies and Intune app protection settings control add-in execution independently from the admin view.

Can Conditional Access policies block Outlook add-ins on mobile?

Yes. Block grants, compliant device requirements, and session controls applied to Outlook mobile can prevent the add-in from initializing even when the user has a valid session and the add-in is assigned to them.

How do I test whether my phishing reporting works on mobile?

Open Outlook mobile, long-press on any message, and look for the add-in in the three-dot menu. If the phishing report add-in is not listed, it is not loading for your session. Then test the full report flow from a mobile device to confirm the submission arrives in your security queue.

What do I do if I cannot enable the phishing report add-in for mobile?

Configure a security@ alias as a fallback. Users can forward suspicious mail to that address from Outlook mobile. Supplement this with DMARC aggregate monitoring so spoofing that bypasses your reporting queue is still visible in authentication failure reports.

How does DMARC monitoring relate to missing phishing reports?

DMARC aggregate reports show authentication failures across all mail sent using your domain, including spoofing that reached recipients without triggering your phishing queue. If your reporting workflow is unavailable on mobile, DMARC reports provide an independent detection layer for domain impersonation.