What this check looks at
Checks the default anti-malware policy notifies an administrator when someone inside the organisation sends a message containing malware.
Exchange Online Protection scans every message for malware, including mail sent between people inside the organisation. When it stops one, the anti-malware policy can notify an administrator, separately for internal and external senders. In the default anti-malware policy these notifications are off, so a malicious message sent from a colleague’s account is quarantined silently.
The check reads the default anti-malware policy and passes when Notify an admin about undelivered messages from internal senders is on and an administrator address is set. It fails when the notification is off, and also when it is on but no address is set, because then nobody receives it.
Malware sent from inside is rarely a person choosing to send it. It usually means an account has been taken over and is sending malicious attachments to colleagues, who trust internal mail, or that an infected device is sending through Outlook. Quarantine stops that one message; the notification is what sends someone to find the cause.
Why it matters
A colleague sending malware is usually a compromised account or an infected machine. Being told at once means it is cleaned up before it spreads, rather than found in a report later.
A typical case: a receptionist’s account is phished and the attacker sends an updated holiday rota with a malicious attachment to the whole company. Exchange Online Protection catches the first wave, but nobody is told, so the account stays compromised and the attacker tries again with a link, which gets through. One notification would have led to a password reset that afternoon.
Missing it costs whatever the compromise leads to: ransomware spreading from a second victim, or invoice fraud from the compromised mailbox. Turning the notification on takes a minute and costs nothing.
CIS Microsoft 365 Foundations Benchmark 2.1.3 asks for administrators to be notified about internal users sending malware. NIST CSF 2.0 DE.AE-06 (information on adverse events given to authorised staff), CIS Controls v8 13.1, ISO 27001 A.8.7 and A.8.16, and NCSC CAF C1.c (generating alerts) all expect detections to reach a person.
How to fix it
Where: Microsoft Defender portal → Email & collaboration → Policies & rules → Threat policies → Anti-malware
Before you start
- Choose a monitored mailbox, such as the security team’s, for the notifications.
Step by step
- Choose the address. Use a monitored shared mailbox or distribution list, such as the security mailbox, that at least two people read. The policy takes a single address, so a list or shared mailbox is better than a person.
- Open the default anti-malware policy. In the Microsoft Defender portal, go to Email & collaboration > Policies & rules > Threat policies > Anti-malware and select Default (Default) to open its details.
- Turn on internal sender notifications. In the Notifications section select Edit notification settings. Under Admin notifications tick Notify an admin about undelivered messages from internal senders, enter the address in Administrator email address and select Save.
- Or set it in PowerShell. Connect with Connect-ExchangeOnline and run Set-MalwareFilterPolicy -Identity Default -EnableInternalSenderAdminNotifications $true -InternalSenderAdminAddress security@contoso.com, using the client’s address.
- Match any custom anti-malware policies. Custom anti-malware policies take priority over the default for the people they cover. Set the same notification on each one so it works whichever policy catches the message; the check itself reads only the default policy.
- Confirm the setting. Run Get-MalwareFilterPolicy -Identity Default | Format-List EnableInternalSenderAdminNotifications, InternalSenderAdminAddress and check it shows True and the address. The next assessment passes.
With PowerShell
Set-MalwareFilterPolicy -Identity Default -EnableInternalSenderAdminNotifications $true -InternalSenderAdminAddress security@yourdomain
What users will notice
None for users. The mailbox is told whenever malware sent from inside the organisation is stopped.
How to confirm it worked
Get-MalwareFilterPolicy -Identity Default shows EnableInternalSenderAdminNotifications as True and an InternalSenderAdminAddress.
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 alerts |
| DSPT | Standard 9: IT protection |
| DORA | Art. 10 Detection of anomalous activities |
| NIS2 | Art. 21(2)(b) Incident handling |
| Microsoft Cloud Security Benchmark | LT-1 Enable threat detection capabilities |
| Zero Trust | Visibility, automation and orchestration |
| SOC 2 | CC7.2 Monitoring system components for anomalies |
| NIST SP 800-171 | 3.14.6 Monitor systems to detect attacks |
| CMMC Level 2 | SI.L2-3.14.6 Monitor Communications for Attacks |
| ISO 27001:2022 | A.8.7 Protection against malwareA.8.16 Monitoring activities |
| CIS M365 | 2.1.3 Ensure notifications for internal users sending malware is enabled |
| CIS Controls v8.1 | 13.1 Centralize security event alerting (IG2) |
| NIST CSF 2.0 | DE.AE-06: Information on adverse events is provided to authorized staff and tools |
| NCSC 10 Steps | Logging and monitoringIncident management |
The framework mappings were last checked against the published standards in October 2026.
Microsoft’s documentation
- Configure anti-malware policies (Microsoft Learn)