Why Your DMARC p=reject Policy Is Not Enough: How Safe-Sender Lists Override Authentication

The scenario that should not have worked

On July 22, four emails arrived at one organization within seconds of each other. They spoofed a RingCentral voicemail notification domain, sent from an IONOS host with no connection to RingCentral's mail infrastructure. The authentication results were unambiguous: SPF failed, DKIM was absent, DMARC failed against a published p=reject policy at full enforcement.

All four were delivered. They were also assigned SCL -1, which marks a message as safe and skips the remaining filtering pipeline.

The reason: the organization was a RingCentral customer and had added the RingCentral domain to its safe-sender configuration. That safe-sender entry outranked the authentication result. DMARC had done its job correctly. Something else overrode the outcome after it arrived.

This is not a hypothetical. This is documented in research published by ZeroBEC in August 2026.

Why safe-sender lists outrank DMARC

DMARC operates at the MTA level. When a receiving server processes an inbound message, it runs SPF, DKIM, and DMARC alignment checks in sequence. If DMARC fails against a p=reject policy, the MTA is supposed to reject the message.

But many organizations run email security gateways in front of their MTA. These gateways -- Microsoft Defender for Office 365, Cisco IronPort, Proofpoint, Mimecast, and others -- maintain their own evaluation logic. Safe-sender lists, transport rules, and domain-based exceptions run inside the gateway, after the MTA has already accepted the message.

The gateway evaluates the safe-sender list after authentication. When it finds a match, it overrides the DMARC result. The MTA's reject decision is effectively unwound. The message was already accepted, and now the gateway delivers it anyway.

This is why a domain can have p=reject published and still get spoofed. The reject fires at the border, but the gateway has already been configured to let that domain through regardless.

The other places this happens

Safe-sender lists are not the only configuration that creates this gap.

Transport rules in Exchange and Microsoft 365 can include domain exceptions that bypass spam filtering. An administrator who added a vendor domain to a transport rule to ensure legitimate mail lands in inbox instead of junk may have simultaneously instructed the system to ignore authentication results for that domain.

Third-party email gateways maintain their own allow-lists. If your organization uses a gateway to proxy inbound mail before it reaches Microsoft 365 or Google Workspace, the gateway's rules apply before the tenant's authentication results. Some gateway configurations allow administrators to specify domains that bypass all checks.

Integrated SaaS security tools can create the same situation. When your email security stack is layered -- gateway, SEG, integrated AI scanning -- each layer may have its own exception logic. A configuration that makes sense at one layer may undermine the authentication result from another.

The vendor breach connection

The risk is not only theoretical. When vendors are breached, their customer configurations can leak. This includes safe-sender lists, transport rule exports, and gateway allow-lists.

An attacker who obtains a vendor's customer allow-list knows exactly which domains are configured to bypass authentication at that organization. Those domains become high-value targets for impersonation, because the organization's own infrastructure is configured to deliver mail from those domains without checking SPF, DKIM, or DMARC.

This is not a new attack pattern. It is an exploitation of a configuration choice that made sense before vendor breaches were common and that now represents a standing risk.

What a proper audit looks like

If you have DMARC p=reject configured, here is what you need to check:

How many domains are in your safe-sender configuration? In Microsoft 365, open Exchange Admin Center, go to Mail Flow > Rules, and review every rule that includes an exception for specific senders or domains. Look for rules that bypass spam filtering or authentication checks based on sender domain.

Are any of those exceptions unconditional? An unconditional exception means any mail claiming to be from that domain bypasses all checks. A conditional exception might require the sender to pass authentication first, which is the safer option.

Do your third-party gateways have allow-lists? If you route mail through a gateway before it reaches your tenant, the gateway's configuration is part of your authentication posture. A reject policy at your MTA does not protect against a gateway that is configured to deliver anyway.

For each domain in your allow-lists, ask whether it needs to be unconditional. In most cases, a conditional allow-list -- one that still requires SPF or DKIM to pass -- provides the same practical benefit with less risk.

How to close the gap

The fix is not to remove safe-sender lists. Legitimate business mail sometimes lands in junk because of over-aggressive filtering, and safe-sender lists solve a real operational problem.

The fix is to require authentication to pass before the allow-list applies. Configure your gateway so that a domain on the safe-sender list still has to satisfy SPF, DKIM, and DMARC alignment before the override kicks in. The safe-sender list becomes a reason to treat authenticated mail as trusted, not a reason to skip authentication entirely.

In Microsoft 365, this means reviewing the interaction between your spam filter policies and your mail flow rules. The specific setting depends on your gateway and version, but the principle is consistent: the allow-list should gate trust, not bypass security.

DMARC aggregate reports cannot tell you whether your gateway is overriding authentication. Aggregate reports show what the MTA border saw, not what the gateway did after. A message that passed DMARC at the border but was overridden by the gateway will show as a pass in your aggregate report.

This is where DMARCFlow becomes part of your monitoring stack. DMARCFlow processes your aggregate reports continuously, tracking your authentication pass rates, failed authentication volume, and sudden shifts in either metric. If your gateway reconfiguration causes a change in delivery patterns, DMARCFlow will surface that in the data. The aggregate report shows a pass, but the volume shift tells you something changed. Combined with your gateway logs, you have the full picture: what the border saw, what the gateway did, and when the pattern shifted.

The MFA AiTM angle, briefly

The same ZeroBEC research documented a second attack with the same root cause: configuration, not technology failure.

In a separate incident, an AiTM proxy relayed a genuine Microsoft MFA challenge in real time, including number-matching. The user completed it. The token that came back was replayed from attacker infrastructure. Impossible travel rules did not fire. More than two weeks later, the same proxy IP was still authenticating against the compromised account.

The condition that made both attacks possible: no Conditional Access policies were applied. The security stack was not broken. It was working exactly as configured. The gap was the configuration itself.

The transferable point is not about RingCentral or IONOS or any specific vendor. It is that DMARC p=reject and strong MFA are both necessary, but neither is sufficient when the configuration of the surrounding systems creates exceptions.

FAQ

Can DMARC aggregate reports tell me if my safe-sender list overrode a reject?

No. Aggregate reports show what arrived at the MTA border. If your gateway overrode DMARC after the MTA accepted the message, the aggregate report shows a pass or fail based on the border evaluation. You cannot see the override in aggregate report data. Only your gateway's mail flow logs show when the gateway delivered mail that the border would have rejected.

Does setting p=reject still help if my gateway has allow-lists?

Yes. For mail that is not covered by an exception, your p=reject policy works correctly. Spoofed emails from domains not in your allow-lists will be rejected. The gap only exists for the subset of domains you have configured to bypass checks.

How do I find all the allow-lists in my environment?

In Microsoft 365: Exchange Admin Center > Mail Flow > Rules. Look for any rule that includes an exception based on sender domain, sender address, or recipient domain. In the spam filter policy, check the Connection Filter Exception Senders list and any safe sender lists configured at the organization level. For third-party gateways, check the vendor's configuration interface for allow-list or exception settings. The answer is usually in the mail flow or message routing section.

Is this a Microsoft 365-specific problem?

No. Any email gateway that evaluates allow-lists after DMARC authentication can create this gap. The pattern has been documented across Cisco IronPort, Proofpoint, Microsoft Defender for Office 365, Mimecast, and other platforms. The issue is not the vendor. The issue is the configuration pattern of allowing domains to bypass authentication without requiring them to pass it first.

Does this mean DMARC is useless?

No. DMARC p=reject is still the most important step most organizations can take for email authentication. It works correctly for the vast majority of inbound mail. The safe-sender gap is a specific, addressable configuration issue, not a flaw in DMARC itself. The answer is to audit your gateway exceptions, not to deprioritize DMARC.

What does DMARCFlow actually do in this scenario?

DMARCFlow processes your aggregate reports and shows you what your MTA border saw. It cannot see inside your email gateway, so it cannot confirm whether your gateway overrode an authentication result. What it does show is the aggregate data: your pass rates, your failed authentication volume, and anomalies that might indicate an attack or a configuration change. Use DMARCFlow for the border visibility. Use your gateway logs for the internal override visibility. Together they give you a complete picture.

Summary

Your DMARC p=reject policy is working. It is doing exactly what it is supposed to do at the MTA border.

The gap is in your email gateway, where safe-sender lists, transport rules, and domain exceptions can override the authentication result after DMARC has finished. The override is often intentional -- it solves a real problem of legitimate mail landing in junk -- but it creates a gap that attackers can exploit.

Audit your gateway allow-lists. Make domain exceptions conditional on authentication passing. Use DMARCFlow to monitor your aggregate authentication data for changes that might indicate a configuration problem or an attack in progress. The border is secure. The inside of your stack needs attention.