What this check looks at
Checks every inbound anti-spam policy for allowed sender domains, whose mail skips spam filtering.
Inbound anti-spam policies (the default policy and any custom ones) have lists of allowed senders and allowed domains. Mail from an allowed domain skips spam filtering and goes to the inbox whatever its spam verdict; only malware and high-confidence phishing verdicts still apply. The lists are usually filled in years ago to rescue a supplier’s mail from junk and never looked at again.
The check reads every inbound anti-spam policy and fails when any lists one or more allowed sender domains, naming the domains (up to five in the summary, every one in the evidence). It passes when no policy has an allowed domain. Allowed individual senders are not part of this check.
The allow is based on the sender’s address, which is easy to fake. Anyone who spoofs or impersonates an allowed supplier, or compromises one of its mailboxes, goes straight past spam filtering into the inbox. Allowing a large webmail domain such as gmail.com, which happens more often than it should, opens the door to everyone.
Why it matters
An allowed domain is trusted however the mail is sent, and the From address is easy to fake. Phishing that spoofs an allowed supplier lands in the inbox with no spam check at all.
A typical case: an estate agency allowed its conveyancing solicitors’ domain years ago because completion statements kept going to junk. An attacker who compromises one solicitor’s mailbox, or spoofs the domain while it has no enforcing DMARC, sends a revised completion statement with new bank details. Spam filtering never looks at it, and a buyer’s deposit goes to a fraudster.
The fix is cheap: remove the allows and let genuine mail be filtered like everything else. Most well-configured senders are unaffected, and the rare false positive can be handled with a Tenant Allow/Block List entry that Microsoft manages and removes when it is no longer needed.
CIS Microsoft 365 Foundations Benchmark 2.1.14 asks for inbound anti-spam policies not to contain allowed domains. ISO 27001 A.8.7 and A.8.9, CIS Controls v8 9.7, NIST CSF 2.0 PR.PS-01 and NCSC CAF B4.b expect filtering exceptions to be the minimum needed.
How to fix it
Where: Microsoft Defender portal → Email & collaboration → Policies & rules → Threat policies → Anti-spam
Before you start
- Note why each allowed domain was added; a supplier whose mail is wrongly caught belongs in the Tenant Allow/Block List for that sender, not the anti-spam policy.
Step by step
- Record what is allowed and why. Connect with Connect-ExchangeOnline and run Get-HostedContentFilterPolicy | Format-List Name, AllowedSenderDomains to see every allowed domain by policy, matching the finding’s evidence. Keep the list in the ticket and ask the client why each was added; most are forgotten.
- Remove the allowed domains in the portal. In the Microsoft Defender portal, go to Email & collaboration > Policies & rules > Threat policies > Anti-spam and open each inbound policy in the evidence, starting with Anti-spam inbound policy (Default). Select Edit allowed and blocked senders and domains, open the allowed domains list, select every entry, delete them and save.
- Or remove them in PowerShell. Run Set-HostedContentFilterPolicy -Identity Default -AllowedSenderDomains $null, and the same with -Identity set to each custom policy named in the evidence.
- Handle genuine false positives properly. If mail from one of those senders is then wrongly caught, release it from Email & collaboration > Review > Quarantine and submit it in Actions & submissions > Submissions as should not have been blocked, choosing to allow it. That creates a Tenant Allow/Block List entry for the sender which is still checked for malware and high-confidence phishing.
- Move phishing simulations to advanced delivery. If an allowed domain belongs to a phishing simulation or security awareness service, configure it under Email & collaboration > Policies & rules > Threat policies > Advanced delivery, on the Phishing simulation tab, with the sending domains and IP addresses the vendor documents. That is the supported route.
- Watch quarantine for a week. Over the next week, check Email & collaboration > Review > Quarantine for messages from the previously allowed domains and release any genuine ones as above, so the client sees no disruption.
- Confirm the lists are empty. Run Get-HostedContentFilterPolicy | Format-Table Name, AllowedSenderDomains and check every policy shows an empty list. The next assessment passes.
What users will notice
Mail from the previously allowed domains goes through spam filtering like everything else; well-configured senders are unaffected.
How to confirm it worked
Get-HostedContentFilterPolicy shows an empty AllowedSenderDomains for every policy.
Frameworks and controls
This check maps to controls in 13 frameworks. Passing it is evidence that the setting is in place, not a certification against any of them.
| Framework | Control |
|---|---|
| NCSC CAF | B4.b Secure configuration |
| DSPT | Standard 9: IT protection |
| NIS2 | Art. 21(2)(e) Security in acquisition, development and maintenance, including vulnerability handling |
| Zero Trust | Applications |
| SOC 2 | CC6.8 Preventing or detecting unauthorised or malicious software |
| PCI DSS 4.0.1 | 5.4.1 Personnel are protected against phishing attacks |
| NIST SP 800-171 | 3.14.2 Provide protection from malicious code |
| CMMC Level 2 | SI.L2-3.14.2 Malicious Code Protection |
| ISO 27001:2022 | A.8.7 Protection against malwareA.8.9 Configuration management |
| CIS M365 | 2.1.14 Ensure inbound anti-spam policies do not contain allowed domains |
| CIS Controls v8.1 | 9.7 Deploy and maintain email server anti-malware protections (IG3) |
| NIST CSF 2.0 | PR.PS-01: Configuration management practices are established and applied |
| NCSC 10 Steps | Architecture and configuration |
The framework mappings were last checked against the published standards in October 2026.
Microsoft’s documentation
- Create safe sender lists (Microsoft Learn)