Why DMARC Reports Say “Reject” but the Email Was Delivered

Reporting

Introduction

One of the most confusing situations an MSP encounters when managing DMARC is this: the aggregate report says a message was rejected, the receiving domain publishes a p=reject policy, and yet the user still received the email. At first glance this looks impossible. If DMARC failed and the policy is reject, how did the message land in the inbox?

The short answer is that a DMARC report tells you what the authentication evaluation concluded and what policy the domain owner requested — not necessarily what the receiving mail system ultimately decided to do with the message. Those are two different things, and the gap between them is where "reject but delivered" lives.

This article is the report-interpretation companion to why DMARC fails behind a gateway. It explains the several distinct reasons a message can show a reject disposition and still be delivered, and what MSPs should do about it.

Why this topic matters

If you interpret DMARC aggregate reports as a perfect log of mailbox delivery, you will draw wrong conclusions. You'll think enforcement is working when it isn't, or panic that legitimate mail is being blocked when it's being delivered fine. Either error erodes the client's trust in the DMARC program.

Understanding the reject-but-delivered pattern lets an MSP interpret reports as what they actually are — authentication intelligence about what receivers observed and what the domain owner requested — rather than as a delivery ledger. That distinction is the difference between an MSP that explains DMARC data correctly and one that misreads it.

First: what a DMARC report actually records

A DMARC aggregate report is an XML summary a receiver sends back to the domain owner. For each group of messages from a given sending source, it records:

• the sending IP,
• the SPF result and whether it aligned,
• the DKIM result and whether it aligned,
• the resulting DMARC evaluation (pass / fail),
• the disposition — the policy action the receiver applied or recommended (none / quarantine / reject).

That disposition field is the source of the confusion. It reflects the policy evaluation. It does not always reflect the final mailbox placement. A receiver can record a disposition of reject in the report while its actual mail-handling pipeline delivers the message for reasons that operate outside the DMARC evaluation.

Reason 1: the report reflects policy evaluation, not final placement

DMARC reports show the policy disposition that was applied or recommended during authentication evaluation. But the final delivery decision may still be influenced by local policy, gateway behavior, allow lists, tenant configuration, or the receiving platform's security settings.

So a report may indicate that DMARC failed and that the published policy was reject, while the receiving environment still decides to deliver, quarantine, rewrite, or route the message based on other rules that run after — or alongside — the DMARC check.

The disposition is the DMARC engine's verdict. The mailbox placement is the whole mail system's verdict. They are not the same field, and they don't have to agree.

Reason 2: the gateway accepted the message before Microsoft 365 evaluated it

If a secure email gateway is the public MX receiver for the domain, the gateway accepts the message first — before Microsoft 365 (or Google Workspace) ever sees it. After the gateway accepts and scans the message, it forwards the message into the mail platform over an internal connector.

At that point, the mail platform is not handling the same SMTP transaction as the public-internet sender. The message has already been accepted by the gateway. The final mailbox delivery therefore depends on gateway-to-platform routing, connector trust, allow lists, or internal transport rules — not solely on the DMARC verdict the platform computes.

This is a very common cause of reject-but-delivered in environments with Proofpoint, Mimecast, INKY, Barracuda, or similar gateways in front of Microsoft 365. The DMARC report (generated from the platform's evaluation) says reject; the delivery (governed by the gateway-to-platform trust relationship) succeeds. The gateway-and-Microsoft-365 article covers this architecture in depth.

Reason 3: local policy can override DMARC enforcement

Receiving systems are not obligated to apply the sender's DMARC policy exactly as published. DMARC tells receivers what the domain owner requests; receivers are free to apply local policy on top of that request.

A receiver may decide to deliver a message despite a DMARC failure because:

• the sender is on an allow list;
• the gateway already scanned the message and cleared it;
• the message arrived through a trusted connector;
• the tenant has custom mail-flow / transport rules;
• a separate security product made its own verdict that overrides DMARC;
• ARC results from a trusted sealer were honored;
• the platform's threat-confidence scoring treated the message as safe.

Every one of these is a legitimate reason a receiver might deliver mail that failed DMARC. The domain owner's p=reject is a request, not a command. This is why DMARC reports should be read as authentication intelligence, not as a guaranteed delivery outcome.

Reason 4: connector configuration changes authentication behavior

When Microsoft 365 receives mail through a third-party gateway, connector configuration matters a great deal. Microsoft's Enhanced Filtering for Connectors is specifically intended for scenarios where a third-party filtering service or device sits in front of Microsoft 365. It helps preserve the source IP and sender information so that SPF, DKIM, and DMARC can be evaluated against the original sender rather than the gateway hop.

If Enhanced Filtering is not configured correctly, Microsoft 365 may evaluate authentication based on the gateway hop instead of the original sender — which produces artificial DMARC failures in the report while the mail is delivered normally through the trusted connector. The Enhanced Filtering guide covers the setup that resolves this.

Putting it together: the classic pattern

Here is the full pattern as it appears in a real environment with a gateway in front of Microsoft 365:

“` SPF result in Microsoft 365: fail (Microsoft 365 sees the gateway IP, not the original sender IP)

DKIM result in Microsoft 365: fail (the gateway modified signed parts of the message)

DMARC result: fail (neither aligned SPF nor aligned DKIM passed)

DMARC report disposition: reject (the sender domain publishes p=reject)

Final delivery: delivered (local policy, connector trust, ARC, gateway decision, allow list, or security-platform behavior) “`

Every line is internally consistent. The message failed DMARC, the policy is reject, the report faithfully records that — and the mail system still delivered the message because the delivery decision was governed by the gateway-to-platform trust relationship, not by the raw DMARC verdict.

Is reject-but-delivered a problem?

It depends on which direction it's happening.

Legitimate mail, reject-but-delivered. This is usually fine — even good. The mail is legitimate, the DMARC failure is an artifact of the gateway modifying the message or hiding the sender IP, and the mail system correctly delivered it via the trusted connector. The action here is to understand why it's failing DMARC (so you can fix the upstream cause with ARC or Enhanced Filtering) but not to panic that mail is being blocked — it isn't.

Spoofed mail, reject-but-delivered. This is a real problem. If a spoofed message failed DMARC, the policy is p=reject, and it was still delivered, then the enforcement the client believes they have is not actually protecting them. The delivery happened because of an allow list, a misconfigured connector, or an over-trusting local policy — and an attacker's spoofed mail slipped through. This is the dangerous case: the client thinks p=reject is protecting them, but a local override is quietly delivering mail that should be blocked.

Telling the two apart requires looking at the actual message, not just the report. Is the sender a legitimate service being mangled by a gateway, or an actual impersonation attempt getting through a local override? The Email Header Analyzer and full mail-path analysis answer that.

Why this matters for MSPs

Three specific risks make this pattern important for MSP practices:

It can create false panic. A client sees DMARC failures with a reject disposition and assumes their domain is misconfigured or under attack, when the real cause is a third-party gateway or forwarding chain mangling legitimate mail.

It can hide real risk. If spoofed messages that should be rejected are being delivered due to a local override, the client believes their DMARC enforcement is stronger than it actually is. The report shows reject; the attacker's mail lands anyway.

It complicates troubleshooting. Without full header analysis and mail-path visibility, it's genuinely hard to know whether a given reject-but-delivered instance is benign (legitimate mail through a gateway) or dangerous (spoofed mail through an override).

What to check

When you see reject-but-delivered, don't stop at the aggregate report. Investigate:

1. Was a gateway the public MX receiver, accepting the message before the mail platform saw it?
2. Did the mail platform see the original sender IP, or only the gateway IP?
3. Is Enhanced Filtering for Connectors enabled (for Microsoft 365)?
4. Is the sender on an allow list or arriving through a trusted connector?
5. Are there custom transport rules that override DMARC?
6. Is ARC present, and is the chain valid (cv=pass)?
7. Is the delivered message actually legitimate, or is it a spoof that slipped through?
8. Does the client's understanding of their enforcement match what's actually happening?

The last question is the one that matters most. If the client believes p=reject blocks all spoofing but a local override is quietly delivering some of it, that gap needs to be surfaced and closed.

How DMARC AI helps

Interpreting reject-but-delivered correctly is exactly the kind of context work a good DMARC platform should assist with. Instead of showing a raw disposition, a context-aware platform helps answer: Is this a legitimate sender being broken by a gateway, or a spoof getting through an override? Was the message modified in transit? Is ARC involved? Does the client need a connector or allow-list change? Should this be escalated as a real enforcement gap or explained away as a benign gateway artifact?

For MSPs, this is the difference between handing a client a confusing XML report and telling them clearly: "This is legitimate mail your gateway is mangling — here's the fix," or "This is a spoof slipping through an allow list — here's the gap we need to close."

Related articles

• Why DMARC fails with a gateway in front of Microsoft 365
• ARC (Authenticated Received Chain) explained
• Microsoft 365 Enhanced Filtering for Connectors
• Reading DMARC aggregate reports
• How to read email headers — an MSP triage guide

Tools mentioned

• Email Header Analyzer — determine whether a delivered message is legitimate or spoofed
• DMARC Checker — verify the published policy the report references

Author: DMARC AI editorial team Last updated: July 2026