Why Safe Sender Lists Can Override Your DMARC Policy

When a domain appears in your Microsoft 365 safe sender list, it does not just mark the sender as trusted. It assigns the message a Spam Confidence Level of -1, which skips the rest of the filtering pipeline entirely. SPF fails. DKIM fails. DMARC fails against your p=reject policy. The message lands in the inbox anyway.

This is not a bug. It is a configuration decision, and it has been exploited in the wild.

What the Incidents Showed

ZeroBEC Security published research in July 2026 on the Greatness phishing kit. Four emails landed at one organization, all sent to spoof the RingCentral voicemail notification domain. Every authentication check failed: SPF failed, DKIM had no signature, and DMARC failed against a published p=reject policy at full enforcement. All four were delivered and assigned SCL -1.

The organization was a RingCentral customer and had put the RingCentral domain in its safe sender configuration. That exclusion outranked the authentication result.

The emails carried a banner reading "This sender has been verified by [organization].com safe senders list." The attacker was using the victim's own allow-list as social proof. That only works against an organization that has one.

ZeroBEC's conclusion was precise: "The security stack was not broken. It was working exactly as configured. The vulnerability was the configuration itself."

How Safe Sender Lists Work in the Filtering Pipeline

Microsoft 365 processes incoming mail through a series of checks. Authentication (SPF, DKIM, DMARC) happens early. The SCL assignment happens after authentication. When a domain is on the safe sender list, the SCL assignment is -1, which means the message is immediately marked safe and skips all remaining filtering, including the policy check that would normally block an SPF, DKIM, or DMARC failure.

The same applies to transport rule exceptions configured to allow mail from specific domains. If you have a rule that allows messages from a vendor domain without requiring authentication to pass first, that rule creates a standing bypass.

The practical implication: any domain in your safe sender list or unconditional transport rule exception is a domain that can send you mail that fails every authentication check and still reach your users' inboxes.

Why This Matters More Now Than It Did

Safe sender lists and vendor exclusions were a reasonable trade when the downside was a partner's invoice landing in junk. You accepted some spoof risk in exchange for not having to manage vendor authentication failures manually.

That tradeoff has changed. Vendor breaches now routinely leak customer contact lists and safe sender configurations. An attacker who obtains your vendor list or gains access to a partner's sending infrastructure knows exactly which domains to spoof to reach your users while your authentication checks say fail.

The same configuration logic that bypasses authentication for legitimate vendors also bypasses it for spoofed messages impersonating those vendors. Your DMARC p=reject policy does not protect against this because the policy is never applied to messages that arrive via the safe sender route.

The MFA Bypass Follows the Same Pattern

The Greatness kit research included a separate observation that is worth separating out. The attackers used an adversary-in-the-middle proxy to relay the genuine Microsoft authentication challenge in real time, including number-matching. The user completed it. The token that came back already carried a satisfied MFA claim.

That token was replayed from attacker infrastructure rather than the victim's browser. The result: impossible-travel rules never fired because the login appeared to come from the user's actual location. More than two weeks later, the same proxy IP was still authenticating against the account.

The conditional access policies that should have flagged or blocked the session were not applied. The security stack was working as configured. The configuration had a gap.

How to Audit Your Safe Sender and Transport Rule Exclusions

In Microsoft 365 Exchange Online, check your safe sender list at the mail flow level and at the user level:

• Mail flow rules (transport rules): Run Get-TransportRule | Where-Object {$_.ExceptIfFromAddressMatchesPatterns -or $_.ExceptIfSenderDomainIs -or $_.SetSCL} in Exchange Online PowerShell to find rules that may be bypassing authentication checks. Look for any rule that allows mail from a domain without requiring authentication to pass.
• Outlook safe senders: Check user-level safe sender lists via Get-MailboxJunkEmailConfiguration. Note that these are per-user and harder to audit centrally.
• Connection filtering: Check IP block lists and safe list configurations in Exchange Online Protection.

In Google Workspace, safe senders are handled differently. Gmail does not have an equivalent global safe sender list that bypasses authentication. The equivalent configuration in Google Workspace is typically handled through malware and phishing policies in the admin console. Review any "allow sender" entries that do not also require the sending domain to pass SPF or DKIM.

The question to ask for each exclusion: does this allow mail from this domain without requiring authentication to pass? If yes, that domain can spoof your users' mailboxes regardless of your DMARC policy.

What DMARC Reports Show When Allow-Lists Override Policy

Your DMARC aggregate reports will show aligned authentication failures for the spoofed domain, because the authentication checks genuinely failed. These reports are not wrong. They are showing you exactly what happened at the mail transport layer.

What the reports do not show is whether the message was ultimately delivered or blocked. That depends on your safe sender configuration, not on your DMARC policy.

When you see repeated aligned failures for domains that you believe should be blocked by your p=reject policy, and those failures are not accompanied by bounce or rejection events, that is the signal. It means either the sending infrastructure is misconfigured, or your filtering layer is allowing mail that should not be allowed.

This is one of the most useful things DMARCFlow does for this specific scenario. Most DMARC monitoring tools show you aligned failures and tell you the domain is not protected. DMARCFlow also flags when failure volumes and delivery volumes suggest a configuration override may be in play, so you investigate the mail flow rules, not just the authentication setup.

---

FAQ

Can a safe sender list override DMARC?

Yes. In Microsoft 365, a domain in the safe sender list is assigned SCL -1, which skips the rest of the filtering pipeline including policy enforcement. A DMARC p=reject policy does not block mail that arrives via the safe sender route because the policy check never runs.

Does DMARC fail if my domain is in the recipient's allow-list?

DMARC performs its authentication checks regardless of allow-lists. What allow-lists affect is what happens after authentication fails. In Microsoft 365, SCL -1 from a safe sender bypasses policy enforcement, so the message is delivered despite the DMARC failure.

How do transport rule exceptions affect DMARC?

A transport rule that allows mail from a specific domain without requiring authentication to pass creates the same bypass. The rule is applied after authentication, and if the rule says allow, the message proceeds regardless of SPF, DKIM, or DMARC result.

How do I audit safe sender lists in Microsoft 365?

Run Get-TransportRule in Exchange Online PowerShell to find rules with exceptions that may bypass authentication checks. Check Get-MailboxJunkEmailConfiguration for user-level safe sender lists. Review connection filtering safe lists in Exchange Online Protection.

What is SCL -1 in Exchange Online?

SCL stands for Spam Confidence Level. SCL -1 marks a message as explicitly safe, which causes it to skip all remaining filtering checks. It is assigned when a sender or domain matches a safe sender or safe domain entry.