Configure ARC trusted sealers and Enhanced Filtering for an email gateway

When mail passes through a third-party gateway before it reaches Exchange Online, Microsoft 365 sees the gateway's IP address instead of the real sender's, and any change the gateway makes to the message breaks the original DKIM signature, so SPF, DKIM and DMARC fail and legitimate mail is treated as spoofed. The fix has two parts: turn on Enhanced Filtering for Connectors on the inbound connector that receives mail from the gateway, so Microsoft 365 evaluates the true source IP, and add the gateway's ARC signing domain (the d= value in its ARC-Seal header) as a trusted ARC sealer, so Microsoft 365 can use the authentication results the gateway recorded before it changed the message. Then retire any rule that bypasses spam filtering for the gateway.

Who this is for and what you will have

This guide is for Exchange Online administrators whose MX record points to a cloud filtering service, a filtering appliance or another relay that handles internet mail before Microsoft 365. Typical symptoms are messages from well-configured senders in Junk Email or quarantine with compauth=fail, every message showing the gateway as its connecting IP, and spoof detections for domains that publish correct SPF, DKIM and DMARC. At the end you will have:

• A partner inbound connector that identifies the gateway and accepts mail for your domains only through it.
• Enhanced Filtering for Connectors enabled, tested on a few recipients, then on the whole organization.
• The gateway's signing domain configured as a trusted ARC sealer.
• Header evidence that both features are working.

Why authentication fails behind a gateway

Every SMTP hop connects with its own IP address. When the gateway relays a message to Exchange Online, the connecting IP is the gateway's, so the SPF check is made against an IP the original sender never authorized. If the gateway also modifies the message (changing headers or content, or removing attachments), the sender's DKIM signature no longer verifies. With both SPF and DKIM failing, DMARC fails too, and the spoofing protections act on mail that was legitimate when it left the sender.

Microsoft's own description is that the message adopts the source IP of the last hop in front of Microsoft 365, and that this is simply how SMTP works. The two features in this guide address different halves of the problem:

Prerequisites

• The MX record for your domain points to the gateway, and the gateway delivers to your Exchange Online MX host.
• Every public IP address the gateway (and any intermediate hop) uses to send to Microsoft 365, from the vendor's documentation or support. Private RFC 1918 and loopback addresses aren't supported in the skip list; they are detected and skipped automatically.
• Exchange Online PowerShell. Enhanced Filtering needs the Organization Management role group, or the Exchange Administrator Entra role. Trusted ARC sealers need the Organization Management or Security Administrator role group; Microsoft notes that the Entra Security Administrator role can't access email authentication settings in the Defender portal.
• A few test recipients and an external mailbox you can send from.

Enhanced Filtering is intended for exactly this layout, where the MX record doesn't point to Microsoft 365. It isn't intended for services that scan mail after Microsoft 365. In hybrid environments, adding on-premises servers to the skip list is supported for linear routing (Internet > on-premises > Microsoft 365) but not for non-linear routing such as Internet > Microsoft 365 > on-premises > Microsoft 365.

Step 1: Create or confirm the partner inbound connector

Enhanced Filtering is configured per inbound connector, so the gateway must be identified by one. Microsoft's guidance for this scenario is a Partner connector that matches the gateway's certificate (preferred) or its IP addresses, with the matching restriction turned on, so that mail sent straight to your Exchange Online endpoint without passing through the gateway is rejected:

Connect-ExchangeOnline -UserPrincipalName admin@contoso.com
 
New-InboundConnector -Name "Inbound from mail gateway" -ConnectorType Partner `
  -SenderDomains * -RestrictDomainsToCertificate $true `
  -TlsSenderCertificateName *.fabrikam.net -RequireTls $true

Or, for a gateway identified by IP addresses:

New-InboundConnector -Name "Inbound from mail gateway" -ConnectorType Partner `
  -SenderDomains * -RestrictDomainsToIPAddresses $true `
  -SenderIpAddresses 203.0.113.0/24,198.51.100.10

Replace the certificate name and addresses with the values your vendor publishes. If you already have an OnPremises inbound connector for the same certificate or IPs, you still need the Partner connector, because the restriction parameters apply only to Partner connectors; the two can coexist.

Step 2: Enable Enhanced Filtering on a test group

Start with a few recipients so you can compare results before applying it to everyone.

In the Defender portal, go to Email & collaboration > Policies & rules > Threat policies > Rules section > Enhanced filtering (or https://security.microsoft.com/skiplisting), select the connector, and choose one of these under IP addresses to skip:

• Automatically detect and skip the last IP address: recommended when only the last message source needs to be skipped, which is the usual single-gateway case.
• Skip these IP addresses that are associated with the connector: enter single IPs, ranges or CIDR blocks when the path has more than one public hop. Microsoft 365 IP addresses aren't supported, and IPv6 entries can only be added in PowerShell.

Then under Apply to these users select Apply to a small set of users and enter the test addresses. Save.

The PowerShell equivalent:

Set-InboundConnector -Identity "Inbound from mail gateway" -EFSkipLastIP $true `
  -EFUsers "michelle@contoso.com","laura@contoso.com"

Two caveats about the test scope. It matches only the exact addresses you list, so a user with several proxy addresses needs every one of them listed. And it applies only to messages where all recipients are in the list; if any recipient isn't, normal filtering applies to all of them. In hybrid setups where mail flows through on-premises Exchange, list the mail user's target address (for example michelle@contoso.mail.onmicrosoft.com).

Step 3: Identify the gateway's ARC signing domain

Ask the vendor whether the service adds ARC headers and whether it is enabled for your account; if there is no ARC-Seal header in delivered messages, the service isn't sealing. Then:

1. Send a test message from an external mailbox to one of the test recipients, so it travels through the gateway.
2. Open its headers (in Outlook: File > Properties > Internet headers, or paste them into the Message Header Analyzer).
3. Find the ARC-Seal: header added by the gateway and note its d= value.

ARC-Seal: i=1; a=rsa-sha256; d=fabrikam.net; s=arcselector;
  cv=none; b=<signature>

Here the trusted sealer is fabrikam.net. It must match the d value in the ARC-Seal and ARC-Message-Signature headers. Microsoft's troubleshooting guidance specifically warns against entering your own domain here, which is a common mistake.

Step 4: Add the trusted ARC sealer

In the Defender portal, go to Email & collaboration > Policies & rules > Threat policies > Email authentication settings in the Rules section, open the ARC tab, select Add (or Edit if sealers are already listed), enter the domain and select Save.

In PowerShell, -ArcTrustedSealers replaces the whole list, so check what is there first and include it:

Get-ArcConfig
 
$sealers = @(Get-ArcConfig | Select-Object -Expand ArcTrustedSealers)
$sealers += "fabrikam.net"
Set-ArcConfig -Identity Default -ArcTrustedSealers $sealers

Allow up to 30 minutes for the change to take effect, and test only with messages sent after that. Add only services you actively use: a compromised trusted sealer could pass spoofed messages through your authentication checks.

Step 5: Verify both features

Send new test messages from an external domain that publishes SPF, DKIM and DMARC, through the gateway, to a test recipient. In the delivered message's headers check the following.

Enhanced Filtering. X-MS-Exchange-ExternalOriginalInternetSender is stamped when skip listing succeeded, is enabled on the connector and the recipient matched; its value contains the true source address. X-MS-Exchange-SkipListedInternetSender is stamped whenever skip listing is enabled on the connector, regardless of recipient match, and is mainly for reporting. If you see the second header but not the first on a test recipient's message, recheck the recipient list.

ARC. In the last ARC-Authentication-Results header, look for arc=pass with oda=1, which means the previous seal was verified and its sealer is trusted:

ARC-Authentication-Results: i=2; mx.microsoft.com 1; ...
 arc=pass (0 oda=1 ltdi=1 ...)

If the original DMARC result failed because of modification, the last Authentication-Results header shows that ARC rescued it:

Authentication-Results: spf=fail (sender IP is 10.10.10.10)
 smtp.mailfrom=contoso.com; dkim=fail (body hash did not verify)
 header.d=contoso.com;dmarc=fail action=none
 header.from=contoso.com;compauth=pass reason=130

reason=130 means the ARC result from a trusted ARC sealer overrode the DMARC failure.

Step 6: Roll out and clean up

When the test recipients look right for a few days, apply Enhanced Filtering to everyone:

Set-InboundConnector -Identity "Inbound from mail gateway" -EFSkipLastIP $true -EFUsers $null
Get-InboundConnector "Inbound from mail gateway" | Format-List Name,ConnectorType,EFSkipLastIP,EFSkipIPs,EFUsers

An empty EFUsers value applies the feature to all recipients. In the portal, choose Apply to entire organization.

Then disable mail flow rules that set SCL -1 for messages from the gateway. Microsoft's guidance is to disable them once Enhanced Filtering is on, except while you use Defender for Office 365 evaluation mode or are phasing in a defense-in-depth configuration. List candidates with:

Get-TransportRule | Where-Object {$_.SetSCL -ne $null} | Format-Table Name, State, SetSCL, Priority
Disable-TransportRule -Identity "Bypass spam filtering for gateway"

The Threat protection status report in the Defender portal shows the change in detections once filtering sees real source IPs.

Troubleshooting

Broken chain (cv=fail). A hop modified the message after adding its seal, the sealer's public key couldn't be looked up in DNS, or a rotated key was still cached. Check cv= at each i= instance to find where it broke. If two services you control are in the path, make sure modifications happen before sealing, not after.

The service can't seal with ARC. Enhanced Filtering's DKIM recovery may be enough. If not, Microsoft recommends reviewing the Spoof detections report and creating allow entries for spoofed senders for the legitimate messages that still fail.

ARC passes but mail is still in Junk. ARC overrides DMARC failures only. An SFV:SPM, CAT:SPM or CAT:HSPM value means content filtering acted; follow Microsoft 365 email landing in Junk to find and fix that cause.

Internet mail stops arriving after you create the connector. The SenderDomains * connector with a restriction rejects mail that didn't come from the listed certificate or IPs. Confirm the vendor's full list of sending addresses or the exact certificate subject, and keep the connector disabled until they match.

You plan to enable inbound DANE. With a gateway in front of Exchange Online, inbound SMTP DANE only protects the gateway-to-Exchange Online leg, and only if the gateway supports DANE validation; see Inbound SMTP DANE with DNSSEC in Exchange Online.

Checklist

• Partner inbound connector restricted to the gateway's certificate or IPs; existing OnPremises connector left in place if present.
• Enhanced Filtering enabled with Automatically detect and skip the last IP address, or an explicit public IP list for multi-hop paths.
• Tested on a small set of users (all proxy addresses listed), then applied to the organization.
• Gateway's ARC d= domain, not your own domain, added as a trusted sealer, with existing sealers preserved.
• Headers confirm X-MS-Exchange-ExternalOriginalInternetSender, arc=pass with oda=1, and compauth=pass where DMARC had failed.
• SCL -1 rules for the gateway disabled.

References

• Configure trusted ARC sealers
• Set-ArcConfig
• Enhanced Filtering for Connectors in Exchange Online
• Manage mail flow using a third-party cloud service with Exchange Online
• Anti-spam message headers
• Troubleshoot anti-spam policies
• Manage mail flow rules in Exchange Online