How to switch spam filter providers without a gap in protection

Switching inbound filtering providers is an MX change with extra dependencies: your mail server trusts the old gateway, your users rely on its quarantine, and your allow and block lists live in its console. The safe approach is a short period where both gateways are trusted, then a clean removal of the old one.

What do you need to collect from the old provider?

Before you change anything, export or record:

1. Allow and block lists, at domain and user level. Note which entries rely on sender verification or authentication, and which are plain address matches.
2. Custom rules: attachment-type blocks, geographic rules, content rules, size limits.
3. Gateway IP ranges and TLS certificate names the old service delivers from. You need these to clean up later.
4. Outbound settings, if the old provider relayed your outgoing mail: smart host, DKIM selectors and SPF include.
5. Quarantine retention after cancellation, and how users reach it.
6. Contract end date. Avoid a hard stop that falls inside the overlap.

Clean the lists as you go. Old entries for retired partners, and broad entries such as whole free-mail domains, are worth dropping rather than carrying across.

What does the timeline look like?

RFC 5321 suggests senders keep retrying for "at least 4-5 days" (section 4.5.4.1), which is why the old path should stay open for about a week.

How do you set up the overlap on each platform?

Microsoft 365. Microsoft's guidance for a filtering service in front of Exchange Online uses a Partner inbound connector, ideally restricted by certificate or IP, plus Enhanced Filtering for Connectors (Microsoft Learn).

1. Create a second Partner inbound connector for the new service, or add its ranges to the existing one.
2. In Microsoft Defender portal > Email & collaboration > Policies & rules > Threat policies > Enhanced filtering, add the new service's ranges on that connector, so both gateways are skipped (Microsoft Learn).
3. If the old connector restricts by certificate or IP (RestrictDomainsToCertificate or RestrictDomainsToIPAddresses), mail from the new gateway must match a connector too. Give the new service its own restricted Partner connector with its certificate or ranges, and test delivery from both gateways before the MX change.
4. Remove any SCL -1 mail flow rule tied to the old service.

Google Workspace. In Apps > Google Workspace > Gmail > Spam, Phishing and Malware > Inbound gateway, add the new service's ranges to Gateway IPs next to the old ones (Google Workspace Admin Help). If Reject all mail not from gateway IPs is on, both sets must be listed before the MX change. Allow up to 24 hours for settings to apply.

cPanel/WHM. Add the new ranges to Trusted SMTP IP addresses and to SpamAssassin's trusted_networks, and to any port 25 firewall allowlist (cPanel docs).

How do you make the switch?

1. Import lists and rules into the new service. Prefer approved-sender entries that require sender verification over plain address allows.
2. Confirm the mail server trusts both gateways (above).
3. Change MX to the new hosts in one edit. Don't keep the old provider listed as a backup MX.
4. Send tests from several outside providers. Check headers with the Email Header Analyzer.
5. If the old provider handled outbound mail, switch your smart host, publish new DKIM keys and update SPF (RFC 7208), keeping within SPF's 10 DNS-lookup limit. Check with the SPF Checker and DKIM Checker.

How do you keep quarantine continuity?

Users don't care which provider holds a message; they care that they can find it.

• Tell users the date of the switch and that digests will come from a new sender. Add that sender to your own allow list.
• For the overlap, messages held before the switch are in the old quarantine; new ones are in the new quarantine.
• Ask the old provider how long quarantine access lasts after cancellation. Review and release anything important before then.
• Keep an admin login to the old console until the contract ends.

How do you tell users and partners?

A short message a few days before the switch prevents most support tickets:

• What changes: quarantine digests will come from a new sender, and the link inside goes to a new quarantine.
• What doesn't: how they sign in, send mail, or use their mail client.
• Where to look: messages held before the switch date are in the old quarantine until a stated date.
• Who to contact if something expected doesn't arrive.

Partners who send to you don't need to do anything, because they follow your MX. The exception is a partner who delivers to a fixed host or IP, such as an old smart host route set up years ago. Their mail would bypass the new filter, or fail once you lock down. If your old provider's logs show mail from a partner that never touched MX, ask them to switch to normal MX delivery.

How do you clean up?

After the old service's traffic has stopped:

1. Remove the old ranges from the Microsoft 365 connector and Enhanced Filtering, or delete the old connector.
2. Remove them from Google's Gateway IPs.
3. Remove them from cPanel trusted lists and firewall rules.
4. Remove the old SPF include and DKIM selectors if they were only used for outbound relay.

Leaving old ranges trusted is a quiet risk: if the old provider's IPs are later used by others, they would still be trusted by your server.

How do you roll back?

Keep the old connector, gateway IPs and trusted entries in place until cleanup. If the new service has a problem, point MX back to the old provider with a short TTL. Because your mail server still trusts both gateways, nothing else needs to change. Keep the new service active until its queue has drained.

What are the common mistakes?

• Removing the old gateway's trust on day 0. Mail it had already accepted, or deferred, is then refused.
• Forgetting restricted connectors. A Partner connector restricted to the old gateway rejects the new one.
• Not lowering the TTL. Mixed routing lasts as long as the old TTL.
• Copying lists without review. Ten-year-old allow entries are a common way phishing gets through.
• Canceling before users have checked the old quarantine.

How iBlockSpam helps

The iBlockSpam setup wizard shows your exact MX hosts, gateway IP ranges and certificate name, alongside your current DNS, so the overlap configuration is clear. Approved and blocked sender lists can require sender verification, which is a good time to tighten entries carried over from your old provider. Users get a personal quarantine with scheduled digests, and admins get a shared domain quarantine. Message history is kept for 30 days. If you also want outbound relay, it includes DKIM signing and 500 messages per month per domain. iBlockSpam can't import another provider's quarantine; release what you need from the old service before it ends.

Next steps

1. Write down your current MX, SPF and DMARC records and lower the MX TTL a day ahead.
2. Ask your old provider how long quarantine access lasts after cancellation.
3. Follow the guided cutover plan, and check the change with the MX Lookup.

Still choosing where to move? Our comparison pages cover common providers, including Mimecast, SpamTitan and, for MSPs, N-able Mail Assure and SpamExperts.

See our other switching and migration guides.