Moving authoritative DNS changes where resolvers obtain the domain's data. A successful nameserver change does not prove that SPF, DKIM, DMARC or receiving routes survived. Preserve the effective records and dependencies before changing delegation, and keep both old and new service available while caches can use either.
Inventory the effective zone
References: RFC 1034 §4.2, RFC 1035 §3.3.14, RFC 6376 §3.1.
Identify the current parent delegation and all authoritative servers. Obtain an authorized export or API inventory from the actual DNS host. An ordinary query cannot enumerate every possible DKIM selector, so combine the export with sending-service configuration and recent signed-message headers. Include apex SPF, DMARC, active and retiring selectors, custom return-path records, MX, their address dependencies, and transport-policy records where deployed.
Record exact owner names, types, TTLs and values. Preserve TXT resource-record boundaries and string fragments. Inventory aliases and child delegations rather than copying only the terminal value seen by a recursive lookup. Provider features such as flattening or managed records need an explicit equivalent at the destination; they may not survive a basic zone-file export.
Build the destination before switching
References: RFC 4034 §5, RFC 4035 §2.4.
Import the reviewed data into the destination, inspect the diff and query each new authoritative server directly. Its SOA and apex NS values may intentionally differ from the old provider; authentication data should differ only where the migration plan explicitly authorizes a change. Check that relative-name input did not duplicate the zone suffix.
For signed zones, coordinate the parent DS and child DNSKEY transition with the providers' supported migration procedure. Copying ordinary records without coordinating DNSSEC can make a validating resolver reject otherwise visible data. Do not delete the DS or disable validation as an improvised default. Determine the exact continuity or transition procedure before scheduling the move.
Reproduce a missing-selector failure
Use an isolated lab zone named example.test. The old authority has example.test. 300 IN TXT "v=spf1 -all", _dmarc.example.test. 300 IN TXT "v=DMARC1; p=none" and s1._domainkey.example.test. 300 IN TXT "fixture=selector-present". The last value is a marker, not a DKIM key. Prepare a destination copy that deliberately omits s1.
Run dig @OLD_IP s1._domainkey.example.test. TXT +norecurse and dig @NEW_IP s1._domainkey.example.test. TXT +norecurse, substituting lab server addresses. The expected comparison identifies the missing marker at the new authority. Restore it, repeat all exact owner/type queries and retain the before-and-after answers. This fixture tests inventory completeness, not a valid DKIM signature.
Switch and observe both paths
References: RFC 1034 §4.2, RFC 2308 §5, RFC 8767 §4.
Lower applicable TTLs sufficiently in advance if the supported plan calls for it; old cached TTLs are not shortened retroactively. RFC 8767 also permits bounded stale serving under specified refresh-failure conditions, so a TTL is not a universal disappearance deadline. Update the parent delegation through the authorized registration workflow, then observe parent referrals and recursive resolution as well as direct new-server answers. Delegation, positive answers and negative answers can have different caching histories.
Retain the old DNS service until the migration's relevant cache and operational conditions have cleared. A rollback is another distributed change, not an instantaneous undo. Close only after records agree, validating resolution works where applicable, and representative legitimate mail paths have been tested. Production migration and mail tests remain pending. The retained historical fixture below supplies a bounded DNS preservation example.
Retained historical lab evidence
The retained 7 November 2026 capture, inspected but not rerun here, records that the isolated socket lab queried the old and new fixed-zone authorities for s1._domainkey.example.test. The destination initially returned NXDOMAIN, while the old authority returned the marker. After the synthetic addition described in the historical runner, the destination returned the marker. The retained capture preserves the exact query names and before/after answers for this narrow record-preservation case; it is not a customer migration plan or approval. The capture labels are migration_missing_s1; migration_old_s1; migration_after_repair. The historical runner and raw capture are included in this review package; their presence is not a new execution claim. Production DNS, DNSSEC and SMTP outcomes remain untested.