Why Your DMARC p=reject Policy Is Not Blocking Phishing Emails (And What Is)

The scenario

Your organization has published DMARC p=reject for two years. Aggregate reports show external domains consistently failing authentication. You have a strict policy. Then a phishing email arrives in a user's inbox, sent from an address that is clearly not yours. You check the headers. SPF, DKIM, and DMARC all show pass. How did it get through? The answer is almost always a safe-sender list, transport rule, or gateway allow-list that outranks your DMARC policy at the receiving server. Your DMARC configuration was not the problem. The receiving server never evaluated it.

How policy evaluation order actually works

Receiving mail servers evaluate checks in sequence. The order matters and is poorly understood. Most enterprise email systems process incoming mail roughly like this: 1. Connection filtering - IP reputation, RBL checks 2. SPF verification 3. DKIM verification 4. DMARC policy evaluation 5. Transport rules and safe-sender lists 6. Malware and content scanning The critical point: steps 5 and 6 happen after DMARC in most configurations. If a transport rule or safe-sender list matches the sender or domain, the message is routed to the inbox before DMARC findings are acted on. DMARC evaluated the message and said reject. The rule said deliver. The rule won. This is not a DMARC bug. It is a consequence of how enterprise email systems evolved. Safe sender lists predate modern email authentication. Transport rules were built for business workflow, not security policy. Adding DMARC did not automatically outrank those existing configurations.

Reading mail headers to find out what happened

When a message arrives despite a DMARC failure, check which check actually allowed it through. In Microsoft 365, these header fields are the ones to look at:

• Authentication-Results: shows SPF, DKIM, and DMARC results from the receiving server
• X-MS-Exchange-MessageSentRepresentingType: shows whether a transport rule identified the sender as internal or external
• X-MS-Exchange-SkipListed: indicates the message was placed on an internal allow-list

If you see DMARC pass in Authentication-Results but the message looks suspicious, either the sending domain has valid authentication or a transport rule routed the message without re-evaluating authentication after the rule fired. In Gmail, look for ARC-Message-Validation in addition to Authentication-Results. If ARC passes but the From address is spoofed, that is a strong indicator that a rule or allow-list overrode normal delivery. The pattern to watch for: Authentication-Results shows pass or none, but a transport rule or skip-list indicator is also present. That combination means the message was routed by policy, not by authentication outcome.

Auditing your Microsoft 365 environment

Transport rules In Exchange Admin Center, go to Mail flow > Rules. Look for rules that:

• Use the condition "The sender is internal" or match your own domain
• Include exceptions for specific senders or domains
• Have actions like "Route the message to a different destination" or "Set the spam confidence level"

Any rule that routes mail based on sender address without checking authentication results is a potential DMARC bypass. To check a rule for authentication awareness: add a condition that exceptions should fire only when SPF, DKIM, or DMARC fails. If you cannot add that condition, the rule is not authentication-aware and may be bypassing your DMARC policy. Safe sender lists In the EAC, go to Mail flow > Rules and check for rules that add senders to the Safe Senders list. In Outlook desktop, check the Junk Email Filter settings under File > Options > Mail > Junk. Organization-wide safe sender configurations are set in the EAC, not individual mailboxes. IP allow lists In the anti-spam policy (Security > Email & collaboration > Anti-spam), check IP Allow Lists. Any IP on the allow list bypasses SPF, DKIM, and DMARC evaluation entirely for messages from that IP. Tenant allow/block list In Microsoft 365 Defender, go to Settings > Email & Collaboration > Tenant allow/block lists. Entries here override standard filtering. If a domain is on this list, authentication checks do not run for messages from that domain.

Auditing common email security gateways

Proofpoint: Go to Policy > Inbound Policies. Look for policies with "Safe Sender" or "Allow From" conditions. In the message log, filter for messages that passed authentication but were flagged or held. If a policy shows "bypass" for a sender, that is your bypass. Mimecast: Go to Administration > Gateway > Policies. Mimecast calls its allow-lists "Allowlist Senders." Any sender on that list skips authentication checks. Mimecast also has "Held for Review" queues where messages flagged by DMARC may be released by analyst override. Check the release history for patterns. Cisco ESA: Use the web interface at Mail Policies > IronPort Anti-Spam. Look for sender-based allow entries. From the CLI, run sh status and check for any bypass configurations. The ESA also has antispam and content过滤器 policies that may include domain-level exceptions. The pattern across all platforms is the same: any configuration that matches a sender or domain and delivers the message without running authentication checks, or that runs checks but overrides the result with an allow action.

The attacker's perspective

Attackers know about these configurations. Many organizations have a standing rule: mail from our own domain is always safe. That rule may be a transport rule in Microsoft 365, a safe sender entry in Proofpoint, or a domain-based exception in your email gateway. When an attacker spoofs your domain and sends to a user inside your organization, they are relying on that rule. The message does not need to pass SPF, DKIM, or DMARC if the receiving server is configured to route internal-domain mail without checking authentication. This is a documented technique in credential phishing campaigns. The attacker sends from attacker.com with the From header set to include your own domain. The rule matches the From header and delivers the message. Your DMARC policy never gets a chance to act. This is why DMARC aggregate reports do not catch this attack vector. The aggregate report shows what your domain is sending. It does not show what your users are receiving through a bypass. You cannot see the bypass from the sending side.

What to do about it

Remediation The cleanest fix is to remove the allow-list entry or modify the transport rule to require a passing authentication result. In Microsoft 365 transport rules, add an exception: do not apply this rule if SPF, DKIM, or DMARC fails. The rule then fires only for legitimately authenticated mail. For safe sender lists, find the root cause of why the entry was created. Safe sender entries are usually added because legitimate mail was not delivering. The right fix is to fix the sending domain's authentication, not to allow-list the symptom. Risk acceptance Some exclusions exist for a reason. A vendor may need to send as your domain from an IP that cannot pass your DMARC alignment. A critical internal system may route mail in a way that breaks authentication. Removing the exclusion may break something more important than the security gain. If you accept the risk, document it. Record the exclusion, the reason, the business impact of removing it, and the date it was reviewed. Set a reminder to re-evaluate every six months. Organizations that accept risk without documentation tend to forget the risk exists. Monitoring the residual risk If you keep the exclusion, you need visibility at the sending side. The receiving server's configuration is opaque to you, but you can verify your own DMARC record is correctly published and that aggregate reports show only expected authentication results for your domains. This is where DMARCFlow fits. It checks your DMARC record for correct publication and monitors aggregate report data for your sending domains. When you accept a bypass risk, you still need to know whether your record is working correctly for all the paths you cannot control.

Why this keeps happening

Email authentication and enterprise email security were built by different teams at different times for different reasons. Authentication was designed to prove that a message actually came from the domain it claims. Enterprise email platforms were designed to let business mail flow, and they accumulated rules and exceptions over years of operational pressure. DMARC sits on top of that accumulated configuration. It does not replace it. When a safe sender list says deliver and your DMARC policy says reject, the safe sender list usually wins unless someone has explicitly configured the policy evaluation order to prioritize authentication results. The organizations that have solved this did two things. They audited their email platform configurations and removed or secured every allow-list entry that bypassed authentication. And they set up monitoring to catch new entries before they become a problem. If you are starting from scratch, the audit is the hard part. Most organizations do not know how many transport rules they have, who created them, or why. The answer is almost certainly more than you think, and at least one of them is doing something you did not intend.