Introduction
Many organizations use a secure email gateway in front of Microsoft 365. This can be a cloud gateway such as Proofpoint, INKY, Mimecast, Barracuda, or another filtering layer that receives inbound email before it reaches Exchange Online.
From a security-architecture point of view, this setup is common. The gateway scans messages for phishing, malware, spam, impersonation, and other threats before delivering the email to Microsoft 365.
But for DMARC, SPF, and DKIM validation, this setup can create confusion. In some cases, Microsoft 365 no longer sees the original sender IP address — it sees the IP address of the email gateway. In other cases, the gateway also modifies the message body, headers, subject line, links, or attachments. As a result, SPF, DKIM, and therefore DMARC may fail — even though the original email may have passed authentication before it reached the gateway.
This article is the mail-flow companion to the DMARC for MSPs pillar. It explains why this happens, why DMARC reports can sometimes show "rejected" emails that were still delivered, and how ARC can help preserve authentication results across email gateways.
The typical mail flow
A standard inbound Microsoft 365 mail flow looks like this:
“ Sender mail server ↓ Microsoft 365 / Exchange Online Protection ↓ User mailbox “
In this scenario, Microsoft 365 can usually see the connecting sender IP address directly. That makes SPF validation more straightforward — if the sender's SPF record authorizes the sending IP, SPF can pass.
Many organizations, however, use a third-party email gateway in front of Microsoft 365:
“ Sender mail server ↓ Secure email gateway ↓ Microsoft 365 ↓ User mailbox “
In this second scenario, Microsoft 365 may only see the gateway as the connecting sender. That changes how SPF and DMARC are evaluated. Microsoft documents this scenario and recommends Enhanced Filtering for Connectors when third-party filtering services sit in front of Microsoft 365, so that Exchange Online can better evaluate the original source of the message instead of only the last filtering hop.
Why SPF often fails behind an email gateway
SPF checks whether the connecting IP address is authorized to send email for the domain used in the envelope sender. That means SPF depends heavily on the IP address of the system that delivers the message to the receiving mail server.
When a gateway sits in front of Microsoft 365, the final hop into Microsoft 365 is often the gateway. Microsoft 365 may therefore evaluate the gateway IP instead of the original sender IP.
Example:
“ Original sender IP: 198.51.100.10 Gateway IP: 203.0.113.20 Microsoft 365 sees: 203.0.113.20 “
If the sender's SPF record authorizes 198.51.100.10 but not 203.0.113.20, SPF may fail when Microsoft 365 performs the check.
This does not always mean the sender configured SPF incorrectly. It may simply mean the receiving architecture hides the original sender IP.
Why DKIM can fail after gateway processing
DKIM is different from SPF. It does not rely on the sending IP address. Instead, DKIM uses a cryptographic signature added by the sending domain. The receiving system checks whether the signed parts of the email still match the original signature.
That means DKIM can survive forwarding or gateway routing — but only if the signed content is not modified in a way that breaks the signature.
A gateway may break DKIM when it modifies the email body, certain headers, URLs inside the message, attachments, the subject line, disclaimers or banners, link rewriting, security-warning banners, or tracking / inspection elements.
For example, if a gateway rewrites links for click protection or adds a warning banner to the body, the DKIM signature may no longer validate. If DKIM fails and SPF also fails or is not aligned, DMARC will fail.
Why DMARC fails in this scenario
DMARC passes when at least one of these authentication paths passes and aligns with the visible From: domain:
“ SPF pass + SPF alignment or DKIM pass + DKIM alignment “
If a gateway hides the original sender IP, SPF may fail. If the gateway modifies the message, DKIM may fail. If both fail, DMARC fails.
The frustrating part is that the message may have been perfectly legitimate before the gateway touched it. The failure can be caused by the receiving infrastructure rather than by the sending domain. This is why MSPs and security teams should be careful when interpreting DMARC failures involving mail gateways, forwarding services, or filtering layers.
The role of ARC
ARC stands for Authenticated Received Chain. It is designed to preserve authentication results across intermediaries such as forwarding services, mailing lists, and email gateways. In simple terms, ARC allows a trusted intermediary to say:
“ When I received this message, SPF/DKIM/DMARC had these results. I am sealing those results so the next receiver can evaluate them. “
This is especially useful when a gateway modifies the email before passing it on. Without ARC, Microsoft 365 may only evaluate the modified message and the gateway IP. With ARC, Microsoft 365 can take into account the authentication results observed earlier in the chain, assuming the ARC seal is trusted and valid.
ARC does not magically make every failed DMARC result safe. It gives the receiving system more context. The receiving platform still needs to decide whether it trusts the ARC sealer and whether the message should be delivered, quarantined, or rejected. Proofpoint and other gateways recommend enabling ARC where supported to preserve authentication through intermediaries. The ARC explainer article covers the mechanism in depth.
Why DMARC reports may say "reject" even when the email was delivered
One confusing situation that shows up in real environments is this: the DMARC aggregate report says the message was rejected, the receiving domain has a p=reject policy, but the user still received the email. At first glance this looks impossible. If the message was rejected, how was it delivered? There are several possible explanations.
1. The report reflects policy evaluation, not always final mailbox placement
DMARC reports can 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 Microsoft 365 security settings. So a report may indicate that DMARC failed and the published policy was reject, while the receiving environment still decides to deliver, quarantine, rewrite, or route the message based on other rules.
2. The gateway accepted the message before Microsoft 365 evaluated it
If the gateway is the MX receiver, the gateway may accept the message first. After that, the gateway forwards it into Microsoft 365. At that point, Microsoft 365 is not necessarily handling the same SMTP transaction as the public-internet sender — the email has already been accepted by the gateway. The final mailbox delivery may therefore depend on gateway-to-Microsoft-365 routing, connector trust, allow lists, or internal transport rules.
3. Local policy can override DMARC enforcement
Receiving systems are not forced to apply the sender's DMARC policy exactly as published. DMARC tells receivers what the domain owner requests, but receivers can apply local policy. A receiver may decide to deliver a message despite a DMARC failure because the sender is allow-listed, the gateway already scanned the message, the message came through a trusted connector, the tenant has custom mail-flow rules, a security product made its own verdict, ARC results were trusted, or the platform treats the message differently based on threat confidence. This is one of the reasons DMARC reports should be interpreted as authentication intelligence, not as a perfect mailbox-delivery log. The reject-but-delivered article covers this case in more detail.
4. Microsoft 365 connector configuration can change authentication behavior
When Microsoft 365 receives mail through a third-party gateway, connector configuration matters a lot. Microsoft's Enhanced Filtering for Connectors is specifically intended for scenarios where a third-party filtering service or device is in front of Microsoft 365. It helps preserve source IP and sender information so that SPF, DKIM, and DMARC can be evaluated more accurately. If this is not configured correctly, Microsoft 365 may evaluate authentication based on the gateway hop instead of the original sender. The Enhanced Filtering guide walks the setup.
Example scenario: Proofpoint or INKY in front of Microsoft 365
A simplified example:
“ example-sender.com sends email ↓ Proofpoint / INKY receives and scans the message ↓ Gateway rewrites links or adds security headers ↓ Gateway forwards message to Microsoft 365 ↓ Microsoft 365 evaluates authentication ↓ User receives the email “
Possible results:
“` SPF result in Microsoft 365: fail Reason: Microsoft 365 sees the gateway IP, not the original sender IP.
DKIM result in Microsoft 365: fail Reason: the gateway modified signed parts of the message.
DMARC result: fail Reason: neither aligned SPF nor aligned DKIM passed.
DMARC report disposition: reject Reason: sender domain publishes p=reject.
Final delivery: delivered Reason: local policy, connector trust, ARC, gateway decision, allow list, or security-platform behavior. “`
This is why DMARC data can look contradictory unless you understand the full mail path.
Why this matters for MSPs
For MSPs managing DMARC across many client domains, this scenario is important for three reasons.
First, it can create false panic. A client may see DMARC failures and assume their domain is misconfigured, while the real issue is caused by a third-party gateway or forwarding chain.
Second, it can hide real risk. If messages that should be rejected are still delivered, the client may believe DMARC enforcement is stronger than it actually is.
Third, it complicates troubleshooting. Without full header analysis and visibility into the mail path, it is difficult to know whether the problem is caused by the sender, the receiver, the gateway, forwarding, DKIM modification, or connector configuration.
What to check when DMARC fails behind a gateway
When you see this pattern, do not only look at the DMARC aggregate report. Check the full message headers and the mail flow. Useful questions:
- What system received the email first?
- Was the gateway the public MX receiver?
- Did Microsoft 365 see the original sender IP or only the gateway IP?
- Was Enhanced Filtering for Connectors enabled?
- Did SPF fail because the gateway IP was evaluated?
- Did DKIM fail because the message was modified?
- Are ARC headers present?
- Is the ARC seal valid?
- Is the ARC sealer trusted by the receiving system?
- Are there allow lists, transport rules, or trusted connectors?
- Did the gateway rewrite URLs, add banners, or modify attachments?
- Does the DMARC report reflect final delivery or only policy disposition?
Headers to inspect
When troubleshooting, look for these headers. The Email Header Analyzer parses all of them automatically.
“ Authentication-Results: “
Shows SPF, DKIM, and DMARC results as evaluated by the receiving system.
“ Received: “
These headers show the message path and can help identify which system handed the message to Microsoft 365.
“ ARC-Seal: ARC-Message-Signature: ARC-Authentication-Results: “
These indicate whether ARC is present and whether previous authentication results were preserved.
“ DKIM-Signature: “
Shows whether the sender signed the email and which headers / body parts were included.
“ X-MS-Exchange-Organization-Authentication-Results: “
In Microsoft 365 environments, Microsoft-specific authentication headers can provide additional detail about how Exchange Online evaluated the message.
Recommended configuration approach
For organizations using a gateway in front of Microsoft 365, the goal is not simply to "make DMARC pass." The goal is to preserve reliable authentication context. Recommended steps:
- Make sure the gateway validates SPF, DKIM, and DMARC before modifying the message.
- Enable ARC sealing on the gateway where supported.
- Configure Microsoft 365 to trust the appropriate ARC sealer only when justified.
- Use Enhanced Filtering for Connectors so Microsoft 365 can better evaluate the original sender IP.
- Avoid unnecessary message modifications before authentication results are preserved.
- Review URL rewriting, disclaimers, and banners that may break DKIM.
- Check whether custom transport rules or allow lists override DMARC decisions.
- Compare DMARC aggregate reports with actual message headers.
- Monitor whether messages marked as rejected are actually delivered.
- Document the inbound mail flow per client.
Important note: ARC is not a free pass
ARC should not be treated as a universal bypass for DMARC failures. A malicious or poorly configured intermediary can also create confusing results. ARC only helps when the intermediary is trusted, the ARC seal is valid, the original authentication results were captured correctly, the receiving system knows how to evaluate ARC, and local policy is configured safely. ARC adds context. It does not replace SPF, DKIM, or DMARC.
How DMARC AI helps
DMARC AI helps MSPs and security teams interpret DMARC results in context. Instead of only showing that SPF, DKIM, or DMARC failed, a context-aware DMARC platform should help answer: Is this a real sender issue or a forwarding / gateway issue? Did the message pass before being modified? Is the source an authorized service? Is the failure caused by SPF, DKIM, alignment, or intermediary handling? Are emails being reported as rejected while still being delivered? Does the customer need Microsoft 365 connector changes? Is ARC present and working? Should this source be fixed, ignored, investigated, or escalated?
For MSPs, this matters because clients do not just need raw DMARC reports. They need to know what to do next.
Final thoughts
When an email gateway sits in front of Microsoft 365, DMARC results can become difficult to interpret. SPF may fail because Microsoft 365 sees the gateway IP instead of the original sender IP. DKIM may fail because the gateway modifies the message. DMARC may fail because neither aligned SPF nor aligned DKIM survives the gateway path. At the same time, DMARC reports may show a reject disposition while the message is still delivered due to local policy, connector configuration, gateway behavior, ARC, or allow lists.
This is not always a sender-side DMARC problem. Often it is a mail-flow visibility problem. The right solution is to understand the full route of the message, preserve authentication results with ARC where possible, configure Microsoft 365 connectors correctly, and interpret DMARC reports together with real message headers.
For MSPs, this is exactly where DMARC management becomes valuable: not just collecting reports, but explaining what happened, why it happened, and what should be fixed.
Related articles
- ARC (Authenticated Received Chain) explained
- Why DMARC reports say reject but the email was delivered
- Microsoft 365 Enhanced Filtering for Connectors
- How to read email headers — an MSP triage guide
- DMARC alignment explained
Tools mentioned
- Email Header Analyzer — parse the Received chain, Authentication-Results, ARC headers, and DKIM signatures
- DMARC Checker — verify the published policy
- DNS Lookup — inspect SPF, DKIM, DMARC records across resolvers
Author: DMARC AI editorial team Last updated: July 2026