Spam filter for Exchange Server: an MX gateway in front of your on-premises server

To use a spam filter with Exchange Server, change your MX records so internet mail reaches the filtering service first, create a Receive connector that accepts that mail only from the filter's IP ranges, and restrict inbound port 25 at your firewall to those ranges. Clean mail then reaches Exchange as before. The built-in anti-spam agents can stay uninstalled.

This page covers on-premises Exchange Server 2016, Exchange Server 2019 and Exchange Server Subscription Edition (SE). If your mailboxes are in Exchange Online, follow the Microsoft 365 setup instead.

Placeholders used below:

• <GATEWAY-MX-HOSTS>: the MX hostnames for your domain.
• <GATEWAY-IP-RANGES>: the IP ranges the filtering service delivers from.
• <EXCHANGE-SMTP-HOST>: the public hostname of your Exchange server, for example mail.example.com.

The iBlockSpam setup wizard shows your exact values, a before/after DNS comparison and the rollback steps.

Prerequisites

• An account in the Organization Management role group, and the Exchange Management Shell.
• <EXCHANGE-SMTP-HOST> resolves publicly, accepts SMTP on port 25 and presents a valid TLS certificate for that name.
• Access to your DNS host and to your perimeter firewall.
• A list of anything that sends mail into Exchange on port 25: scanners, line-of-business apps, monitoring tools and partners. These need a plan before you restrict the firewall.
• An outside test mailbox.

How inbound mail reaches Exchange today

Without an Edge Transport server, internet mail enters through the default Receive connector named Default Frontend <ServerName> in the Front End Transport service. It listens on port 25 and accepts anonymous connections from every IP address (Microsoft Learn: Mail flow and the transport pipeline).

When several Receive connectors listen on the same port, Exchange uses the one whose remote IP range most specifically matches the connecting server (Microsoft Learn: Receive connectors). That lets you give the filtering service its own connector without touching the default one.

Step by step

1. Add your domain in iBlockSpam. Set the delivery destination to <EXCHANGE-SMTP-HOST> on port 25. The wizard checks that it can connect.

2. Lower the MX TTL to 300 seconds at least one full old-TTL period before the cutover, so the change spreads quickly and can be undone quickly.

3. Create a Receive connector scoped to the filter. Microsoft says custom port 25 connectors on Mailbox servers belong in the Front End Transport service, and a connector limited to specific remote IPs doesn't conflict with the default one (Microsoft Learn: Scenarios for custom Receive connectors). Run this on each Mailbox server that receives internet mail:

   New-ReceiveConnector -Name "iBlockSpam inbound" -Server <SERVER> `
     -TransportRole FrontendTransport -Custom -Bindings 0.0.0.0:25 `
     -RemoteIPRanges <GATEWAY-IP-RANGES> -Fqdn <EXCHANGE-SMTP-HOST> `
     -AuthMechanism Tls -PermissionGroups AnonymousUsers `
     -ProtocolLoggingLevel Verbose
   

   The AnonymousUsers permission group accepts mail for your accepted domains but doesn't allow relay to outside domains. Keep -Fqdn matching the name on your certificate, because TLS needs a certificate that includes the name the connector advertises. Don't use Externally secured with the Exchange servers permission group here. Microsoft warns that this combination lets the listed IPs relay anonymously through your server.

4. Decide what to do with the built-in anti-spam agents. Check what's installed with Get-TransportAgent. The agents aren't installed on Mailbox servers by default, and Microsoft says you typically don't need them when other anti-spam filtering handles incoming mail (Microsoft Learn: Enable anti-spam functionality on Mailbox servers). If they're installed, turn off the ones that judge the connecting IP, because that IP is now the filtering service:

   Set-SenderIdConfig -Enabled $false
   Set-SenderReputationConfig -Enabled $false
   

   You can keep the Content Filter agent as a light second layer, starting from Microsoft's default thresholds. The Malware agent is enabled by default on Mailbox servers and can stay on (Microsoft Learn: Anti-spam protection in Exchange Server).

5. Change the MX record. Replace your MX with <GATEWAY-MX-HOSTS> and the priorities the wizard shows. Don't keep your Exchange server as a lower-priority backup MX. Senders may use any listed MX (RFC 5321, section 5.1), and spammers often target the backup on purpose. Our guide on changing MX records without losing email covers the timing.

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. Close port 25 to everyone else. Removing your server from MX doesn't stop spammers who connect to its IP address directly, and Default Frontend still accepts them. After the old TTL has expired, set your perimeter firewall to allow inbound TCP 25 from the internet only from <GATEWAY-IP-RANGES>. Keep port 443 and, if you use it, 587 open for clients. Internal devices that relay through Exchange from your LAN aren't affected by a perimeter rule. Our guide to blocking direct-to-server bypass explains why this step matters.

8. Optional: send outbound mail through the iBlockSpam outbound relay. A Send connector can route mail to a smart host instead of using DNS (Microsoft Learn: Send connectors):

   New-SendConnector -Name "iBlockSpam outbound" -Internet -AddressSpaces * `
     -DNSRoutingEnabled $false -SmartHosts <RELAY-HOST> `
     -SmartHostAuthMechanism BasicAuthRequireTLS `
     -AuthenticationCredential (Get-Credential)
   

   Use the relay host and sign-in details from the wizard, then disable your old Internet Send connector or give it a higher cost. Add iBlockSpam to your SPF record only if you do this. See outbound relay for the included volume before you switch.

If you run an Edge Transport server

With an Edge Transport server, internet mail enters through the Edge server's own Receive connector. Apply steps 3, 4 and 7 to the Edge server instead, and omit -TransportRole from the step 3 command when you run it there. Its anti-spam agents are installed and enabled by default, so review them the same way.

How to verify

Send a test from an outside mailbox and open the message headers in Outlook (File > Properties > Internet headers), or paste them into the Email Header Analyzer, which runs in your browser.

• Received: the hop before your Exchange server should be the filtering service.
• Protocol log: with verbose logging on the new connector, Front End Transport protocol logs show sessions on iBlockSpam inbound. Sessions on Default Frontend from internet IPs should stop after step 7.
• Direct test: from a server that isn't the gateway, try telnet <EXCHANGE-SMTP-HOST> 25. After step 7 the connection should time out or be refused.

Rollback

Order matters. If you reverse the MX first, the firewall will block internet mail that now arrives directly.

1. Remove the port 25 firewall restriction.
2. Change the MX back to <EXCHANGE-SMTP-HOST>, with a short TTL.
3. Keep the iBlockSpam domain active until the old TTL has expired, so mail still arriving through the filter is delivered.
4. Remove the scoped connector with Remove-ReceiveConnector "<SERVER>\iBlockSpam inbound". If you disabled Sender ID or sender reputation and have no other filtering, turn them back on.
5. If you set up the outbound Send connector, re-enable your old connector first, then remove the new one.

Common mistakes

• Restricting the firewall before the MX change has spread. Mail still routed directly is refused.
• Keeping Exchange as a backup MX. It gives spammers a route around the filter.
• Using the Externally secured permission. It turns the filter's IPs into an anonymous relay.
• Leaving Sender ID on. It evaluates the filtering service's IP against the sender's SPF record and can mark good mail as failing.
• Forgetting outside senders that deliver straight to port 25. Partners or cloud apps that bypass MX stop working once the firewall rule is on.
• Wrong certificate name. If -Fqdn doesn't match a name on your certificate, TLS from the filter can fail.

Limits

• Each domain includes 100,000 inbound messages per month and accepts messages up to 400 MB. Exchange's own message size limits still apply, and the smaller limit wins.
• Unlimited mailboxes means any number of mailboxes per domain, not unlimited message volume.
• Mail is spooled for up to 5 days if your server is unreachable. See outage spooling. Message history is kept for 30 days.
• A filter doesn't patch Exchange. Microsoft's lifecycle pages show that extended support for Exchange Server 2016 and Exchange Server 2019 ended in October 2025.
• An MX lookup can't prove mail is filtered. Headers, protocol logs and a direct-connection test are the evidence.

Sources

• Microsoft Learn: Receive connectors
• Microsoft Learn: Scenarios for custom Receive connectors in Exchange Server
• Microsoft Learn: Enable anti-spam functionality on Mailbox servers
• Microsoft Learn: Anti-spam protection in Exchange Server
• Microsoft Learn: Mail flow and the transport pipeline
• Microsoft Learn: Send connectors in Exchange Server
• RFC 5321: Simple Mail Transfer Protocol, section 5.1