The Tenant Allow Block List should replace your SCL -1 bypass rules

In the customer tenants I review, I still come across SCL -1 transport rules far more often than I'd like. The story is usually the same. There was a delivery problem, a partner's domain got blocked, or a marketing tool needed a quick fix, so someone created a mail flow rule that sets the Spam Confidence Level to -1 and skips filtering altogether. It feels fast. It's also a dangerous shortcut, because SCL -1 fully disables Defender for Office 365's protections for those messages (anti-malware, anti-phishing, safe links, even ZAP and quarantine). Any malware or phishing from that sender goes straight to user inboxes without being inspected. Rules like this practically invite targeted attacks, and in many cases the original business reason disappeared long ago while the rule stayed in place, out of sight and still risky.

SCL -1 mail flow rules put everyone at risk

SCL -1 mail flow rules (set via "Mail flow rules" → "Set the spam confidence level (SCL) to -1") switch off filtering for every matching message. No anti-malware, no spam checks, no phishing protection, nothing at all. Legitimate business senders and partners get a free pass, and so do attackers if they manage to spoof or compromise that address or domain. You give up security and visibility at the same time, because these rules have no audit trail and no expiry. As the exceptions pile up over the years, forgotten and unmonitored, they turn into a real liability.

My tip: Track down SCL -1 rules and get rid of them as soon as you can. Set them temporarily to SCL 0 or 1 and watch which legitimate messages (if any) actually get blocked, then adjust from there. Don't bypass filtering for whole domains or partner addresses unless you have a good reason and review it regularly.

The Tenant Allow Block List is the right place for exceptions

For trusted domains, sender addresses, spoofed senders, URLs and file hashes, the Tenant Allow Block List is the modern and safe option. It lives in the Microsoft Defender portal → Email & collaboration → Policies & rules → Threat policies → Tenant Allow/Block Lists. You manage allowed and blocked entries centrally there, with full auditability and expiration. One detail matters a lot: allow entries created through admin submissions (when you report a false positive and Microsoft agrees) always expire automatically after a set period. That limits long-term risk and cuts down on forgotten exceptions.

Mail passes the allow and block lists before the normal filters

The simplified diagram below shows how incoming mail is checked against the allow and block lists before standard filtering kicks in:

flowchart TD
    Inbound["Mail received"] --> BlockCheck["Check block list"]
    BlockCheck -->|"Hit"| Reject["Reject"]
    BlockCheck -->|"No hit"| AllowCheck["Check allow list"]
    AllowCheck -->|"Hit"| Allow["Deliver (filtered, but preferred)"]
    AllowCheck -->|"No hit"| Filters["Normal filters (spam, phish, malware)"]
    Filters --> Outcome["Deliver or block"]

Figure: Email filtering with Tenant Allow Block List and mail filters.

What you get are exceptions that are traceable, scoped and time-bound. Allow entries also don't switch off all filtering the way SCL -1 rules do. Malware is still blocked, and the filters still log their verdicts. For organizations whose partners change often, or whose cloud systems occasionally get flagged, this is the only approach that scales and keeps security and the business running side by side.

Spoof intelligence lets admins grant allows that expire

One of the best things about the Tenant Allow Block List is how it ties into Spoof Intelligence. Defender analyzes sender and domain combinations, surfaces likely spoofing patterns and lets you review them on the "Spoofed senders" tab. From there, admins can allow a specific scenario with a defined expiry. That saves a lot of pain during migrations or testing, because special cases don't turn into permanent exceptions. Everything stays visible and expires on schedule unless someone renews it.

Regular reviews of the list are essential

I recommend going through the allow/block list at least once a quarter. Look closely at partner domains, leftover migration entries and admin submissions. Plenty of auto-generated allows are no longer needed once the original incident is resolved. The Defender portal now shows who created each entry, where it came from (manual or submission) and when it expires. As of August 2026 there's no built-in export, but PowerShell via the Security & Compliance module (role: Security Administrator or Security Reader) lets you list and review items quickly.

PowerShell lists all allow and block entries

# PowerShell 7, ExchangeOnlineManagement module (Connect-ExchangeOnline required)
Get-TenantAllowBlockListItems -ListType All | ft ListType, Entry, ExpirationDate, CreatedBy

The output gives you a clear overview and makes it easy to spot entries that are about to expire or whose origin needs a closer look.

I see the Allow/Block List as your safety net

Relying on SCL -1 rules is something you'll end up regretting. For business exceptions, the Tenant Allow Block List is the only approach that gives you traceability, expiry and Spoof Intelligence integration instead of security blind spots. If you haven't done it yet, clean out those old mail flow bypasses and switch to proper allow/block management. Compliance improves, you'll have fewer incidents, and investigations become a lot less stressful.

If you want to go further, read SPF, DKIM & DMARC for Exchange Online: DNS done right and Microsoft's documentation on the Tenant Allow Block List.