Map the identities on both sides

Record the visible From domain, SMTP MailFrom/return-path domain, DKIM signing domain and selector, sending IP ownership, message types, volumes, and bounce/complaint handling for the old service. Do the same for the new service using its approved account, not a salesperson’s generic example.

Check whether the new provider requires an SPF include for your MailFrom domain or uses its own domain. An include at the visible From domain may do nothing if SPF is evaluated against a different return path. If you configure a custom return path, verify ownership, DNS records, bounce routing, and DMARC alignment as one design.

Stage without removing proven authorization

Create the provider account with least privilege and verified domains. Publish DKIM using a new selector so it can coexist with the old key. If SPF must change, calculate the complete policy and lookup budget before publishing one consolidated record. Keep the old sender authorized while it still sends legitimate messages.

Lowering TTL immediately before a change only helps caches that fetch the lower TTL; it does not shorten older cached answers. Record timing rather than promising instant propagation.

Test the new path

Send each representative workflow to authorized accounts at relevant providers. Inspect the trusted Authentication-Results and record SPF identity/result, DKIM domain/selector/result, DMARC result, SMTP response, and observed folder. Exercise bounce and unsubscribe/suppression handling with safe test cases. A provider dashboard saying “domain verified” is not proof that the production application uses the intended identities.

Cut over with evidence

Choose a bounded cohort or low-risk stream first. Compare volume, bounces, complaints, authentication, latency, and placement observations with the baseline. Define a rollback trigger and retain the old path long enough to use it safely without sending duplicates.

After the old service is demonstrably idle, revoke its credentials, preserve legally and operationally required suppression data, remove obsolete SPF authorization, and retire DKIM keys after messages signed with them no longer need verification. Query DNS and repeat fresh message tests. The migration is complete when every current authorization maps to an active owner—not when the first message leaves the new provider.