How Safe Sender Lists Bypass DMARC p=reject Enforcement

The short answer

Yes. When a domain appears in your email gateway's safe sender list or a transport rule exclusion, the gateway can skip DMARC enforcement for that domain entirely. SPF fails, DKIM fails, DMARC fails against a published p=reject policy -- and the message still lands in the inbox because the allow-list outranked the authentication result. This is not a bug. It is a configuration trade-off that made sense when the downside was a partner invoice in junk, and is a worse one now that vendor breaches expose customer allow-lists publicly.

The Greatness phishing campaign in 2024 demonstrated exactly this gap. Attackers sent spoofed RingCentral notifications to an organization that had the RingCentral domain in its safe sender configuration. Authentication failed across the board -- SPF fail, no DKIM signature, DMARC fail against p=reject -- yet all four messages were delivered with SCL -1, which skips the entire filtering pipeline. The phishing kit was not sophisticated. The attack worked because no one had noticed that the safe sender entry nullified the DMARC policy.

Why safe sender lists bypass DMARC

Most enterprise email gateways assign a Spam Confidence Level (SCL) to each incoming message. When a sender domain appears in a safe sender list or transport rule exclusion, the gateway assigns SCL -1, which marks the message safe and skips the remaining filtering pipeline -- including DMARC policy enforcement.

The logic behind this is operational: organizations rely on receiving legitimate email from vendors, partners, and cloud services that may not have perfect email authentication. A domain that passes SPF, DKIM, and DMARC alignment is ideal, but the reality is that many legitimate senders still fail one or more of those checks. Safe sender lists were added as a safety valve: when in doubt, allow the message through rather than risk blocking something important.

The problem is that this safety valve also applies to spoofed messages. If an attacker spoofs a domain that appears in your safe sender list, the authentication checks never apply. The gateway sees the safe sender flag, skips DMARC, and delivers the message. The attacker does not need to compromise SPF, DKIM, or DMARC alignment. They just need to use a domain you have already decided to trust unconditionally.

The Greatness case makes this concrete: the attackers used a domain with no connection to RingCentral's mail infrastructure. They did not need to hack RingCentral's SPF or DKIM. They just sent from infrastructure that happened to share a domain the target organization had marked as safe. The allow-list was the vulnerability.

Why this matters more now than it did five years ago

Safe sender lists and transport rule exclusions were designed in an era when the main risk from over-trusting a domain was a misdelivered invoice or a few spam messages in an executive's inbox. The operational cost of blocking a legitimate vendor email was higher than the cost of allowing occasional spoofed mail through.

That trade-off has aged badly. Vendor breaches now routinely expose customer contact databases and internal email lists. An attacker who steals a list of your vendors, partners, and internal systems has a ready-made list of domains to spoof -- and if any of those domains appear unconditionally in your safe sender list, your gateway will deliver the spoofed messages without any authentication check.

The same logic applies to transport rule exclusions in Exchange Online and similar platforms. IT teams add domains to transport rule allow-lists to work around deliverability issues, not realizing that the exclusion also bypasses DMARC enforcement for those domains.

How to audit your gateway allow-list

The practical question is not whether this gap exists in your gateway -- most enterprise gateways create it by default. The question is which domains in your allow-lists are also publishing strict DMARC policies, because that combination is the specific risk. A domain that allows unconditional inbound delivery AND publishes p=reject is actively contradictory: you are telling the world you reject unauthenticated mail from your domain while simultaneously instructing your gateway to accept unauthenticated mail claiming to be from your domain.

Here is a process for finding the problematic entries:

Step 1: List your unconditional allow-list entries.

Export or document every domain in your gateway safe sender list and every transport rule that applies to specific sender domains. For each entry, note whether it includes an authentication requirement. If the entry does not say "require SPF pass" or "require DKIM pass," treat it as unconditional.

Step 2: Cross-reference against your DMARC published policies.

For each unconditional entry, check whether that domain publishes a DMARC record. Domains that publish p=reject or p=quarantine AND appear unconditionally in your allow-list are the highest priority to fix. The mismatch between your published policy and your gateway configuration is where the risk lives.

Tools like DMARCFlow are designed to surface this kind of configuration contradiction automatically. DMARCFlow's reporting cross-references your published DMARC policies against your gateway's authentication behavior, so you can identify in minutes which allow-listed domains are creating enforcement gaps rather than discovering it during a security review.

Step 3: Assess and convert.

For each unconditional entry, evaluate whether it can be converted to a conditional allow-listing. If the domain passes authentication checks from its legitimate sending infrastructure, require those checks as a condition of the allow-listing. If the domain genuinely cannot pass authentication -- for example, a legacy vendor system with no DKIM support -- document the business justification, set a review reminder, and consider whether a specific sending IP allow-list is a narrower alternative.

Step 4: Track changes over time.

Allow-lists tend to grow. A domain added to resolve a deliverability incident in 2021 may still be there in 2026, even if the original problem was fixed years ago. DMARCFlow monitoring helps catch new allow-list entries that conflict with your existing DMARC policy before they create new bypass paths.

What to do about it

The naive solution is to remove all safe sender entries. This is operationally unrealistic for most organizations -- vendor email will break, and the business cost is immediate and visible. A more practical approach involves two changes.

First, convert unconditional allow-list entries to conditional ones wherever your gateway supports that option. Require SPF pass or DKIM pass as a condition of the allow-listing, so that the safe sender flag only applies to messages that also pass authentication. This preserves the deliverability benefit while closing the bypass.

Second, treat safe sender entries as standing security decisions, not just deliverability fixes. Every unconditional entry is a standing instruction to ignore authentication for any message claiming to come from that domain. Review those entries quarterly, remove anything no longer needed, and document the business justification for what remains.

How DMARCFlow helps

DMARCFlow identifies configuration gaps between your published DMARC policies and your actual email gateway behavior. The bypass risk created by unconditional safe sender entries is exactly the kind of gap that DMARCFlow is built to surface: you know your domain publishes p=reject, but your gateway is still delivering unauthenticated messages from that domain because an allow-list entry overrides the policy enforcement.

During DMARC analysis, DMARCFlow can flag domains in your safe sender lists that also publish strict DMARC policies, making the contradiction visible. This turns a manual audit into something you can act on systematically, without manually cross-referencing gateway configuration exports against your DNS records.

FAQ

Can a safe sender list really override DMARC p=reject?

Yes. Most enterprise gateways evaluate safe sender lists before applying DMARC policy. If a domain appears in the safe sender list, the gateway may skip DMARC enforcement entirely for messages from that domain, regardless of what the DMARC record says.

What is the difference between a safe sender list and a transport rule exclusion?

A safe sender list is typically configured at the gateway level and affects how the gateway scores and routes incoming messages. A transport rule exclusion is configured in the mail server (for example, Exchange Online) and determines whether messages from a specific domain are processed by the rule in question. Both can bypass DMARC enforcement if configured to apply unconditionally.

Does SPF pass or DKIM pass override DMARC?

No. SPF pass and DKIM pass are individual authentication checks. DMARC alignment requires either SPF alignment or DKIM alignment, which means the domain used in the RFC5321 From address must match the domain that passed SPF or DKIM. A message can pass SPF and still fail DMARC if the From address domain does not match the SPF sending domain. Safe sender lists bypass the DMARC check entirely, not just the individual authentication mechanisms.

How do I check if my organization is affected?

Audit your gateway safe sender list and your mail transport rules for unconditional domain entries. The specific risk applies to any domain that is allow-listed without requiring authentication to pass. If your DMARC record publishes p=reject and a domain in your safe sender list could be spoofed, the bypass is active.

Is it safe to remove all safe sender entries?

Not without checking what they are protecting first. Some vendor domains may genuinely not support email authentication, and removing the safe sender entry without an alternative will cause legitimate email to be rejected or quarantined. The right process is to audit, convert to conditional allow-listing where possible, and escalate only the entries that cannot be secured by any means.