Introduction
When a secure email gateway sits in front of Microsoft 365, Exchange Online often evaluates authentication against the gateway's IP address instead of the original sender's. That produces artificial SPF and DMARC failures on legitimate mail, because the gateway — not the real sender — is the last hop Microsoft 365 sees. Microsoft's answer to this is Enhanced Filtering for Connectors (also called "skip listing"), a setting that tells Exchange Online to look past the gateway hops and evaluate authentication against the true originating source.
This article is the configuration companion to why DMARC fails behind a gateway. It explains what Enhanced Filtering does, when an MSP should enable it, how it interacts with DMARC and ARC, and the specific things to verify per client.
This is an orientation and planning guide, not a click-by-click walkthrough of the Microsoft admin UI — that UI changes, and Microsoft's own documentation is the authoritative source for the exact current steps. What this article gives you is the operational understanding to know what you're configuring and why.
Why this topic matters
A large share of the "DMARC is failing on legitimate mail" tickets in Microsoft 365 environments trace back to a gateway hiding the original sender IP. The client's DMARC record is correct, the sender's SPF is correct, and yet the aggregate reports show SPF failures and DMARC failures. The cause is architectural: Exchange Online is checking the gateway's IP against the sender's SPF record, and of course it doesn't match.
Enhanced Filtering for Connectors is the setting that resolves this class of problem. For an MSP managing Microsoft 365 clients with gateways in front, knowing when and how to apply it is core competency. Without it, the DMARC data for those clients is systematically misleading.
What Enhanced Filtering does
When mail arrives at Microsoft 365 through an inbound connector from a third-party gateway, Exchange Online normally treats the connector's source (the gateway) as the connecting host for authentication purposes. SPF is checked against the gateway IP; DMARC alignment is computed from there.
Enhanced Filtering for Connectors tells Exchange Online to "skip" the gateway's IP addresses when determining the true source of the message. Exchange Online then walks back through the Received headers to find the last IP before the gateway — the actual originating sender — and evaluates SPF, DKIM, and DMARC against that instead.
In effect:
“` Without Enhanced Filtering: Microsoft 365 evaluates auth against: gateway IP (203.0.113.20) → SPF fails (gateway not in sender's SPF record) → DMARC fails
With Enhanced Filtering (gateway IPs skip-listed): Microsoft 365 evaluates auth against: original sender IP (198.51.100.10) → SPF can pass (if the sender authorizes that IP) → DMARC can pass “`
The gateway still does its filtering job. Enhanced Filtering only changes which IP Exchange Online uses for its own authentication evaluation.
When an MSP should enable it
Enable Enhanced Filtering for Connectors when all of these are true for a client:
- Microsoft 365 / Exchange Online is the mail platform.
- A third-party secure email gateway (Proofpoint, Mimecast, INKY, Barracuda, or similar) sits in front of Microsoft 365 as the public MX.
- The gateway forwards mail into Microsoft 365 over an inbound connector.
- You are seeing (or expect) SPF/DMARC failures caused by Exchange Online evaluating the gateway IP instead of the original sender.
Do not enable it, or enable it carefully, when:
- Microsoft 365 is the direct MX (no gateway in front) — there's nothing to skip.
- The "gateway" is actually part of a more complex multi-hop path where the true source is ambiguous — test carefully first.
- You're not certain which IPs belong to the gateway — skip-listing the wrong IPs produces wrong results.
The core configuration decision: which IPs to skip
Enhanced Filtering works by skip-listing the gateway's IP addresses. Exchange Online skips those IPs when looking for the true source. This means the single most important input is: which IP addresses belong to the gateway?
Get this list from the gateway vendor. Proofpoint, Mimecast, INKY, and Barracuda all publish their sending IP ranges (the IPs their infrastructure uses to hand mail to your Microsoft 365 tenant). Those are the IPs you skip-list. Skip-listing too few means some gateway hops aren't skipped and authentication still evaluates wrong. Skip-listing too many (or the wrong ranges) means Exchange Online might skip past a legitimate hop and evaluate the wrong source.
There is also an option to apply Enhanced Filtering to all IPs on a connector versus a specific list. For a well-understood single-gateway setup, the specific-list approach is more precise. For simpler setups, the "skip all" option on the connector may be acceptable — but understand what it's doing before applying it.
How it interacts with DMARC
Enhanced Filtering is upstream of DMARC evaluation. By fixing which IP Exchange Online treats as the source, it fixes the input to the SPF check and therefore to DMARC alignment.
The typical before/after in the aggregate reports:
- Before: the client's DMARC reports show a large volume of SPF failures from the gateway's IP, and DMARC failures on mail that is actually legitimate. The reports are dominated by this artifact.
- After: SPF is evaluated against the real sender IP, legitimate mail passes SPF (assuming the sender's SPF is correct), and the DMARC reports become a much cleaner reflection of actual authentication posture.
This is why Enhanced Filtering matters for DMARC-management specifically: without it, the client's DMARC reports are polluted with gateway-induced failures that obscure the real signal. With it, the reports become trustworthy.
How it interacts with ARC
Enhanced Filtering and ARC solve related but distinct problems, and they work together:
- Enhanced Filtering fixes the SPF / IP problem — it makes Exchange Online evaluate the original sender IP instead of the gateway IP.
- ARC fixes the DKIM / message-modification problem — it preserves the authentication verdict from before the gateway modified the message.
A gateway can break authentication in both ways: by hiding the sender IP (SPF) and by modifying the message (DKIM). Enhanced Filtering addresses the first; ARC addresses the second. For a gateway that both hides the IP and modifies the message, you want both: Enhanced Filtering so SPF evaluates correctly, and a trusted ARC seal so the DKIM-modification case is covered. The ARC explainer covers the ARC side.
Verification: how to confirm it's working
After enabling Enhanced Filtering for a client, verify it actually changed the evaluation:
- Send a test message from a known external sender through the gateway into the client's Microsoft 365.
- Inspect the headers of the delivered message. The Email Header Analyzer parses the relevant fields. Look at the
Authentication-Resultsand the Microsoft-specificX-MS-Exchange-Organization-Authentication-Resultsheaders. - Confirm the evaluated IP is the original sender's, not the gateway's. Exchange Online's authentication headers should now reference the true source.
- Watch the aggregate reports over the following days. The volume of gateway-IP SPF failures should drop, and legitimate senders should start showing SPF pass.
If the headers still show the gateway IP being evaluated, the skip-list is incomplete or the connector isn't matching — revisit the gateway IP ranges.
Per-client checklist
For each Microsoft 365 client with a gateway in front, an MSP should confirm:
- Is there actually a gateway in front? Confirm the public MX points at the gateway, not directly at Microsoft 365.
- Which gateway, and what are its IP ranges? Get the authoritative IP list from the vendor.
- Is there an inbound connector from the gateway into Microsoft 365? Enhanced Filtering applies to that connector.
- Is Enhanced Filtering enabled on that connector with the correct skip-list?
- Does a test message now evaluate against the original sender IP?
- Are the aggregate reports showing cleaner SPF results after the change?
- Is ARC also needed? If the gateway modifies messages (link rewriting, banners), pair Enhanced Filtering with trusted ARC sealing.
- Is the change documented in the client runbook, including the gateway IP ranges and the date enabled?
Common mistakes
Skip-listing the wrong IPs. Using stale or incomplete gateway IP ranges means some hops aren't skipped and the fix is partial. Always get current ranges from the vendor.
Enabling it without a gateway. If Microsoft 365 is the direct MX, there's nothing to skip and Enhanced Filtering does nothing useful — and if the connector matching is wrong, it can misbehave.
Expecting it to fix DKIM. Enhanced Filtering fixes the IP/SPF problem. If the gateway is breaking DKIM by modifying the message, Enhanced Filtering alone won't fix DMARC — you also need ARC (or you need the gateway to stop modifying signed content before authentication is preserved).
Not verifying. Enabling the setting and assuming it worked. Always confirm with a test message and header inspection.
Not documenting. The gateway IP ranges change over time. If the skip-list isn't documented in the runbook, the next analyst won't know what was configured or why mail started failing again when the vendor changed ranges.
Why this is an MSP competency
For an MSP managing DMARC across Microsoft 365 clients, Enhanced Filtering for Connectors is one of the highest-leverage configuration items. A single correct application cleans up an entire client's DMARC reporting, turning a stream of confusing gateway-induced failures into a trustworthy authentication signal. Getting it wrong — or not knowing it exists — leaves the client's DMARC data permanently misleading, which undermines the whole value of the DMARC engagement.
This is exactly the kind of mail-flow-aware configuration work that distinguishes an MSP that manages DMARC from a platform that only reports on it. The report shows the symptom; fixing the connector configuration resolves the cause.
How DMARC AI helps
A context-aware DMARC platform should recognize the gateway-induced failure pattern — a high volume of SPF failures from a single gateway IP range across otherwise-legitimate mail — and flag it as an Enhanced-Filtering candidate rather than a sender misconfiguration. That saves the analyst from mistaking an architecture problem for a DMARC problem, and points directly at the connector-configuration fix. For MSPs, that's the difference between spending an hour puzzling over reports and spending ten minutes applying a known fix.
Related articles
- Why DMARC fails with a gateway in front of Microsoft 365
- ARC (Authenticated Received Chain) explained
- Why DMARC reports say reject but the email was delivered
- How to read email headers — an MSP triage guide
- DMARC alignment explained
Tools mentioned
- Email Header Analyzer — confirm which IP Exchange Online evaluated after enabling Enhanced Filtering
- DNS Lookup — verify the client's SPF record and MX configuration
- DMARC Checker — verify the published policy
Author: DMARC AI editorial team Last updated: July 2026