What this check looks at
Checks that people can report a Teams message as a security concern, and that the reports reach the organisation’s own reporting mailbox (Microsoft Defender’s user reported settings).
Two settings work together. In Teams, the messaging policy’s "Report a security concern" (AllowSecurityEndUserReporting) adds Report this message to each message’s menu, so people can flag a chat as phishing or a security risk. In the Microsoft Defender portal, the user reported settings decide where reports go (your reporting mailbox, Microsoft, or both) and whether Teams reports are collected at all.
The check fails when reporting is off in the Global Teams messaging policy. With it on, it reads the user reported settings from Exchange Online and fails unless reported Teams messages go to your reporting mailbox (ReportChatMessageToCustomizedAddressEnabled) rather than to Microsoft (ReportChatMessageEnabled is false), and reported junk, not-junk and phishing email also go to the reporting mailbox with an address set, which is how CIS audits it. Where Exchange Online is not set up for ConfigCheckup, the second part is reported as not checked.
Without the option, someone who spots a phishing chat can only delete it or send IT a screenshot, and most just ignore it. Without a reporting mailbox somebody watches, reports disappear and your own team never learns that a campaign is under way, so the same message reaches everyone else and nobody looks for who has already clicked.
Why it matters
Staff are often the first to see a phishing message in Teams. If they cannot report it, or reports go nowhere the security team looks, the same message reaches everyone else before anyone acts.
A typical case: a "help desk" chat from an outside tenant reaches 30 people in a firm. Two report it, but the reports go only to Microsoft. The fourth person engages, approves an MFA prompt and gives the attacker their account. Had the reports reached the MSP’s reporting mailbox, the domain could have been blocked in Teams external access and staff warned within minutes of the first report.
Staff reports are often the earliest warning an organisation gets, ahead of any automated alert. The NCSC’s phishing guidance asks organisations to make reporting easy and to act on reports quickly, and that only works if the reports land somewhere someone looks.
CIS Microsoft 365 Foundations Benchmark 8.6.1 asks that users can report security concerns in Teams, with reports going to the organisation’s own mailbox. It supports PCI DSS 5.4.1 (protecting people against phishing) and the NCSC Cyber Assessment Framework’s C1.c on generating alerts.
How to fix it
Where: Teams admin centre → Messaging → Messaging policies
Before you start
- Choose the reporting mailbox (for example security@) and who monitors it; an MSP often receives a copy.
- The mailbox must be an Exchange Online mailbox in the tenant.
Step by step
- Choose the reporting mailbox and who watches it. Use an Exchange Online mailbox in the tenant, for example a shared mailbox called security@. Decide who checks it every working day (the internal IT lead, the MSP, or both). In the Defender portal, go to Email & collaboration > Policies & rules > Threat policies > Advanced delivery and add it on the SecOps mailbox tab, so reported messages are not filtered before your team sees them.
- Turn on reporting in Teams. In the Teams admin centre, go to Messaging > Messaging policies and select Global (Org-wide default). Turn on "Report a security concern" and select Save. Do the same in any custom messaging policy. In PowerShell: Set-CsTeamsMessagingPolicy -Identity Global -AllowSecurityEndUserReporting $true.
- Send reports to your mailbox in the Defender portal. In the Defender portal, go to Settings > Email & collaboration > User reported settings. Under Microsoft Teams, tick "Monitor reported messages in Microsoft Teams". Under Outlook, keep reporting on with the built-in Report button. Under reported message destinations, choose "My reporting mailbox only" and enter the mailbox address. Select Save. You can still send a report on to Microsoft from the Submissions page when you want its analysis.
- Or set the destinations in Exchange Online PowerShell. Connect-ExchangeOnline as an Exchange Administrator, then run Set-ReportSubmissionPolicy -Identity DefaultReportSubmissionPolicy -EnableReportToMicrosoft $false -ReportChatMessageEnabled $false -ReportChatMessageToCustomizedAddressEnabled $true -ReportJunkToCustomizedAddress $true -ReportNotJunkToCustomizedAddress $true -ReportPhishToCustomizedAddress $true -ReportJunkAddresses security@<domain> -ReportNotJunkAddresses security@<domain> -ReportPhishAddresses security@<domain>. If Get-ReportSubmissionRule returns nothing, create the rule: New-ReportSubmissionRule -Name DefaultReportSubmissionRule -ReportSubmissionPolicy DefaultReportSubmissionPolicy -SentTo security@<domain>.
- Make sure reports are acted on. Show whoever watches the mailbox where reports also appear: Defender portal > Actions & submissions > Submissions > User reported. Agree what they do with a confirmed phish: block the sender or domain, remove copies, check who clicked.
- Confirm the change with a test report. Get-CsTeamsMessagingPolicy -Identity Global | Select-Object AllowSecurityEndUserReporting should show True, and Get-ReportSubmissionPolicy should show ReportChatMessageToCustomizedAddressEnabled True, ReportChatMessageEnabled False and your mailbox in the three report address fields. In Teams, open a test message’s More options > Report this message and report it as a security risk: it should arrive in the mailbox and appear under Submissions > User reported.
With PowerShell
Connect-MicrosoftTeams Set-CsTeamsMessagingPolicy -Identity Global -AllowSecurityEndUserReporting $true Connect-ExchangeOnline Set-ReportSubmissionPolicy -ReportChatMessageToCustomizedAddressEnabled $true
What users will notice
People see "Report this message" on Teams messages. Reports go to the reporting mailbox, where the security team reviews them.
How to confirm it worked
Get-CsTeamsMessagingPolicy -Identity Global shows AllowSecurityEndUserReporting True, and Get-ReportSubmissionPolicy shows ReportChatMessageToCustomizedAddressEnabled True with the reporting mailbox set; report a test message and check it arrives.
Frameworks and controls
This check maps to controls in 14 frameworks. Passing it is evidence that the setting is in place, not a certification against any of them.
| Framework | Control |
|---|---|
| NCSC CAF | C1.c Generating alertsD1.a Response plan |
| DSPT | Standard 6: Responding to incidents |
| DORA | Art. 17 ICT-related incident management process |
| NIS2 | Art. 21(2)(b) Incident handling |
| Microsoft Cloud Security Benchmark | IR-2 Preparation: set up incident notification |
| Zero Trust | Visibility, automation and orchestration |
| SOC 2 | CC7.3 Evaluating security events |
| PCI DSS 4.0.1 | 5.4.1 Personnel are protected against phishing attacks12.10.1 An incident response plan exists and is ready to be activated |
| NIST SP 800-171 | 3.6.1 Establish an operational incident-handling capability |
| CMMC Level 2 | IR.L2-3.6.1 Incident Handling |
| ISO 27001:2022 | A.5.24 Information security incident management planning and preparationA.5.25 Assessment and decision on information security events |
| CIS M365 | 8.6.1 Ensure users can report security concerns in Teams |
| NIST CSF 2.0 | DE.AE-06: Information on adverse events is provided to authorized staff and tools |
| NCSC 10 Steps | Incident managementEngagement and training |
The framework mappings were last checked against the published standards in October 2026.
Microsoft’s documentation
- User reporting of messages in Microsoft Teams (Microsoft Learn)