Move an email provider safely

An email-provider migration changes several paths that can fail independently: inbound routing, mailbox acceptance, outbound submission, application senders, SPF authorization, DKIM signing, DMARC alignment, forwarding, filtering, archives, and queued messages. A new MX RRset alone does not complete the move.

Blast radius and owners

Control or service	Responsible owner
Mail domains, recipients, aliases, and groups	Messaging owner
MX and email-policy DNS records	DNS-zone owner
New mailbox and accepted-domain configuration	New receiving provider owner
Legacy mailboxes, forwarding, and queues	Old receiving provider owner
User and application submission	Identity and application owners
SPF, DKIM keys, and DMARC policy	Sending-domain security owner
Journaling, retention, compliance, and archives	Data-governance owner
Window, evidence, rollback, and communication	Migration owner and verifier

SMTP uses MX preference for delivery and defines behavior when no MX exists [1]. That routing decision is separate from user sign-in, message migration, outbound authorization, and inbox placement.

Prerequisites

• approved inventory of every mail domain and subdomain;
• new-provider acceptance for required domains, recipients, aliases, and groups;
• migrated messages and metadata to the required completeness;
• prepared user sign-in, recovery, clients, and support communications;
• identified applications, devices, relays, scanners, and third-party senders;
• new DKIM selectors and provider-supplied DNS values;
• reviewed coexistence and rollback periods covering DNS caches and mail queues;
• old-provider access, receiving, forwarding, and submission retained; and
• approved test recipients and sender accounts without sharing credentials.

Inventory and export

Capture:

• current MX RRset, priority, TTL, and every exchanger address;
• SPF records and all included or redirected policy domains;
• DKIM selectors, public keys, signing domains, and active sender classes;
• DMARC record, alignment modes, policy, percentage, and report destinations;
• provider-verification, autodiscovery, SRV, and client-configuration records;
• accepted domains, mailboxes, aliases, groups, routes, forwarding, and catch-all behavior;
• outbound SMTP hosts, ports, TLS modes, identities, and application owners;
• inbound connectors, allowlists, gateways, filters, journaling, and archives;
• message-migration scope, cut-off rule, and reconciliation owner;
• current deliverability baseline with full headers and provider queue IDs; and
• exact prior DNS RRsets and provider settings required for rollback.

Use the DNS Lookup pathway for timestamped MX and TXT observations. Use the Email Security Checker pathway to review public SPF, DKIM, and DMARC evidence. Neither tool proves mailbox readiness, signing behavior, or final delivery.

Preflight

1. Create every production recipient, alias, group, and required route at the new provider.
2. Verify an approved inbound test path before changing production MX when the provider supports a safe test method.
3. Verify user and application outbound submission, TLS, authentication, and envelope identity.
4. Confirm the new provider signs each intended sender class with the expected DKIM domain and selector. DKIM associates a signing domain with a cryptographic message signature [2].
5. Build one syntactically valid SPF policy that authorizes both old and new senders during coexistence. SPF evaluates an authorization policy for a checked identity; it is not MX routing [3].
6. Keep DMARC at the reviewed policy. Confirm new mail can align before increasing enforcement. DMARC evaluates identifier alignment and published sender policy [4].
7. Confirm the old provider will continue accepting and queuing mail throughout the previous MX TTL, retry window, and reconciliation period.
8. Lower TTL only if it was published and observed before the change window for at least the previous TTL.
9. Run approved end-to-end tests in both directions and preserve headers, timestamps, queue IDs, and SMTP results.
10. Confirm monitoring distinguishes DNS, SMTP connection, recipient acceptance, authentication, delivery, and placement.

Stop conditions

Stop before changing MX when:

• any production recipient or accepted domain is absent at the new provider;
• the complete MX and sender inventory is unknown;
• old-provider access, queues, forwarding, or rollback duration is unconfirmed;
• a required application cannot submit through either approved coexistence path;
• SPF would exceed provider or protocol constraints or omit a sender;
• DKIM signing or selector publication is unverified;
• DMARC alignment fails for an approved sender class;
• message migration or retention obligations are unresolved;
• test messages lack headers or provider queue evidence; or
• no owner can reconcile mail delivered to both providers.

During execution, stop deleting records or disabling the old service after the first unexplained rejection, defer, authentication failure, or missing message.

Ordered steps

1. Approve the recipient, sender, DNS, data, coexistence, verification, and rollback inventories.
2. Publish required new-provider verification and DKIM records without removing active old selectors.
3. Update SPF once to authorize the reviewed old and new sender sets.
4. Confirm DMARC reporting can distinguish the new provider; do not tighten policy as part of the migration.
5. Migrate mail and metadata according to the approved initial synchronization boundary.
6. Enable and test users, applications, relays, and approved third-party senders at the new provider.
7. Change the complete MX RRset once to the provider-supplied values. Do not mix arbitrary old and new MX values unless both providers explicitly support that routing design.
8. Keep the old provider active for cached senders, retries, late messages, and rollback.
9. Run the final synchronization and reconcile recipients, timestamps, counts, folders, and messages received during overlap.
10. Change clients and applications in controlled groups, preserving evidence for each sender class.
11. Observe through the documented MX cache, SMTP retry, and business-risk window.
12. Retire old routes, SPF mechanisms, DKIM selectors, accounts, and billing only after dependency and retention review.

Verification

Verify separately:

1. every authority and named resolver returns the intended MX RRset;
2. every MX target resolves and accepts SMTP for an approved recipient;
3. expected inbound messages reach the new mailbox with headers preserved;
4. users and applications submit through the intended host and TLS mode;
5. each sender class passes the intended SPF evaluation;
6. each sender class is DKIM-signed and the signature verifies;
7. DMARC alignment and policy evaluation match the approved design;
8. replies, forwarding, aliases, groups, calendars, and application workflows behave as scoped;
9. old-provider queues and mailboxes are empty or reconciled; and
10. no unrelated web or DNS service changed.

An approved test with the SMTP Tester pathway can capture transport evidence. Never provide production credentials to ClueDNS, and do not treat one successful message as proof of universal deliverability.

Rollback

• Keep both providers licensed, reachable, and able to accept mail until the rollback window closes.
• If inbound acceptance fails, restore the exact prior MX RRset once. The new MX can remain cached, so keep the new provider accepting mail too.
• If outbound authentication fails, restore the prior application submission path and preserve both providers in SPF until every active sender is known.
• Do not remove a new DKIM selector while messages signed with it may still be evaluated.
• Do not tighten DMARC during rollback. Restore the captured policy only when a policy change was part of the failed change.
• Export and reconcile messages received by either provider; DNS rollback does not move mail already accepted or queued.
• Re-run inbound, outbound, SPF, DKIM, DMARC, delivery, and placement verification after restoration.

Next step

Keep the old provider available until caches, queues, data reconciliation, and sender verification are complete. For any remaining symptom, use Diagnose email failure when the website works to separate DNS from SMTP, policy, mailbox, queue, and delivery evidence.