How do you decommission your old spam filter after switching?

Switching spam filters ends with an MX change, but the old service is still woven into your setup: connectors, IP allow lists, DNS records, maybe your outbound mail path. Leftovers aren't harmless. Every range you still trust is a route around your new filter. This guide is the cleanup checklist, in the order that avoids losing mail.

It picks up where switching spam filter providers leaves off. If you haven't changed MX yet, start there.

When is it safe to start removing the old filter?

Not on cutover day. Three things must be true first.

1. The old MX has expired everywhere. Wait at least the TTL the old MX record had before you lowered it, plus a margin. How DNS TTL affects an MX change explains why.
2. The old service's queue is empty. Mail it accepted before the switch, or mail it deferred because your server was busy, is still delivered from there. Senders also retry. RFC 5321, section 4.5.4.1 says the give-up time "generally needs to be at least 4-5 days", so a sender that tried the old MX just before the change may come back days later.
3. Users have finished with the old quarantine. Release anything needed before you lose console access.

Check the old service's own logs or message history. You want several days in a row with no new inbound deliveries. A trickle after the switch is normal; steady traffic means something still points at the old service, such as a partner delivering to a fixed host.

What does the decommissioning checklist look like?

Work through it top to bottom. The order matters: remove the routes into your mail first, then trust settings, then outbound pieces, then the account.

The sections below cover each platform in detail.

How do you clean up Microsoft 365?

Microsoft 365 is where most leftovers hide, because a filter in front of it touches several separate settings.

Connectors

In the Exchange admin center, go to Mail flow > Connectors. Look for the Partner inbound connector you created for the old service. Microsoft's guidance is to lock Exchange Online down so it accepts mail only from your filter, by restricting a Partner inbound connector to the filter's certificate or IP addresses (Microsoft Learn).

• If the new service has its own connector, delete the old one.
• If you added the new ranges to the old connector during the overlap, remove the old ranges or certificate name and rename the connector.
• Check that the remaining connector is still restricted, so direct delivery is rejected. Our guide to blocking direct-to-tenant bypass shows how to test it.

In PowerShell, Get-InboundConnector | Format-List Name,SenderIPAddresses,TlsSenderCertificateName,RestrictDomainsTo* lists what's there, and Remove-InboundConnector deletes a connector.

Enhanced Filtering, mail flow rules and allow lists

• Enhanced Filtering. In the Defender portal, go to Email & collaboration > Policies & rules > Threat policies > Enhanced filtering (or security.microsoft.com/skiplisting). Remove the old provider's ranges from Skip these IP addresses that are associated with the connector (Microsoft Learn).
• SCL -1 rules. Some setups bypass Microsoft's spam filtering for the old filter's IPs with a mail flow rule. Microsoft warns that "Most third-party cloud anti-spam providers share IP addresses among many customers. Bypassing scanning on these IPs might allow spoofed and phishing messages from these IP addresses." Delete any such rule.
• Connection filter IP Allow List. Check the anti-spam connection filter policy for the old ranges and remove them.

Trusted ARC sealers

If you added the old service as a trusted ARC sealer, remove it. Microsoft cautions: "Only add vendors that you actively use and trust. Adding unnecessary ARC sealers increases your attack surface because a compromised vendor could pass spoofed messages through your authentication checks" (Microsoft Learn).

Run Get-ArcConfig to see the list. Set-ArcConfig -Identity Default -ArcTrustedSealers replaces the whole list, so include every sealer you want to keep. Microsoft says changes can take up to 30 minutes.

Outbound connector

If the old provider relayed your outgoing mail as a smart host, there's an outbound connector from Office 365 to it. Point it at the new relay, or delete it if outbound mail now goes directly from Microsoft 365. Send a test message to an outside mailbox and check the path in the headers.

How do you clean up Google Workspace?

In the Admin console, go to Apps > Google Workspace > Gmail > Spam, Phishing and Malware > Inbound gateway (Google Workspace Admin Help).

1. Remove the old provider's ranges from Gateway IPs, leaving the new ones.
2. If Reject all mail not from gateway IPs is on, confirm the new ranges are complete before saving, or legitimate filtered mail will be rejected.
3. Check Message tagging. If you set a spam header for the old provider, update it to the new provider's header or clear it.
4. Check outbound routing. The Outbound gateway setting is under Gmail > Routing, and more complex setups use a route under Gmail > Hosts plus a routing rule (Google Workspace Admin Help). Remove or update any route to the old provider.

Google says these settings can take up to 24 hours to apply. Use Email Log Search afterwards to confirm inbound mail arrives from the new gateway only.

How do you clean up your own mail server?

For cPanel/WHM, Exchange Server or another self-hosted server:

• Firewall. Remove the old ranges from any rule that allows inbound TCP 25. Keep the new ranges.
• Trusted hosts. On cPanel/WHM, remove them from Trusted SMTP IP addresses and from SpamAssassin's trusted_networks. Our cPanel/WHM guide shows where these live.
• Exchange Server. Remove the old ranges from the internet-facing Receive connector's RemoteIPRanges, and update any Send connector that used the old provider as a smart host.
• Relay settings. If the server relayed outbound mail through the old provider, change the smart host and test.

How do you clean up DNS?

DNS is the last place to change, because outbound mail may still be in flight.

SPF

Microsoft's guidance is that you "would only need to include the third-party service in your SPF record if your organization sends outbound internet email through the service" (Microsoft Learn). Remove the old provider's include once nothing sends through it. That also frees one of SPF's ten DNS lookups; see too many SPF DNS lookups. Check the result with the SPF Checker.

DKIM

If the old provider signed your outbound mail, its selectors are published under your domain. Don't delete them on day one. Messages signed with those keys can still be in queues or be verified later.

1. Stop the old provider signing for you, and confirm new mail is signed by the new service. Look at d= and s= in the DKIM-Signature header.
2. After a week or two, revoke the old key by publishing the selector with an empty p= value. RFC 6376, section 3.6.1 says "An empty value means that this public key has been revoked."
3. Later, delete the record.

Our DKIM key rotation guide covers the same sequence in more detail, and the DKIM Checker confirms what's published.

Other records

Look for verification TXT records, CNAMEs for tracking or bounce domains, and DMARC report addresses that point at the old provider. Remove what's no longer used.

What should you do before canceling the account?

• Export logs and lists you may need later, such as allow and block entries or message history for an investigation.
• Remove your domains from the old account, so it stops accepting mail for them if anything still points there.
• Remove user accounts and API keys, and any administrator logins that are single sign-on linked to your directory.
• Confirm the contract end date, and that quarantine access lasts until users are done.

How do you confirm nothing still depends on the old filter?

1. Headers. Send messages from two or three outside providers and open them in the Email Header Analyzer. The hop before your mail server should be the new service only.
2. Direct delivery test. From an outside server, try to deliver straight to your mail server or tenant. It should be refused.
3. DNS. Run the Email Health Check and the MX Lookup. Look for old hostnames in MX, SPF and DKIM.
4. Outbound. Send to an outside mailbox and confirm SPF, DKIM and DMARC pass with the new path.

Next steps

1. Pick a date about a week after your MX change and book an hour for this checklist.
2. Export your Microsoft 365 connector, Enhanced Filtering and ARC settings, or your Google gateway settings, before you edit them, so you can roll back.
3. Clean up DNS last, and revoke old DKIM keys before you delete them.
4. If you're moving to iBlockSpam, the setup wizard lists the exact ranges and certificate name to keep, so it's clear which entries belong to the old service. The guided cutover plan covers the steps before this one.

If you haven't picked the replacement yet, our comparison pages set iBlockSpam against common filters, and our cutover plan covers the switch itself.

More guides on switching and migration.