An email platform migration changes the systems that receive, send, store and authenticate an organisation's mail all at once, and every one of those changes can silently lose messages, break sender authentication or leave an old, still-reachable mail system holding years of data and live credentials. Organisations move mail platforms when an on-premises mail server reaches end of support, when they move to or between hosted mail services, after a merger or divestiture, or when they consolidate several domains onto one platform. This playbook covers the security side of that move: mail flow and DNS sequencing, SPF, DKIM, DMARC and MTA-STS through the cutover, mailbox data and its permissions, the administrative and application identities that come with a mail platform, and decommissioning the old one. It is vendor-neutral and based on the SMTP, SPF, DKIM, DMARC and MTA-STS standards and NIST SP 800-177 Rev. 1, Trustworthy Email. Replacing a filtering gateway only is covered in the Email security gateway migration playbook, and moving between tenants of the same hosted service in Tenant-to-Tenant Migration Security.
Key takeaways
- Authenticate the new platform before it sends. Add the new platform to SPF and publish its DKIM keys before any outbound mail moves, or DMARC enforcement will quarantine or reject your own mail.
- Change MTA-STS before MX. Under an enforce policy, senders refuse to deliver to MX hosts not listed in your cached policy.
- Mailbox data carries its permissions. Delegation, forwarding rules and shared mailbox access move with the data and often move badly; review them rather than copying them blind.
- Migration tooling is a privileged identity. Accounts with impersonation or full-access rights to every mailbox are the most dangerous credential in the project; scope them, time-box them and remove them.
- The old platform is not off until it is gone. Legacy mail servers and tenants left reachable keep accepting logons and holding data long after the cutover.
What has to move
| Component | Migration approach | Watch for |
|---|---|---|
| Inbound mail flow (MX records) | Lower TTLs in advance, then switch MX to the new platform or route through it | Senders retrying to the old MX for days; old host still accepting mail |
| Outbound mail flow and relays | Move user mail first, then applications and devices that relay through the old server | Printers, scanners, monitoring tools and line-of-business apps using SMTP relay with hard-coded hostnames |
| Sender authentication (SPF, DKIM, DMARC) | Add new platform, publish new DKIM selectors, monitor DMARC reports, then remove the old platform | SPF lookup limit exceeded; DKIM keys left published for retired platforms |
| Transport security (STARTTLS, MTA-STS, TLS-RPT) | Update MTA-STS policy for new MX names before the MX change; valid certificates on new MX hosts | Enforce mode blocking delivery to unlisted MX hosts |
| Mailbox content, calendars, contacts | Staged or cutover migration through the platforms' migration interfaces | Partial copies, item size limits, archives and journals left behind |
| Permissions and delegation | Rebuild from a reviewed list; do not copy blindly | Stale full-access and send-as rights, external forwarding rules |
| Shared, resource and service mailboxes | Recreate with owners and sign-in rules decided | Shared mailboxes with interactive sign-in enabled and a known password |
| Transport rules, retention and holds | Translate by intent; re-apply legal holds before source data is deleted | Holds that do not survive the move, breaking legal or regulatory retention |
| Client and application integrations | New app registrations or credentials on the target; retire old ones | Legacy protocols (POP, IMAP, basic authentication) re-enabled for one old app |
| Logs and message traces | Export and archive the source logs for their retention period | Evidence lost when the old platform is shut down |
Mail flow and DNS sequencing
SMTP is forgiving in ways that hide migration mistakes. RFC 5321 section 4.5.4.1 recommends senders wait at least 30 minutes between retries and says the give-up time generally needs to be at least 4 to 5 days, so a sender holding mail for your domain may keep retrying the old MX for days. Section 5.1 says lower MX preference values are tried first and that, where MX records exist, senders must not fall back to the domain's address records. Both facts matter during the switch.
- Lower TTLs: reduce MX, SPF, DKIM and MTA-STS TXT record TTLs at least one full old TTL before the change.
- Prepare the target: accept mail for every domain and subdomain, including addresses only used by applications, and confirm the new MX hosts present valid certificates for their names.
- Update MTA-STS first: RFC 8461 says in enforce mode senders must not deliver to hosts that fail MX matching, certificate validation or STARTTLS, and that a non-expired cached policy is applied when no live policy can be fetched. Add the new MX names to the policy file, then change the policy id in the _mta-sts TXT record (section 8.1: update the HTTPS policy before the TXT record), and wait for the TXT TTL before switching MX. During a complex move, testing mode is an option, as long as you return to enforce afterwards.
- Switch MX: point MX to the new platform. Keep the old platform accepting and forwarding mail for at least the 4 to 5 day retry window (our recommendation: two weeks).
- Remove old MX names from MTA-STS: only after the old hosts are out of the MX set and the policy max_age has been considered, since senders may cache the policy for up to max_age seconds.
The transport security background is in the SMTP Security, STARTTLS and MTA-STS Guide.
SPF, DKIM and DMARC through the cutover
| Control | Before outbound moves | During overlap | After the old platform is gone |
|---|---|---|---|
| SPF (RFC 7208) | Add the new platform's include or IP ranges | Both platforms authorised; count DNS lookups | Remove the old platform and any includes no longer used |
| DKIM (RFC 6376) | Publish the new platform's public keys under new selectors and turn on signing | Both selectors published | Remove the old selector records once no mail is signed with them |
| DMARC (RFC 9989) | Keep the existing policy; watch aggregate reports for the new platform's sources | Confirm alignment for every sending source | Keep or raise enforcement; do not relax to p=none as a shortcut |
| MTA-STS (RFC 8461) | Add new MX names; new policy id | Both sets of MX names listed | Remove old MX names; new policy id |
- SPF lookup limit: RFC 7208 section 4.6.4 caps include, a, mx, ptr, exists and redirect at 10 DNS lookups in total; exceeding it returns permerror, which DMARC treats as a failure. Adding a new platform's include during overlap is a common way to cross the limit.
- DKIM selectors: RFC 6376 section 3.1 uses selectors so a domain can publish several keys at once. Give the new platform its own selector and key; never reuse the old platform's private key.
- DMARC status: RFC 9989, published in May 2026 as a Proposed Standard, obsoletes RFC 7489. It removes the pct tag and adds a t (testing) tag, so do not plan a migration around stepping pct up and down. See the DMARCbis Changes Guide.
- Inventory sending sources: marketing platforms, ticketing tools and applications send as your domain too. Use DMARC aggregate reports and the Email Sending Sources Inventory Template to find them before you remove anything.
The mechanics are in the DMARC, SPF and DKIM Guide, and troubleshooting in the DMARC, SPF and DKIM Failure Troubleshooting Guide.
Mailbox data, permissions and retention
- Review delegation before copying: export full-access, send-as and send-on-behalf rights from the source and have owners confirm them. Use the Mailbox Delegation Review Checklist.
- Find forwarding and inbox rules: attackers use forwarding rules for persistence (MITRE ATT&CK T1114.003, Email Forwarding Rule). A migration that copies rules can copy an attacker's rule to the new platform. See How to Audit Mailbox Forwarding and Inbox Rules.
- Decide on shared and service mailboxes: set an owner, disable interactive sign-in where it is not needed, and remove known passwords. See How to find shared mailboxes and service mailboxes with sign in enabled.
- Preserve legal holds and retention: re-apply holds and retention policies on the target and confirm them before deleting source data. Archives and journals are often a separate migration; see the Email Archiving and Journaling guide.
- Protect data in transit: migration traffic should use encrypted protocols end to end (NIST SP 800-53 SC-8). Staging copies on intermediate storage need the same protection as the mailboxes and a deletion date.
Where identity fits
A mail platform comes with a cluster of non-human identities, and the migration adds the most powerful one of all.
- Migration service account: needs read access to every source mailbox and write access to every target mailbox. Create it for the project, restrict its sign-in to the migration hosts, use application permissions scoped to the mailboxes in the current wave where the platform allows, alert on use outside migration windows, and delete it at the end.
- Application and device senders: SMTP relay accounts, API keys for sending services and app registrations with mail permissions. Re-issue rather than copy credentials, and prefer modern authentication over basic authentication. Mail-sending keys are a frequent leak; see the SendGrid, Mailgun and Mailchimp API Keys Security Guide.
- Administrators: map old administrative roles to the target's least-privilege roles (NIST SP 800-53 AC-6), require phishing-resistant MFA, and remove administrative accounts on the old platform when it is retired.
- Agents and integrations: any AI assistant or automation with mailbox access needs new, scoped consent on the target. See the AI Agent Email Access Security guide.
The phased playbook
- Inventory: domains, MX and DNS records, sending sources, relays, mailboxes by type, delegation, forwarding rules, transport rules, retention and holds, integrations and admin accounts.
- Design the target: admin roles, authentication policy (no legacy protocols by default), transport security, filtering, retention, and the migration identity with its scope.
- Authenticate the target: SPF include, DKIM selectors and signing, MTA-STS policy update, valid certificates on MX hosts. Confirm with test messages that SPF, DKIM and DMARC pass to external receivers.
- Pilot: move a pilot group of mailboxes, including a shared mailbox and an application relay. Test send, receive, delegation, mobile clients, retention and a rollback.
- Migrate mailboxes in waves: pre-stage content, then cut over each wave. Review permissions per wave rather than in one bulk copy.
- Switch inbound mail: MTA-STS first, then MX. Keep the old platform accepting and forwarding mail through the retry window.
- Move applications and relays: one by one, with an owner sign-off and new credentials for each.
- Decommission: block sign-in to the old platform, remove its MX, SPF and DKIM entries, export and archive logs, confirm holds on the target, then delete data and sanitise storage following NIST SP 800-88 Rev. 2.
Rollback: until source mailboxes are deleted, rollback means switching MX back (the old platform must still accept mail for your domains), reverting client configuration and synchronising any mail received on the target back to the source. Keep the old platform in a receive-capable, sign-in-restricted state until the final wave is signed off.
Small and large organisations: a small organisation with one domain and a few hundred mailboxes can often use a single cutover weekend. Large estates with many domains, hybrid coexistence and thousands of application senders need staged waves, longer overlap and a dedicated sending sources inventory.
Detection and measurement
| Metric or signal | Why it matters | Target (our recommendation) |
|---|---|---|
| DMARC pass rate by sending source, from aggregate reports | Shows sources not yet authenticated on the new platform | All legitimate sources aligned before the old platform is removed |
| Inbound mail still arriving at the old MX | Senders retrying or cached records | Falling to zero within the retry window |
| TLS-RPT failure reports after the MX change | MTA-STS or certificate mismatch on new MX hosts | Zero sustained failures |
| Migration account sign-ins outside migration windows or hosts | Misuse of an all-mailbox credential | Zero; alert on any |
| Mailboxes with external forwarding on the target | Copied or new exfiltration rules | Only approved exceptions |
| Sign-ins to the old platform after decommission date | A live legacy system | Zero; block, then investigate |
Collect message traces, admin audit logs and sign-in logs from both platforms in one place during the overlap; the Email Gateway and Message Trace Detection Guide covers what to look for.
Common failure patterns
- DMARC rejecting your own mail: outbound mail moves before the new platform is in SPF and signing with an aligned DKIM key.
- MX changed before MTA-STS: senders with a cached enforce policy refuse to deliver to the new hosts, and mail queues for days.
- Permissions copied wholesale: years of stale full-access rights and an attacker's forwarding rule arrive on the new platform.
- Migration account left in place: an account with access to every mailbox outlives the project.
- Old tenant or server left reachable: the Microsoft Midnight Blizzard breach began with a forgotten legacy test tenant and led to executive mailboxes. Old mail systems need the same full decommissioning.
- Relays forgotten: devices and applications keep sending through the old server, which is kept alive with basic authentication "for now".
Framework mapping
| Activity | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | MITRE ATT&CK |
|---|---|---|---|
| Mailbox and admin account management | AC-2, AC-6 | PR.AA-05 | T1078 |
| Transport encryption and MTA-STS | SC-8 | PR.DS-02 | |
| Filtering on the new platform | SI-8 | DE.CM-09 | |
| Forwarding and inbox rule review | AC-2 | PR.AA-05 | T1114.003 |
| Migration change control | CM-3 | PR.PS-01 | |
| Log retention and old platform decommissioning | AU-11 | ID.AM-08 |
CIS Controls v8.1 Control 9 (Email and Web Browser Protections) covers the mail filtering and DMARC side; see the CIS Control 9 Email and Web Browser Protections Guide.
Practitioner checklist
- Lower DNS TTLs and inventory every domain, sending source and relay before the change.
- Add the new platform to SPF, keep under 10 DNS lookups, and publish new DKIM selectors before outbound moves.
- Update the MTA-STS policy and id before switching MX; remove old MX names only afterwards.
- Keep the old platform accepting mail through the SMTP retry window.
- Review delegation, forwarding and inbox rules instead of copying them.
- Scope, monitor and delete the migration service account.
- Re-issue credentials for application senders and keep legacy protocols off.
- Confirm holds and retention on the target before deleting source data.
- Block sign-in, remove DNS entries, archive logs and sanitise storage on the old platform.
Standards and references
- IETF: RFC 5321, Simple Mail Transfer Protocol
- IETF: RFC 7208, Sender Policy Framework (SPF)
- IETF: RFC 6376, DomainKeys Identified Mail (DKIM) Signatures
- IETF: RFC 9989, Domain-based Message Authentication, Reporting, and Conformance (DMARC)
- IETF: RFC 8461, SMTP MTA Strict Transport Security (MTA-STS)
- NIST: SP 800-177 Rev. 1, Trustworthy Email
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls
- NIST: SP 800-88 Rev. 2, Guidelines for Media Sanitization
Related NHI Mgmt Group resources: Exchange Web Services Retirement · Email Security Guide · Collaboration suite migration playbook · Email Security Policy Template