Email Security Gateway Migration Playbook

Replacing an email security gateway touches DNS, sender authentication, TLS policy, mail routing and dozens of filtering rules at once, and a migration done as a simple MX swap usually ends with lost mail, broken DMARC alignment, or an old gateway path that attackers can still use to deliver straight to mailboxes. Organisations move gateways when contracts end, when consolidating after a merger, or when shifting from an inline gateway to filtering built into the mail platform or added through an API. This playbook covers moving from one email security gateway to another, or retiring one: what has to move besides filtering rules, how to choose a cutover pattern, the order of DNS and authentication changes, translating policy, the identities the gateway holds, rollback, and switching the old path off. It is vendor-neutral and based on the IETF email standards and NIST guidance. The underlying architecture is explained in the Email Security Guide; this page does not repeat it.

Key takeaways

Inventory everything the gateway touches. MX records, SPF includes, DKIM selectors, MTA-STS policy, connectors, allow lists, quarantine, journaling and API permissions all carry state that must move or be removed.
Sequence DNS changes, do not batch them. Publish the new gateway in SPF and MTA-STS before it receives or sends any mail, and remove the old one only after traffic has drained.
Translate policy by intent. Old allow lists, bypass rules and sender exceptions are where most gateways are weakest; a migration is the cheapest moment to drop them.
The gateway is a privileged identity. Its API access to mailboxes, SMTP relay credentials and admin accounts must be recreated with least privilege and the old ones revoked.
Close the old path explicitly. Until the mail platform rejects delivery from anything except the new gateway, the old gateway's IPs and the platform's own endpoint remain a bypass.

What has to move

A gateway holds more state than its filtering policy. Build the migration inventory by object type and assign an owner to each row before choosing dates.

Object	Migration approach	Watch for
MX records and their TTLs	Lower TTL days ahead, then repoint per domain	Forgotten parked or acquired domains still pointing at the old gateway
Inbound connector or allow rule on the mail platform	Add the new gateway before cutover; remove the old one at decommission	Platform still accepting direct delivery from any source
Outbound smart host and relay	Repoint outbound routing per sending source	Applications, printers and scanners that relay through the old gateway by IP
SPF record	Add the new include before outbound cutover, remove the old after	The RFC 7208 limit of 10 DNS-querying terms; exceeding it returns permerror
DKIM signing keys and selectors	New selector and key for the new gateway, published before it signs	Old selectors left published with keys the old provider still holds
MTA-STS policy and TLS-RPT	Update mx list and policy id before MX changes	Senders deferring mail to MX hosts not in a cached enforce policy
Enforced TLS partner rules	Recreate per partner domain with certificate checks	Partners who pinned the old gateway's IPs or certificate
Filtering policies (attachment, URL, impersonation, DLP)	Translate by intent, then test with real samples	Defaults on the new platform that are weaker than the tuned old policy
Allow lists, block lists, bypass rules	Re-justify every entry; carry only those with an owner and reason	Whole-domain allow entries and bypasses on shared provider IPs
Quarantine, user digests, report button	Recreate release rights; plan the end of old quarantine access	Users releasing from an old quarantine after cutover
Journaling and archiving feeds	Confirm capture continues on the new path before cutover	A gap in the compliance record during the switch
Post-delivery remediation API access	New application grant with least privilege	Old provider's mailbox read and delete permission left in place
Logs and message trace history	Export or retain for the required period before contract end	History needed for an investigation gone with the old tenant

The Email Sending Sources Inventory Template is a good starting point for the outbound half of this list, because every system that relays mail must be repointed or will fail.

Choosing a cutover pattern

There is no single right pattern; the choice depends on domain count, mail volume and how much the two platforms can run side by side.

Pattern	How it works	Choose it when	Trade-off
Single MX switch	Repoint all MX records to the new gateway in one change window	One or a few domains, modest volume, simple policy	Fastest; all problems appear at once and rollback is a DNS change bounded by TTL
Domain by domain	Move low-risk domains first, main domain last	Many domains, acquired brands, regional mail	Two platforms run for weeks; policy drift between them must be managed
Inbound first, outbound later	Switch MX, keep outbound through the old gateway, then move outbound	Outbound has many relaying applications or partner TLS rules	SPF and DKIM must cover both gateways during the overlap
Chained (new gateway in front of old, or behind)	Mail passes through both for a period	You need a comparison of verdicts before trusting the new platform	Double processing can break DKIM; ARC helps receivers but is an Experimental RFC
Retire inline gateway for platform or API filtering	MX points at the mail platform; filtering is native or API-based	Cloud-only mail where the inline hop adds little	Different detection model (post-delivery); see the Email Security Guide comparison

Decision guidance: a small organisation with one domain usually does best with a single switch after a short pilot on a test domain. A large organisation with dozens of domains, regional mail and many relaying systems should move domain by domain and inbound first, so each problem is small. Avoid chaining for longer than the comparison needs: two gateways in series double the routing, the false positives and the places where policy can drift.

DNS and authentication sequencing

Most migration outages come from changing DNS records in the wrong order. Keep to this sequence for each domain.

Lower TTLs: reduce MX, SPF and MTA-STS TXT record TTLs at least one full old TTL period before the change, so rollback is fast. Raise them again once stable.
SPF first: add the new gateway's include or IP ranges before it sends a single outbound message. Count DNS-querying terms: RFC 7208 section 4.6.4 caps include, a, mx, ptr, exists and redirect at 10 per evaluation, and also limits void lookups to two by default. A record over the limit returns permerror, which receivers can treat as a failure.
DKIM by selector: RFC 6376 uses selectors so a domain can run several keys at once and rotate them. Publish a new selector for the new gateway, start signing with it, and remove the old selector's record only after the old gateway has stopped signing and in-flight mail has been delivered. Use a fresh key pair; never import the old provider's private key.
MTA-STS before MX: RFC 8461 tells senders in enforce mode not to deliver to hosts that fail MX matching. Senders cache the policy for up to max_age and only refetch when the _mta-sts TXT record id changes. Add the new gateway hostnames to the policy mx list, publish the HTTPS policy first, then change the TXT id, and only then change MX. A practical option is to switch to testing mode for the cutover window and back to enforce once stable.
TLS-RPT on: RFC 8460 reports such as certificate-host-mismatch and sts-policy-invalid will show senders failing against the new gateway. Make sure the _smtp._tls rua address is monitored during the migration.
DMARC reports watched: aggregate reports show alignment failures by sending source within a day. A spike after outbound cutover usually means a missing SPF include or an unsigned stream. See the DMARC, SPF and DKIM Failure Troubleshooting Guide.
MX last: repoint MX, keeping the old gateway able to accept mail until the old TTL has expired and traffic has drained.

Translating policy

Gateways express policy differently, and no export format moves cleanly between them. The goal is the same protection, or better, not an identical rule list.

Translate intent, not syntax: for each rule, record what it protects against, the owner and the evidence it still matters. Rebuild it in the new platform's model.
Re-justify allow lists: every sender or domain allow entry overrides detection. Carry only entries with a named owner and a reason, and prefer authenticated allow rules (aligned DKIM or a verified connector) over IP or display address entries.
Drop bypasses on shared IPs: many security services share sending IPs across customers, so a bypass for a provider's IP range admits anyone else using it.
Start from the new platform's strict preset: then add exceptions as evidence appears, rather than loosening it to match the old one on day one.
Test with a sample library: keep a set of known-bad attachments, URLs and impersonation samples (handled safely) and known-good business mail, and run both through the new gateway in a pilot before cutover.
Preserve attachment controls: CIS Safeguard 9.6 asks organisations to block unnecessary file types; confirm the new platform blocks the same types, including inside archives.

Where identity fits

An email security gateway is a non-human identity with some of the broadest access in the organisation. Treat each of its credentials as part of the migration scope.

Mailbox API grants: post-delivery remediation needs permission to read and delete messages in every mailbox. Grant the new platform only the permissions it documents as required, record the grant and its approver, and revoke the old platform's grant on decommission day. See the AI Agent Email Access Security guide for how broad mailbox permissions are abused.
Connector trust: prefer certificate-based connector trust over IP lists, so the platform only accepts mail from your tenant on the new gateway, not from any customer of the same provider.
SMTP relay credentials: applications that authenticate to the old gateway with a username and password or API key need new credentials, stored in a secrets manager, and the old ones disabled.
Admin accounts: provision gateway administrators through SSO with phishing-resistant MFA, and delete local admin accounts on the old console once logs are exported.

The Email security gateway integration security guide covers these integrations in steady state.

The phased playbook

Phase 0, inventory and baseline: complete the object inventory, list every sending source, and record baseline metrics for 30 days (daily volume, block rate, user-reported phishing, false positive releases, DMARC pass rate).
Phase 1, build and harden the new gateway: SSO for admins, logging to the SIEM, quarantine and release roles, journaling capture, strict preset policy.
Phase 2, pilot: route a test or low-volume domain, or a pilot group of mailboxes, through the new gateway. Run the sample library and compare verdicts with the old gateway for at least two weeks (our recommendation).
Phase 3, authentication records: SPF, DKIM selector, MTA-STS mx list and TLS-RPT for all domains, following the sequence above.
Phase 4, inbound cutover: repoint MX per wave. Watch queue depth, TLS-RPT failures and user reports hourly for the first day.
Phase 5, outbound cutover: repoint the smart host and each relaying system. Watch DMARC reports and partner TLS rules.
Phase 6, lock and drain: restrict the mail platform to accept inbound mail only from the new gateway, and set the old gateway to reject or alert on any mail it still receives.
Phase 7, decommission: see below.

Rollback

Define the trigger in advance: for example mail queued for more than 30 minutes, or a false positive release rate above twice baseline for a business day (our recommendation), and name who decides.
Keep the old path live until the end of the freeze: rollback is an MX change bounded by the TTL you lowered, plus restoring the connector, which only works if the old gateway has not been switched off.
Never roll back by opening a bypass: pointing MX directly at the mail platform "temporarily" removes filtering for everyone.

Decommissioning the old gateway

Remove its IPs from connectors and SPF: any IP range left in an inbound allow or in SPF still lets that provider's infrastructure deliver or send as you.
Delete old DKIM selectors: once in-flight mail has been delivered, remove the selector records so the old provider's keys cannot sign for your domain.
Revoke API grants and credentials: mailbox access, SIEM tokens, directory sync accounts and relay credentials issued to or by the old gateway.
Export logs and quarantine for retention: keep message trace and audit history for the retention period your policy sets (NIST SP 800-53 AU-11) before the tenant is closed.
Sanitise on-premises appliances: local queues, quarantine and certificates hold mail content and private keys; sanitise following NIST SP 800-88 Rev. 2 and record it (MP-6). Revoke the old gateway's TLS certificates.
Get written confirmation of data deletion: from a hosted provider, under the contract's exit terms.

Detection and measurement

Metric or signal	Why it matters	Target (our recommendation)
Inbound mail delivered without passing the new gateway	Detects direct-to-platform bypass	Zero after Phase 6
Mail received by the old gateway after cutover	Stale MX caches, missed domains or a back door	Zero for 14 days before decommission
DMARC pass rate by sending source	Shows missing SPF includes or unsigned streams	At or above baseline within 7 days
TLS-RPT failure count	MTA-STS or certificate mismatch on new MX hosts	No sustained failures
User-reported phishing that reached inboxes	Detection parity with the old platform	At or below baseline
Allow list entries without owner and reason	Shows policy carried over without review	Zero

Message trace queries for these signals are covered in the Email Gateway and Message Trace Detection Guide. Also watch for new inbox forwarding rules (ATT&CK T1114.003) during the migration window, when users and attackers both know filtering is in flux.

Common failure patterns

Platform still accepts direct delivery: the new gateway is in place but the mail platform accepts mail from anywhere, so attackers deliver around it.
SPF over the lookup limit: adding the new include without removing anything pushes the record past 10 lookups, and outbound mail starts failing DMARC.
MTA-STS left stale: enforce mode with the old mx list causes senders to defer mail to the new gateway until the cached policy expires.
Allow lists copied wholesale: years of exceptions move across and override the new platform's detection.
Old mailbox API grant never revoked: a departed provider retains read and delete rights over every mailbox.
Relaying devices forgotten: a finance system or scanner keeps sending through the old gateway until its contract ends and invoices stop arriving.

Framework mapping

Activity	NIST SP 800-53 Rev 5	NIST CSF 2.0	CIS Controls v8.1
Spam and malware filtering on the new path	SI-8, SI-3	DE.CM-01	9.7
Attachment and file type policy	SI-3	PR.PS-01	9.6
Sender authentication records	SC-8	PR.DS-02	9.5
Transport TLS policy (MTA-STS, TLS-RPT)	SC-8	PR.DS-02	Not mapped
Routing changes and rollback	CM-3	PR.PS-01	Not mapped
Gateway API and admin access	AC-6, IA-5	PR.AA-05	Not mapped
Log retention and sanitisation	AU-11, MP-6	PR.DS-01	Not mapped

Practitioner checklist

Inventory every domain, MX, connector, sending source, selector, policy, allow list and API grant the old gateway uses.
Lower DNS TTLs before any change and record the rollback steps for each domain.
Add the new gateway to SPF within the 10-lookup limit and publish a new DKIM selector before it sends.
Update the MTA-STS mx list and policy id before changing MX, and monitor TLS-RPT.
Translate policy by intent, start from the strict preset and re-justify every allow list entry.
Grant the new platform least-privilege mailbox access and certificate-based connector trust.
Pilot with a sample library and compare verdicts before production cutover.
Lock the mail platform to accept mail only from the new gateway.
Revoke the old gateway's API grants, credentials, selectors and IP entries, and export logs for retention.
Sanitise any on-premises appliance and obtain written deletion confirmation from a hosted provider.

Email security gateway migration playbook: switch mail filtering without losing mail or control