DNS authentication checklist after migrating mailbox providers

Treat a mailbox migration as a multi-sender inventory change

Moving inboxes rarely means the old provider was the only system using the domain. Before editing DNS, inventory interactive mailboxes, transactional systems, support tools, billing mail, forms, and any outbound worker. Record which service owns MX, SPF authorization, DKIM selectors, Return-Path domains, and DMARC reporting. The purpose is to know which records can change together and which old paths must continue temporarily. A migration checklist that only says “change MX” is incomplete for a domain that sends mail from more than one platform.

Capture known-good headers before the cutover

Send test messages through every important path before changing nameservers or provider settings. Save From, Return-Path, Authentication-Results, and DKIM-Signature. These headers are a factual baseline of what the system actually used, including selectors and vendor domains that may not be obvious in a dashboard. When Monday's billing message behaves differently from the mailbox test, the pre-cutover evidence tells you whether billing was always on a separate path or whether the migration changed it unexpectedly.

Change SPF by editing the existing policy, not stacking a new one

If the new mailbox provider needs SPF authorization, update the domain's one SPF policy and preserve any still-active legitimate senders. Removing the old provider's mechanism should happen only after its final traffic is truly gone. Publishing a second `v=spf1` record as a temporary bridge can create `permerror` instead of graceful overlap. Also re-evaluate the policy's DNS-querying mechanisms because migrations often leave both old and new includes in place longer than intended.

Publish new DKIM selectors before expecting the new signer to pass

Create the new provider's DKIM DNS records and confirm them from authoritative DNS before enabling signing if the provider allows that order. Then send a fresh message and inspect the selector actually used. Keep old selectors during the overlap window while old systems may still sign delayed messages. Once the old path is retired and no rollback depends on it, remove obsolete records according to your change policy. Selector coexistence is normal; confusion about which selector is active is the real risk.

Re-check DMARC alignment for every message type

A migration can preserve raw SPF or DKIM passes while changing alignment. For example, the new provider may default to a vendor Return-Path or vendor signing domain until custom authentication is completed. Test mailbox mail, transactional mail, and any outbound route separately. Compare the authenticated domains with the visible From domain and confirm the intended DMARC outcome. If `p=none` reporting is in place, use aggregate data as additional inventory evidence, not as a substitute for fresh header tests.

Expect DNS caches but query authoritative answers first

Propagation is often discussed as a vague wait period, but troubleshooting should begin with the authoritative nameservers. Confirm that they serve the intended MX, TXT, and CNAME values. Then compare resolver views if necessary. If the authoritative answer is still old, waiting on public caches cannot fix the configuration. If authoritative DNS is correct but some resolvers show older data, TTL and cache behavior become relevant. This distinction keeps a migration from turning into hours of blind “propagation” waiting.

Retire old records only after an evidence-based overlap window

After cutover, monitor actual sending for several normal business cycles. Confirm that old provider traffic is gone from logs and DMARC/source observations before removing its SPF term or selectors. Label every retained record with an owner in your internal inventory so temporary overlap does not become permanent clutter. The final state should be simpler than the migration state: one intentional SPF policy, current selectors, explainable DMARC sources, and test headers that match the systems the business still operates.

Run an overlap window where old and new authentication can coexist

A migration is safer when the new path becomes valid before the old path is dismantled. Publish the new DKIM selector, update the existing SPF policy to authorize the new sender without removing the old sender prematurely, and verify the new provider can produce an aligned message. During the overlap window, send small controlled tests through both paths and save the headers. Only after production mail is consistently using the new route should retired mechanisms and selectors be removed. This is the same logic RFC 6376 uses for DKIM key rotation: concurrent publication avoids breaking messages that are still in flight. The overlap should be long enough to observe DNS propagation and real mail behavior, not an arbitrary number copied from a migration checklist.

Keep a post-cutover inventory so stale senders do not linger forever

Overlap reduces risk, but forgotten authorization creates a different problem: old providers remain allowed to send indefinitely. After the cutover stabilizes, compare DMARC aggregate reports, provider logs and actual headers to the pre-migration inventory. Remove an SPF include only after no legitimate stream depends on it. Retire an old DKIM selector after the signer has stopped using it and the transition window is complete. Check support addresses, transactional aliases and low-volume automation because they are the streams most likely to be missed during a sales-focused migration. Finish by documenting the final SPF, active selectors, DMARC policy and mailbox provider in one place. That record becomes the baseline for the next authentication incident instead of forcing the operator to rediscover the architecture from DNS alone.

Test low-volume aliases and reply paths after the main mailbox works

Migrations often validate the main outbound mailbox and miss support aliases, forwarding rules, automated notifications or reply-handling addresses that send only a few messages. Create a checklist of every address or service that can originate mail with the domain and trigger one controlled message from each. Confirm the expected DKIM selector, SPF identity and DMARC alignment, then verify that replies still arrive where the outbound automation expects them. A sales mailbox can pass perfectly while a low-volume alias silently fails DKIM and later damages aggregate authentication statistics. Treat the migration as complete only when the uncommon paths have been tested as well as the primary sender.

Field checklist

• Inventory all mail-sending systems, not only human inboxes.
• Save known-good headers from each sending path before the cutover.
• Edit the existing SPF policy; never bridge a migration with two SPF records.
• Publish and verify new DKIM selectors before relying on them.
• Test DMARC alignment separately for mailbox, transactional, and outbound traffic.
• Query authoritative DNS first and remove old records only after traffic proves they are unused.