Put a non-Microsoft filtering service or appliance in front of Exchange Online and every inbound message seems to come from the gateway's IP addresses. SPF results stop meaning anything, DMARC fails on messages the gateway changed, and spoof detection either fires on legitimate mail or gets bypassed completely. In this post I'll show how to lock Exchange Online to the gateway, turn on Enhanced Filtering for Connectors (also called skip listing) and prove in the message headers that it works.
How it works#
SMTP only shows the receiving server the IP address of the last hop. When your MX record points to a gateway, that last hop is always the gateway, so Exchange Online Protection checks SPF against the gateway instead of the real sender. If the gateway adds a banner or rewrites links, the DKIM signature breaks too, and DMARC fails with it.
Enhanced Filtering tells Exchange Online which IP addresses on an inbound connector to skip. It then evaluates the source in front of them. Microsoft says this preserves the original IP address and sender, recovers from DKIM failures caused by modification and enables explicit SPF, DKIM and DMARC checks. Two headers show it at work:
| Header | Stamped when |
|---|---|
X-MS-Exchange-SkipListedInternetSender | Skip listing is enabled on the connector, whether or not the recipient is in scope |
X-MS-Exchange-ExternalOriginalInternetSender | Skip listing succeeded and the recipient matched the scope; the value contains the true source address |
The feature is meant for routes where the MX record doesn't point to Microsoft 365: an inbound gateway, or a hybrid setup where internet mail enters through Exchange Server first. It isn't meant for services that scan mail after Microsoft 365; routing scanned mail out and back breaks the chain of trust.
Prerequisites#
- Organization Management in Exchange Online, or the Exchange Administrator role in Microsoft Entra ID.
- Your domains added and verified in Microsoft 365, with the MX record pointing to the gateway.
- The gateway's public sending IP addresses, or the name on its TLS certificate, from the vendor's documentation. Include any intermediate hops with public IPs.
- An SPF record that still lists only Microsoft 365 (
include:spf.protection.outlook.com), unless your outbound mail also goes through the gateway. See SPF, DKIM and DMARC for your Microsoft 365 custom domain.
Step-by-step#
1. Accept inbound mail only from the gateway#
Microsoft recommends a Partner inbound connector that identifies the gateway by certificate (preferred) or by IP address, with the matching restriction turned on. After that, Exchange Online rejects messages sent straight to your tenant that try to get around the gateway:
Connect-ExchangeOnline
# Certificate-based (preferred)
New-InboundConnector -Name "From mail gateway" -ConnectorType Partner -SenderDomains * `
-RequireTls $true -TlsSenderCertificateName *.gateway.example -RestrictDomainsToCertificate $true
# Or IP-based
New-InboundConnector -Name "From mail gateway" -ConnectorType Partner -SenderDomains * `
-SenderIpAddresses 203.0.113.0/24,198.51.100.10 -RestrictDomainsToIPAddresses $trueThe restriction parameters work only on Partner connectors. If an OnPremises connector already uses the same certificate or IPs, create the Partner connector anyway. Microsoft says the two can coexist.
2. Turn on Enhanced Filtering for a pilot group#
In the Microsoft Defender portal, go to Email & collaboration › Policies & rules › Threat policies › Enhanced filtering (in the Rules section) and select the connector. Under IP addresses to skip, choose one of these:
- Automatically detect and skip the last IP address, when the gateway is the only hop in front of Microsoft 365.
- Skip these IP addresses that are associated with the connector, when there are several hops. List every public IP of the systems that handle your mail before Microsoft 365.
Under Apply to these users, start with Apply to a small set of users. In PowerShell:
# Pilot: skip the last hop for three recipients
Set-InboundConnector -Identity "From mail gateway" -EFSkipLastIP $true `
-EFUsers "michelle@contoso.com","laura@contoso.com","julia@contoso.com"
# Multiple hops: skip a list of IPs instead
Set-InboundConnector -Identity "From mail gateway" -EFSkipLastIP $false -EFSkipIPs 203.0.113.0/24,198.51.100.10
# After the pilot: apply to all recipients
Set-InboundConnector -Identity "From mail gateway" -EFUsers $nullPilot scoping is literal. List every proxy address of each test user, and remember that a message with any recipient outside the list gets normal filtering for all of its recipients. When internet mail passes through Exchange Server on-premises first, specify the MailUser's target address (for example michelle@contoso.mail.onmicrosoft.com).
3. Remove the SCL -1 bypass rule#
Gateway setups often include a mail flow rule that sets the spam confidence level (SCL) to -1 for mail from the gateway. Once Enhanced Filtering is on, Microsoft says to disable it, except during a Defender for Office 365 evaluation or while phasing in a defense-in-depth configuration. A bypass is risky because gateway providers often share IP addresses among many customers, so spoofed and phishing mail from those IPs would skip filtering too.
4. Trust the gateway's ARC seal, if it has one#
If the gateway modifies messages and supports ARC, go to Email & collaboration › Policies & rules › Threat policies › Email authentication settings › ARC and add its sealing domain. The domain must match the d= value in the ARC-Seal and ARC-Message-Signature headers. In PowerShell, Set-ArcConfig -Identity Default -ArcTrustedSealers gateway.example replaces the whole list, so include any existing sealers. If the gateway modifies messages without ARC, review the spoof detections and add allow entries for legitimate spoofed senders. My Tenant Allow/Block List guide shows how.
Verify#
- Send a test from an external mailbox to a pilot user and open the message headers (in Outlook, File › Properties, or paste them into the Message Header Analyzer).
- Good looks like:
X-MS-Exchange-ExternalOriginalInternetSenderis present and contains the external sender's real IP, not the gateway's.Authentication-Resultsevaluates SPF against that original source, and DMARC andcompauthpass for a properly authenticated sender. - Only
X-MS-Exchange-SkipListedInternetSenderis present? Then skip listing is enabled, but the recipient is out of scope. Check-EFUsersand the proxy addresses. - From a host that isn't the gateway, send a message straight to the MX value Microsoft 365 shows for your domain (Settings › Domains in the Microsoft 365 admin center). It should be rejected.
- Watch the Threat protection status report in the Defender portal.
Get-InboundConnector "From mail gateway" |
Format-List ConnectorType, RestrictDomainsToCertificate, RestrictDomainsToIPAddresses, EFSkipLastIP, EFSkipIPs, EFUsersTips & gotchas#
- Don't skip what you don't own. Microsoft 365 IP addresses aren't supported. Private (RFC 1918) and loopback addresses are skipped automatically and can't be added. IPv6 entries work only in PowerShell. Configure NAT so mail servers use public IPs.
- Hybrid with centralized mail transport. Adding your Exchange servers is supported only for linear routes (internet › on-premises › Microsoft 365). It isn't supported when mail goes from Microsoft 365 to on-premises and back, because the returning mail is scanned again and can be marked as spam.
- Gateway relays through Exchange Server? Microsoft says to enable Enhanced Filtering on the OnPremises inbound connector as well.
- For the on-premises version of this design, see Email gateway in front of Exchange Server.
