Spam filter for Microsoft 365: an MX gateway in front of Exchange Online

This page shows how to place iBlockSpam in front of Exchange Online so that internet mail reaches the filtering service first and only clean mail is delivered to Microsoft 365. It follows Microsoft's documented pattern for an MX record that points to a non-Microsoft filtering service (Microsoft Learn: Manage mail flow using a third-party cloud service).

Throughout this page, placeholders stand in for values that are specific to your account:

• <GATEWAY-MX-HOSTS>: the MX hostnames for your domain.
• <GATEWAY-IP-RANGES>: the IP ranges the filtering service uses to deliver mail to you.
• <GATEWAY-TLS-CERT-NAME>: the certificate subject name the filtering service presents over TLS.

The iBlockSpam setup wizard shows your exact values, a before/after DNS comparison and the rollback steps for your domain. Copy values from the wizard, not from examples.

Prerequisites

• Your domain is verified and Healthy in the Microsoft 365 admin center (Settings > Domains).
• An account with the Exchange Administrator role (or Organization Management in Exchange Online). Microsoft recommends least privilege, so avoid Global Administrator where you can.
• Access to your DNS host to change MX records.
• The Exchange Online PowerShell module if you prefer PowerShell (Connect to Exchange Online PowerShell).
• Your tenant's MX endpoint, for example contoso-com.mail.protection.outlook.com. Find it under Settings > Domains > your domain > DNS records in the Microsoft 365 admin center. iBlockSpam delivers clean mail to this host.
• A list of anything that sends mail straight into your tenant on port 25 (scanners, line-of-business apps, other services). These need a plan before you lock the connector down.

Step by step

These are the iBlockSpam-specific steps. For the background on connectors and why Enhanced Filtering matters with any third-party filter, read our Microsoft 365 Enhanced Filtering setup guide.

1. Add your domain in iBlockSpam. Enter the domain and your Microsoft 365 MX endpoint as the delivery destination. The wizard confirms that the filtering service can deliver to it.

2. Lower the MX TTL. At your DNS host, set the TTL of your current MX records to 300 seconds (5 minutes) at least one full old-TTL period before the cutover, so the change spreads quickly and can be undone quickly.

3. Create the Partner inbound connector, without restrictions yet. In the Exchange admin center at https://admin.cloud.microsoft/exchange#/connectors, go to Mail flow > Connectors > + Add a connector:

   • Connection from: Partner organization (Connection to is fixed to Office 365).
   • Name: for example iBlockSpam inbound.
   • Authenticating sent email: By verifying that the sender domain matches one of the following domains, and enter * (all sender domains).
   • Security restrictions: select Reject email messages if they aren't sent over TLS. Leave the certificate and IP-range restrictions unchecked for now.
   • Select Create connector.

   PowerShell equivalent:

   New-InboundConnector -Name "iBlockSpam inbound" -ConnectorType Partner `
     -SenderDomains * -RequireTls $true `
     -SenderIpAddresses <GATEWAY-IP-RANGES>
   

4. Turn on Enhanced Filtering for Connectors. In the Microsoft Defender portal, go to Email & collaboration > Policies & rules > Threat policies > Rules > Enhanced filtering (direct link: https://security.microsoft.com/skiplisting). Select the connector and choose Skip these IP addresses that are associated with the connector, then enter <GATEWAY-IP-RANGES>. Microsoft also offers Automatically detect and skip the last IP address, which suits a single hop. Start with Apply to a small set of users if you want a pilot, then switch to Apply to entire organization. (Microsoft Learn: Enhanced Filtering for Connectors)

   Set-InboundConnector -Identity "iBlockSpam inbound" `
     -EFSkipLastIP $false -EFSkipIPs <GATEWAY-IP-RANGES>
   # Pilot on named recipients first (list every proxy address you want covered):
   # Set-InboundConnector -Identity "iBlockSpam inbound" -EFUsers "pilot1@example.com","pilot2@example.com"
   

   Note that IPv6 ranges can only be set in PowerShell, and private or Microsoft 365 IPs are not accepted.

5. Change the MX record. Replace your Microsoft 365 MX record with <GATEWAY-MX-HOSTS> and the priorities the wizard shows. Do not keep the Microsoft MX as a lower-priority backup: sending servers may use any listed MX (RFC 5321, section 5.1), and spammers often target the backup on purpose.

6. Watch the change spread. Use the MX Lookup tool and send test messages from an outside mailbox. Mail may arrive by both paths while resolvers expire the old record. This is expected.

7. Lock the connector to the filtering service. After the old TTL has expired and you see mail arriving through iBlockSpam, restrict the connector so that mail sent straight to *.mail.protection.outlook.com is rejected. Microsoft prefers the certificate method:

   # Preferred: certificate
   Set-InboundConnector -Identity "iBlockSpam inbound" `
     -TlsSenderCertificateName <GATEWAY-TLS-CERT-NAME> `
     -RestrictDomainsToCertificate $true -RequireTls $true
   
   # Alternative: IP ranges
   Set-InboundConnector -Identity "iBlockSpam inbound" `
     -SenderIpAddresses <GATEWAY-IP-RANGES> `
     -RestrictDomainsToIPAddresses $true
   

   In the Exchange admin center, these correspond to And require that the subject name of the certificate that the partner uses to authenticate with Office 365 matches this domain name and Reject email messages if they aren't sent from within this IP address range on the Security restrictions page.

8. Remove spam-bypass rules. If you have any mail flow rule that sets SCL to -1 for the gateway, disable it. Microsoft says SCL -1 is "an input to filtering, not a final decision" and recommends Enhanced Filtering instead.

9. Optional: reject Direct Send from your own domain. Set-OrganizationConfig -RejectDirectSend $true rejects unauthenticated messages that use your accepted domains as the sender and are delivered straight to your tenant. It complements the connector lockdown; it does not replace it.

How to verify

Open a test message from an outside sender in Outlook (File > Properties > Internet headers), or paste the headers into the Email Header Analyzer, which runs in your browser. Check:

• Received lines: the hop before Microsoft 365 should be the filtering service.
• X-MS-Exchange-SkipListedInternetSender and X-MS-Exchange-ExternalOriginalInternetSender: these show the true source address when Enhanced Filtering is working (Microsoft Learn).
• Authentication-Results: SPF should be evaluated against the original sender's IP, not the gateway's. compauth reason 905 means DMARC was not enforced because of complex routing, which usually points to Enhanced Filtering not covering that message (Microsoft Learn: anti-spam headers).
• X-Forefront-Antispam-Report: SFV:SKN means a mail flow rule bypassed filtering. You should not see it after step 8.

Then test the lockdown: send a message straight to your *.mail.protection.outlook.com host from a server that is not the gateway. It should be rejected with a 5.7.51 TenantInboundAttribution error.

Rollback

Order matters. If you reverse the MX first, the locked connector will reject internet mail that now arrives directly.

1. Remove the restriction: Set-InboundConnector -Identity "iBlockSpam inbound" -RestrictDomainsToCertificate $false -RestrictDomainsToIPAddresses $false.
2. Change the MX back to your Microsoft 365 endpoint, with a short TTL.
3. Keep the iBlockSpam domain active until the old MX TTL has expired, so mail still arriving through the gateway is delivered.
4. Turn off Enhanced Filtering (-EFSkipLastIP $false -EFSkipIPs $null), then disable or remove the connector.

Common mistakes

• Locking the connector before the MX change has spread. Mail still routed directly is rejected.
• Leaving Microsoft's MX as a backup. It gives spammers a route around the filter.
• Enhanced Filtering on the wrong connector, or for a small set of users only. When piloting, Enhanced Filtering applies only if every recipient of the message is listed, including all proxy addresses.
• Keeping an SCL -1 rule. It disables most of Microsoft's protections for everything from shared gateway IPs.
• Forgetting Direct Send senders. Scanners and apps that deliver straight to the tenant stop working once the connector is restricted.
• Changing SPF when you don't need to. Inbound filtering doesn't touch your SPF record. If you're checking it anyway, our Microsoft 365 SPF record page shows the exact include Microsoft documents and its lookup cost.
• Double link rewriting. Microsoft advises against two services rewriting the same links (Microsoft Learn: integrate non-Microsoft security services).

Limits

• Each domain includes 100,000 inbound messages per month and accepts messages up to 400 MB. Exchange Online applies its own message size limits, so the smaller limit wins.
• Unlimited mailboxes means any number of mailboxes per domain. It does not mean unlimited message volume.
• If Microsoft 365 is unavailable, mail is spooled for up to 5 days. Message history is kept for 30 days.
• An MX lookup shows where mail should go. It can't prove that mail is filtered, and it doesn't show whether your tenant still accepts direct delivery. Use the header and lockdown tests above.

Do you need a gateway?

Microsoft's own protection is capable, and a gateway isn't right for every tenant. Read Microsoft 365 built-in filtering vs a gateway and Defender for Office 365 vs a gateway before you decide. Stuck on a step? Our support page lists what to send so we can trace mail quickly.