Enhanced Filtering for Connectors in Exchange Online: Check the Mail Route First

Enhanced Filtering for Connectors in Exchange Online: check the mail route first

Originally published 12 December 2023 · Reviewed 4 November 2026. Microsoft’s guidance and portal labels can change; the official references below were checked on the review date. This is a technical orientation, not tenant-specific configuration advice.

Enhanced Filtering for Connectors (EFC), also called skip listing, is relevant when a trusted gateway or on-premises Exchange server handles internet mail before Microsoft 365. The important first question is not “Should we turn it on?” It is “What is the real route, and is that route supported?”

Why the last hop matters

SMTP passes a message from one server to another. If an external filter receives a message and then sends it to Exchange Online, Microsoft 365 sees that filter as the last hop at the tenant boundary. In some multi-hop configurations, the last-hop address is not the original internet source that Microsoft’s filtering needs to assess.

EFC helps Exchange Online use earlier sender and IP information in supported inbound scenarios. That can help protection systems interpret authentication, spoofing and phishing signals. It is not a guarantee that a message will be accepted, that a verdict will change, or that SPF, DKIM or DMARC has been repaired. It also is not a general switch for every tenant.

Decide whether the route fits

Microsoft says EFC is intended for cases where the domain’s MX record does not point directly to Microsoft 365. Examples include a third-party email filtering service or a supported hybrid path that sends internet mail through on-premises Exchange before cloud mailboxes. Identify the Exchange Online connectors that receive this route before considering their EFC settings.

It is not intended for a non-Microsoft service that scans a message after Microsoft 365 has scanned it. Re-routing after a cloud verdict can break the chain of trust and make earlier headers inaccurate.

Centralized Mail Transport needs special care. Microsoft distinguishes linear paths from non-linear ones. Adding hybrid servers to EFC is unsupported for the documented non-linear pattern that routes internet mail to Microsoft 365, then on-premises, then back to Microsoft 365. A linear path through on-premises to Microsoft 365 is treated differently. Do not reduce this to “hybrid works” or “hybrid does not work”: compare your exact route with Microsoft’s diagrams and examples.

Map and inspect before changing anything

Draw the message path from the external sender to the destination mailbox. Include each filter, gateway, on-premises server, NAT boundary and cloud hop. Confirm the MX destination, the connector involved and which systems send mail into Microsoft 365. Ask the service or network owner for the current trusted public addresses; do not infer them from old logs.

Microsoft says to include trusted IP addresses for pre-Microsoft 365 systems that send mail into the organization, including intermediate hops with public addresses. It does not support Microsoft 365 IPs in this list. Loopback and private RFC 1918 addresses are also not supported; EFC handles those automatically. Do not add broader ranges “just in case” or use EFC to compensate for an unsupported route. Microsoft’s current page says IPv6 addresses are supported only through PowerShell.

An authorized Exchange Online administrator can inspect connector fields without changing them:

Get-InboundConnector |
  Select-Object Name, Enabled, EFSkipLastIP, EFSkipIPs, EFUsers

This is an example of a read-only inspection command, not a command run against a tenant. Review the output against the route diagram and approved change record. Keep tenant-specific connector names, addresses and recipient data inside the approved administration workflow.

Review bypass rules and recipient scope

Microsoft advises administrators to review mail-flow rules that set SCL -1 for messages flowing through a connector after EFC is enabled. SCL -1 requests a spam-filtering bypass, but Microsoft documents some exceptions, including certain evaluation-mode and phased defense-in-depth scenarios. Check what a rule matches and why it exists; do not delete a production rule solely to satisfy a generic checklist.

Microsoft recommends testing EFC with a small recipient set before applying it to the whole organization. Scope matching has details that can surprise administrators:

• List the actual recipient addresses that need the test; a mailbox’s aliases may not be covered automatically.
• A group SMTP address applies to mail addressed to that group; it does not automatically cover messages addressed directly to each member.
• In hybrid inbound flow through on-premises Exchange, Microsoft calls out the MailUser object’s TargetAddress.
• If a message has recipients outside the configured set, normal filtering applies to all recipients on that message.

Choose test messages and recipients with the mail owner. Agree what evidence you expect before making a change, and retain a rollback plan.

Separate read-only checks from configuration

An inventory review can be read-only: examine the route, connector identity and current EFC fields, and review relevant rules. Configuration is different. Microsoft documents the Defender portal’s Enhanced filtering page and the Exchange Online PowerShell parameters EFSkipLastIP, EFSkipIPs and EFUsers. Those controls change how mail is evaluated and which recipients are in scope.

Treat any configuration as an owner-approved change. Confirm the topology, trusted addresses, least-privilege role, impact, test scope and rollback plan with the responsible mail administrator. Microsoft lists Exchange Organization Management or Exchange Administrator/Global Administrator role options for its procedures and explicitly recommends least privilege; Global Administrator should not be the default. This guide intentionally provides no Set-InboundConnector command to run.

Verify with documented signals

After an approved test, inspect representative message headers and the Threat protection status report with the mail team. Microsoft documents X-MS-Exchange-ExternalOriginalInternetSender when skip listing succeeds and recipient matching occurs. It also documents X-MS-Exchange-SkipListedInternetSender as a reporting signal when skip listing is enabled. These fields help investigate what happened; they do not promise a particular spam verdict or prove every route is correct.

If the expected indicators are absent, check the connector, recipient match and actual message path before expanding scope. If protection results change unexpectedly, pause rollout and follow your incident and mail-flow review process.

A practical review order

1. Diagram the current inbound route and confirm where the MX record points.
2. Verify that the mail path matches Microsoft’s supported EFC scenarios, including the Centralized Mail Transport distinction.
3. Obtain the current trusted public IPs for systems that send mail before Microsoft 365; exclude unsupported address classes.
4. Inspect connector settings and SCL -1 bypass rules without changing them.
5. Get the change approved, select a small test scope, and document success and rollback criteria.
6. Verify representative message headers and the Threat protection status report before considering a wider scope.

If the route is unclear, contains cloud-to-on-premises-to-cloud loops, or depends on a filter after Microsoft 365, stop and have a mail-flow specialist review it. An accurate route diagram is more useful than copying a setting from a different tenant.

Official references

• Enhanced filtering for connectors in Exchange Online — Microsoft Learn, accessed 4 November 2026; page listed as updated 15 October 2026.
• Set-InboundConnector — Exchange Online PowerShell reference, accessed 4 November 2026.
• Configure mail flow using connectors in Exchange Online — Microsoft Learn, accessed 4 November 2026.

Related: Microsoft 365 mail flow troubleshooting steps, check email domain records, and the email health check.