What this check looks at
Checks for enabled mail flow (transport) rules that set the spam confidence level to -1 for mail from named sender domains, which delivers it without spam filtering.
Mail flow rules (transport rules) in Exchange Online can change how any message is handled. A common action sets the spam confidence level (SCL) to -1, which Exchange treats as bypass spam filtering: the message goes to the inbox whatever its spam or bulk verdict, with only malware and high-confidence phishing verdicts still applied. Combined with a condition such as the sender’s domain is supplier.co.uk, it allow-lists a whole domain.
The check reads every mail flow rule and fails when any enabled rule sets SCL -1 and has a sender domain condition, naming the rules and their domains. It passes when no enabled rule does both. Rules that set SCL -1 on other conditions, such as a sender IP address, are not flagged by this check.
The domain in a sender’s address is the easiest thing in email to fake. A rule trusting a domain trusts anyone who claims to be it: a spoofed message, or mail from the partner’s own compromised mailbox. Phishing simulation vendors and old support articles often told administrators to create these rules, so many tenants still have one.
Why it matters
A rule trusting a sender domain bypasses every spam and phishing check for anything claiming to be from it, and the sender address is trivial to fake. It is one of the most common reasons phishing reaches inboxes in otherwise well-run tenants.
An MSP set up a rule years ago so a client’s payroll bureau’s emails never went to junk. When the bureau’s domain was spoofed in a phishing run, every message carrying a fake payslip portal link went straight to the inboxes of 200 staff, past filtering that would have caught it, and several people entered their passwords before anyone noticed.
Removing the rule costs little: genuine mail from a well-configured sender passes spam filtering anyway, and the occasional false positive can be handled with a submission and a Tenant Allow/Block List entry. Keeping it leaves a hole any attacker can use simply by choosing the right sender address.
CIS Microsoft 365 Foundations Benchmark 6.2.2 asks that mail transport rules do not allow-list specific 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 minimal and justified.
How to fix it
Where: Exchange admin centre → Mail flow → Rules
Before you start
- Note why each rule exists; a partner whose mail must arrive belongs in an inbound connector with TLS, or the Tenant Allow/Block List for a specific sender.
Step by step
- Find the rules. In the Exchange admin centre (admin.exchange.microsoft.com), go to Mail flow > Rules and open each rule named in the evidence; look for a condition on the sender’s domain and the action that sets the spam confidence level to bypass spam filtering. In Exchange Online PowerShell: Get-TransportRule | Where-Object { $_.SetSCL -eq -1 -and $_.SenderDomainIs } | Format-Table Name, State, Priority, SenderDomainIs.
- Find out why each rule exists. Read the rule’s comments and ask the client: a supplier whose mail was junked, a phishing simulation vendor, an alerting or scanning service. Use Mail flow > Message trace in the Exchange admin centre to see how much mail the domains send.
- Move phishing simulations to advanced delivery. If a rule exists for a phishing simulation or security awareness platform, configure that vendor in the Microsoft Defender portal under Email & collaboration > Policies & rules > Threat policies > Advanced delivery, on the Phishing simulation tab, with the sending domains and IP addresses the vendor documents.
- Disable the rules. Select each rule and switch it off with Enable or disable rule, or run Disable-TransportRule -Identity "<rule name>". Disabling rather than deleting keeps the rule for a week or two in case you need to see what it did.
- Handle genuine false positives. If mail from one of the domains is wrongly caught after the change, release it from Email & collaboration > Review > Quarantine and submit it in Actions & submissions > Submissions as should not have been blocked, which creates a Tenant Allow/Block List entry still checked for malware and phishing. For a partner whose mail must never be filtered, base any exception on its sending IP addresses, never its domain.
- Delete the rules once settled. After a week or two without problems, delete the disabled rules (Remove-TransportRule -Identity "<rule name>") so they cannot be switched back on by mistake.
- Confirm no rule bypasses filtering by domain. Run the Get-TransportRule command from the first step again and check no enabled rule is returned. The next assessment passes.
What users will notice
Mail from the named domains is filtered for spam like everything else. A partner that sends cleanly is unaffected.
How to confirm it worked
Get-TransportRule shows no enabled rule with SenderDomainIs and SetSCL -1.
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 | 6.2.2 Ensure mail transport rules do not whitelist specific 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
- Mail flow rules in Exchange Online (Microsoft Learn)