What this check looks at
Checks the connection filter for IP addresses allowed to skip spam filtering, and for Microsoft’s safe list, which does the same for senders Microsoft trusts.
The connection filter policy in Exchange Online Protection decides which sending servers are trusted by IP address. Mail from addresses on its IP Allow List, and from senders on Microsoft’s safe list (turned on with Turn on safe list), skips spam filtering and sender authentication checks; it is still scanned for malware and high-confidence phishing. Both are empty or off in a new tenant and are usually added to fix a one-off delivery problem.
This check reads the default connection filter policy. It raises a warning (it never fails) when any IP address is on the allow list or the safe list is on. The evidence lists the allowed addresses.
An allowed IP is trusted for everything it sends, now and in future. If it belongs to a shared mail service, a marketing platform or a supplier’s server, anyone else who uses or compromises that server can send mail that arrives without spam checks, including spoofed messages claiming to come from the organisation itself. The safe list does the same for senders the organisation does not control.
Why it matters
Mail from an allowed IP address skips spam and spoofing checks entirely. If that address belongs to a shared service, or is ever compromised, phishing arrives in inboxes looking cleared. Neither list is needed when SPF and connectors are set up properly.
Years ago a 45-person firm added its email marketing provider’s sending IPs to the allow list after newsletters went to junk. Another customer of the same provider later abuses the platform to send phishing that claims to come from the firm’s own domain; because the IPs are allowed, the messages skip filtering and land in every inbox looking legitimate.
Properly configured senders do not need the allow list: SPF, DKIM, an inbound connector or an entry in the Tenant Allow/Block List handle the legitimate cases more narrowly. Removing the entries returns those senders to normal filtering without blocking them.
CIS Microsoft 365 Foundations Benchmark 2.1.12 asks for the connection filter IP allow list not to be used, and 2.1.13 asks for the connection filter safe list to be off. CIS Controls v8 safeguard 4.1, ISO 27001 A.8.7 and A.8.9, the NCSC CAF secure configuration outcome and NIST CSF PR.PS-01 support it.
How to fix it
Where: Microsoft Defender portal → Policies → Anti-spam → Connection filter policy
Before you start
- Note who sends from each allowed IP address. A system that sends as the company’s domain belongs in SPF or an inbound connector.
- Check message trace for mail from those addresses over the last 30 days, to know what to watch after the change.
Step by step
- Record what is there now. Connect to Exchange Online PowerShell and run Get-HostedConnectionFilterPolicy -Identity Default | Format-List IPAllowList, EnableSafeList. Keep a copy of the addresses so the change can be reversed.
- Work out who each address belongs to. For each allowed IP, find who sends from it (a reverse DNS lookup, the client’s records or the change history), and run a message trace for mail from it over recent days (Get-MessageTraceV2 -FromIP <address>, or Get-MessageTrace in older modules) so you know what to watch after the change.
- Set up legitimate senders properly. For a system that sends as the organisation’s domain, add it to the SPF record or create an inbound connector for it (Exchange admin centre > Mail flow > Connectors). For a trusted external sender being wrongly filtered, add a narrow allow entry for that sender in the Tenant Allow/Block List in the Microsoft Defender portal rather than allowing an IP.
- Empty the allow list and turn off the safe list. In the Microsoft Defender portal, go to Email & collaboration > Policies & rules > Threat policies > Anti-spam and open Connection filter policy (Default). Select Edit connection filter policy, remove every address under Always allow messages from the following IP addresses or address range, untick Turn on safe list and Save. Or run Set-HostedConnectionFilterPolicy -Identity Default -IPAllowList $null -EnableSafeList $false.
- Watch for mail going astray. For the next week, check quarantine (Defender portal > Email & collaboration > Review > Quarantine) for genuine mail from those senders, and fix any with SPF, a connector or a narrow allow entry.
- Confirm the policy is clean. Run Get-HostedConnectionFilterPolicy -Identity Default | Format-List IPAllowList, EnableSafeList: IPAllowList should be empty and EnableSafeList False. The warning clears at the next assessment.
What users will notice
Mail from the previously allowed addresses goes through spam filtering like everything else; well-configured senders are unaffected.
How to confirm it worked
Get-HostedConnectionFilterPolicy -Identity Default shows an empty IPAllowList and EnableSafeList as False.
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.12 Ensure the connection filter IP allow list is not used2.1.13 Ensure the connection filter safe list is off |
| CIS Controls v8.1 | 4.1 Establish and maintain a secure configuration process (IG1) |
| 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
- Configure connection filtering (Microsoft Learn)