Safe Sender Lists Can Override Your DMARC p=reject Policy

Four emails arrived in an inbox with DMARC set to reject. SPF failed. DKIM was absent. All four were marked SCL -1, which means safe and skip all remaining filters. The organization had added the RingCentral domain to its safe sender list. That list outranked the authentication result.

This is not a DMARC misconfiguration. DMARC worked. Something below it in the email security stack unmade the result. And unless you are monitoring for the pattern, you would not see it happening.

DMARCFlow tracks authentication failures across your inbound mail and flags the discrepancy when failures are not producing rejections. If your aggregate reports show SPF or DKIM failures that are not being rejected, that is the signal that something is overriding your policy. It is the fastest way to find a safe sender configuration you forgot you set.

How Email Filtering Layers Actually Stack

DMARC does not operate at the perimeter. It runs inside the email security pipeline, which means it is subject to decisions made by layers above it. Safe sender allow-lists, transport rules, and Conditional Access policies all evaluate mail before DMARC gets a chance to act.

Here is the sequence that actually runs inside Microsoft 365:

The message arrives at the gateway.
Transport rules and safe sender lists evaluate the sender.
If the sender matches an allow rule, the message is marked safe before authentication checks run.
DMARC evaluates the message.
If DMARC fails and the policy is reject, the system checks whether the message is already marked safe.
Safe overrides reject. The message delivers.

The same layering exists in Google Workspace, Proofpoint, Cisco Ironport, and most cloud email security products. Allow rules sit above authentication in the evaluation order. That is by design. It was a reasonable tradeoff when the primary threat was a partner invoice landing in junk.

Why Safe Sender Lists Override Authentication

Safe sender lists were added to email systems to handle a real problem: legitimate mail getting blocked by overeager spam filters. The fix was to let admins mark specific domains or addresses as trusted. When a domain is on that list, the system skips spam analysis and authentication checks for mail from that source.

In Microsoft 365, safe sender configuration lives in Exchange Transport Rules, the Spam Filter Policy, or Conditional Access. Each can be configured to bypass spam filtering, skip the Authentication Credits check, or both. If authentication bypass is enabled, SPF, DKIM, and DMARC do not run at all for matching messages.

In Google Workspace, the equivalent lives in the Spam settings under Advanced Settings. Domains marked as safe senders can be configured to bypass spam and delivery classification.

The design assumption behind these bypasses was that a trusted partner would not spoof your domain. That assumption is exactly what the Greatness phishing kit exploits.

The Specific Attack Pattern

The Greatness phishing kit works because it spoofs domains the target organization already trusts:

The attacker selects a domain the target uses internally, such as RingCentral, Zoom, Microsoft 365, or an internal line-of-business tool.
The attacker sends email that fails SPF, carries no DKIM signature, and fails DMARC against a p=reject policy.
The target organization's email gateway checks the safe sender list and finds the spoofed domain.
The message is marked safe and skips all remaining checks.
The recipient sees a banner reading "This sender has been verified by [organization] safe senders" - which is the social proof the attacker uses to make the message credible.
The recipient clicks the link or opens the attachment.

The attack works without breaking any authentication mechanism. It uses the organization's own configuration against it.

How to Audit Your Safe Sender Configuration

Run this audit now, before your domain is the one being spoofed:

List every domain and IP address in your safe sender and allow-list configurations across all email security layers, including Exchange Transport Rules, Spam Filter Policies, and Conditional Access.
Check each entry to determine whether it bypasses authentication checks or only spam filtering. Bypassing authentication is the higher-risk setting.
Identify any entries that allow mail without requiring the sender to authenticate first. These are the entries that can be exploited by an attacker spoofing that domain.
Audit Conditional Access policies for any rules that whitelist specific domains without requiring MFA or device compliance.
Look for transport rules that automatically approve mail from specific senders or domains without additional verification.
Review the list for any domains used in internal line-of-business tools, VoIP platforms, or cloud services that send email on behalf of your users.
Reduce the list to the minimum required for operations. Every unconditional allow is a standing instruction to bypass authentication for that domain.
Set a recurring calendar review - at minimum annually and after any change to your email security configuration.

How to Detect an Allow-List Override Using DMARC Reports

Your DMARC aggregate reports (RUA) show authentication failures. If your reports show SPF or DKIM failures from a specific domain but that mail is arriving in inboxes rather than being rejected, that gap is a signal that something is overriding your policy.

DMARCFlow processes aggregate reports automatically and flags two patterns that indicate an allow-list override:

Consistent SPF or DKIM failures from a domain that is not generating rejection feedback
Sudden spikes in authentication failures without a corresponding change in rejection rates

These patterns are the fingerprints of a safe sender rule undoing your p=reject policy. DMARCFlow surfaces them as alerts rather than requiring you to parse raw aggregate reports manually.

Conclusion

Your DMARC p=reject policy is doing its job. The authentication checks are working correctly. The problem is that authentication enforcement at the DMARC layer is only as strong as the layers above it.

Safe sender lists and transport rules are configuration tools. They solve real problems with legitimate mail. But every unconditional allow is a standing instruction to bypass authentication for whoever can claim that domain name.

Auditing your allow-lists is the only way to know whether your p=reject policy is actually doing what it says on the outside of your email security stack.