Does the Applicant have a report-phishing email add-in enabled for all email users?
The button matters less than what happens after it is pressed, but without the button almost nothing gets reported at all.
What the carrier is actually asking
The carrier is asking whether every user has a one-click way to report a suspicious message, and implicitly whether those reports go somewhere useful. Forwarding a suspicious message manually loses the headers and discourages reporting; a built-in button preserves the evidence and takes two seconds.
Why it is underwritten
Users are the detection layer for messages that got through filtering. The interval between the first delivery and the first report determines how many people interact with a campaign. Organisations with easy reporting detect in minutes; organisations without it detect when someone's account starts sending mail.
Where the answer lives in Microsoft 365, Entra ID, and Azure
This is directly measurable in Microsoft 365, both the deployment of the button and the volume of reports it produces.
| Platform | Where the setting lives | What has to be true |
|---|---|---|
| Microsoft 365 | User reported settings in the Defender portal | Reporting enabled, with a destination mailbox or direct submission to Microsoft configured |
| Microsoft 365 | Add-in deployment state across the user base | Deployed to all users rather than to a group, and present in Outlook on web, desktop, and mobile |
| Microsoft 365 | Submissions history in the security portal | Actual report volume, which is the practical test of whether users know the button exists |
| Microsoft 365 | Automated investigation triggered by user reports | Reports initiate an investigation rather than sitting in a queue |
| Process | Who reviews reports and how quickly | A named owner with a response target, and feedback to the reporting user. Attested |
Users who report and hear nothing stop reporting within a few months. A short acknowledgement, even automated, is what keeps the detection layer alive. Report volume over time is the metric that shows whether this control is working.
What a defensible yes requires
- Reporting is available to every user in every mail client they use.
- Reports reach a monitored destination with a named owner.
- Reports trigger investigation of who else received the message.
- Users receive an acknowledgement, so the behaviour persists.
- Report volume is tracked, since a sudden drop usually means the button broke rather than that phishing stopped.
How this answer goes wrong
The button is deployed and reports arrive in a mailbox nobody owns. Or it is deployed to the desktop client and absent on mobile, where a significant share of mail is read. Both produce a technically true yes and an ineffective control.
Frequently asked
Does the built-in Outlook option count?
Yes. The native reporting experience in Microsoft 365 satisfies this question when it is enabled and its destination is configured, which are two separate settings.
Should reports go to Microsoft or to us?
Both is the usual answer. Microsoft improves filtering; your own copy lets you scope who else received it, which is the part that limits the incident.
What report volume is healthy?
There is no benchmark that transfers between organisations. Watch your own trend. A decline usually means a deployment problem, and a spike usually means a campaign.
How does this connect to phishing simulations?
Directly. Simulations that measure only click rate miss the more useful metric, which is how many people reported. Reporting rate is the behaviour you actually want.
Related questions
Stop answering this from memory
Connect Microsoft 365, Entra ID, and Azure read-only. Insurance Posture reads the live configuration behind each application answer and shows you which ones you can prove before you sign.
Assess your posture