Publishing a DMARC record with p=reject is supposed to be the finish line. It tells every receiving mail server, in writing, to throw away anything claiming to be from your domain that cannot prove it. Security researchers and Microsoft 365 administrators have been documenting a gap in that promise: a trust tag inside Exchange Online Protection called SCL:-1, which can wave spoofed mail straight past DMARC enforcement, on domains that did everything right.
What SCL:-1 Actually Does
Every message that lands in a Microsoft 365 mailbox gets stamped with a Spam Confidence Level, a header running from -1 to 9 that Exchange Online Protection uses to decide what happens next. Most of that range feeds the normal spam-scoring pipeline. SCL:-1 is different. It means “this message is from a trusted source,” and a message carrying it skips the filtering stack outright, including the anti-phishing checks that are supposed to act on a failed DMARC evaluation. The authentication result can still be computed and logged. It just never gets the chance to matter, because the message was waved through before enforcement runs.
Where the Trust Leaks In
SCL:-1 is not something an attacker sets. It gets applied by the tenant’s own configuration, usually without anyone intending the consequence. The most common source is the IP allow list inside the connection filter policy: any address added there, often years ago to unblock a vendor or a scanner that was having delivery trouble, is now permanently trusted, no matter what mail later arrives from it. Mail flow rules written to smooth out delivery for a specific application can do the same thing by explicitly setting SCL to -1. Inbound connectors configured to treat a partner or gateway as fully trusted carry the same risk. None of these were built as security holes. They were built as delivery fixes, quietly layered on top of each other across years of tenant administration, each one invisible until someone maps the whole chain and finds that a strict DMARC policy is sitting downstream of a dozen ways to bypass it.
Not the Same Gap as Direct Send
It is worth being precise about what this is not. Direct Send, the anonymous relay path we have covered before, lets unauthenticated mail reach a tenant by connecting straight to its MX endpoint on port 25, and Microsoft’s RejectDirectSend setting closes that specific door. SCL:-1 is a different mechanism entirely. It affects mail that arrives through completely normal, authenticated-looking paths, external senders, real connectors, real routing, but gets tagged as trusted before the anti-phishing policy ever evaluates it. Turning on RejectDirectSend does nothing to fix an allow-listed IP or a leftover transport rule. An organization can close the Direct Send door completely and still have SCL:-1 quietly overriding its DMARC enforcement on a different route into the same mailboxes.
What This Means for Your Program
Audit the connection filter allow list first. Every IP address on it should have a documented, current reason to be there. Entries added to solve a one-time delivery problem years ago are the most common source of this gap, and nobody remembers adding them.
Search mail flow rules for explicit SCL:-1 actions. Transport rules that set the spam confidence level directly are easy to write and easy to forget. Each one is a standing exception to whatever your DMARC policy says.
Enable Enhanced Filtering for Connectors on every inbound connector, including ones that route through a third-party gateway. This lets Microsoft evaluate SPF, DKIM, and DMARC against the true originating IP instead of the gateway’s IP, which keeps authentication meaningful even when mail is not arriving directly.
Do not assume RejectDirectSend closes this. It solves anonymous relay abuse. It has no effect on allow-listed or explicitly trusted mail flows, which is a separate audit entirely.
Review anti-phishing policy actions in the Defender portal against what your DMARC record actually declares. A strict policy published in DNS and a permissive action configured in the tenant can coexist indefinitely, with nothing surfacing the conflict unless someone checks both.
The Takeaway
A DMARC record is a promise made in DNS, but Microsoft 365’s own configuration decides whether that promise gets kept. SCL:-1 is not a flaw in DMARC and not a flaw in Microsoft’s filtering engine. It is what happens when years of small, reasonable delivery fixes accumulate into a standing exception that nobody audits against the domain’s current authentication policy. Enforcement is not something you set once in a DNS record and forget. It has to survive contact with every allow list, every transport rule, and every connector an organization has ever added.
Excello Mail gives you continuous visibility into your DMARC reports, so you can see exactly which sources are authenticating under your domain and catch the gap between what your policy declares and what your mail platform actually enforces. Sign up for free to Excello Mail and put real monitoring behind the enforcement you think you already have.