enhanced filtering for connectors skips spf checks and spoofed partner mail reaches inboxes

TL;DR

Restore the authentication check on the partner path: review the inbound connector that partner mail uses, confirm whether Enhanced Filtering for Connectors is skipping checks for IPs that should only be trusted for your own gateway, and narrow the skip list to your actual filtering host IPs. When the skip list is too broad, mail that merely transits a listed IP inherits a free pass, and spoofed partner mail sails through with no SPF evaluation at all.

enhanced filtering for connectors skips spf checks and spoofed partner mail reaches inboxes

Use this when

• Spoofed or unauthenticated partner mail reaches inboxes with no SPF or DMARC enforcement applied.
• Headers show the mail skipped filtering or arrived through a connector with enhanced filtering skip enabled.
• Your tenant receives mail through a third party gateway before Exchange Online.

Not for this skill when

• Partner mail is authenticated and passes, but content is malicious. That is a content filtering case, not a skipped check case.
• You intentionally skip Exchange checks because your gateway fully enforces them and stamps results you trust. Audit the gateway instead.

Steps

1. Open a delivered spoof sample and read the connector, the source IPs, and any skip or SCL minus one indicators in the headers. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: the sample shows filtering was skipped and names the path it took
2. List the IPs in the Enhanced Filtering skip configuration and compare them with the documented egress IPs of your own gateway only. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: every skip entry is classified as your gateway or as an entry that should not be there
3. Remove partner, shared, or overly broad ranges from the skip list, keeping only your gateway real egress addresses. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: the saved skip list contains only your gateway addresses
4. Send a controlled unauthenticated test as the partner domain through the same path and watch its treatment. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: the test is now evaluated for SPF and DMARC and is junked or rejected as policy requires
5. Monitor partner mail verdicts for several days to confirm legitimate partner mail still passes on its real authentication. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: legitimate partner samples show evaluated passes, not skips

Why it happens

Enhanced Filtering for Connectors exists so Exchange can see through your own gateway and evaluate the true sender. Misused, it does the opposite: it tells Exchange to trust mail arriving from listed IPs as already checked. If partner ranges, an old gateway, or a broad provider range sit in that list, spoofed mail that touches those IPs inherits trust it never earned. The control is powerful and IP based, so its list needs the same care as a firewall rule.

Variants and edge cases

enhanced filtering for connectors skips spf spoofed partner mail

The exact feature wording with the spoof outcome.

exchange online enhanced filtering skip list too broad spoofing

The broad list variant admins find during audits.

partner mail bypasses dmarc connector enhanced filtering fix

The bypass phrasing used when DMARC seems ignored.

Compatibility: Microsoft 365 Enhanced Filtering for Connectors documentation, Exchange Online inbound connectors.

Edge cases to check:

• Review the skip list whenever you change gateways; the old gateway range left behind is the usual broad entry.
• Combine EHC with connector restrictions so only your gateway can use the trusted inbound connector at all.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_khiKVtiSUUjvQeSaHwONLw