A DNS provider migration changes who publishes your domain’s records. It should not change where your website runs or where your mailboxes live. However, missing records, proxy differences, or broken security settings can interrupt both services.
The safest approach treats this as a controlled infrastructure change, not a simple nameserver edit. Build matching zones, test the new provider directly, and preserve the old service during the transition. This guide focuses on moving authoritative DNS while keeping existing hosting and email services in place.
Define the DNS Migration Scope Before Buying Service
DNS, the Domain Name System, connects domain names with service information. Your authoritative DNS provider publishes those records. A recursive resolver looks them up and caches answers for users.
Your registrar manages the domain registration and its nameserver delegation. Delegation tells the internet which authoritative servers to ask. Changing DNS providers does not require transferring the registration or moving hosting.
Before choosing a provider, confirm support for your actual requirements:
- All record types, including email authentication and service discovery.
- DNSSEC, which lets resolvers verify signed DNS answers.
- Zone exports, access controls, activity logs, and emergency support.
- Any current traffic steering, proxying, or automated record updates.
Assign one change owner and identify who can access the registrar. Record a maintenance window, acceptance checks, and rollback triggers. Cloudflare’s DNS overview explains the roles behind this process.
Inventory Every Record and Provider-Specific Feature
Export the existing zone before making changes. A zone is the collection of DNS records for your domain. Keep screenshots or structured notes for features the export omits.
For each record, capture its full name, type, value, priority when applicable, and time to live. Also note the service owner and business purpose.
- A and AAAA: IPv4 and IPv6 addresses for websites and other services.
- CNAME: aliases pointing one hostname to another.
- MX: mail delivery destinations and their priorities.
- TXT: email policies, verification tokens, and other text data.
- SRV: service locations, ports, priorities, and weights.
- CAA: restrictions on which certificate authorities may issue certificates.
- NS: nameserver records, including any delegated subdomains.
Check wildcards, DKIM selectors, autodiscover records, and certificate renewal automation. Public queries cannot reliably discover every hostname. Use the provider dashboard, exports, and service documentation instead.
Document URL forwarding, mail forwarding, health checks, and dynamic updates separately. These may represent provider services rather than portable DNS records.
Lower TTLs Without Expecting an Instant Cutover
Time to live, or TTL, tells resolvers how long they may cache an answer. Lowering it can shorten later record corrections. It does not clear answers that resolvers already hold.
Reduce relevant record TTLs far enough ahead that their previous cache periods can expire. For example, a record with a one-day TTL needs that lead time before shorter caching becomes useful.
Choose a temporary value that both providers support and your operations team can manage. Lower TTLs increase lookup traffic, so check provider limits before applying them broadly.
Nameserver delegation has separate caching behavior. Lowering website or mail record TTLs does not necessarily shorten the parent zone’s delegation cache.
Negative caching also matters: resolvers may remember that a name did not exist. Avoid creating required names only after cutover. Matching old and new zones provides stronger protection than relying on short TTLs alone.
Recreate the Zone and Compare Authoritative Answers
Create the destination zone while the current provider still serves production traffic. Import records if the provider supports it, then compare each entry against your inventory.
Do not blindly copy the old provider’s zone-level NS and SOA records. SOA records contain zone administration details. The new provider normally generates these records itself. Preserve intentional subdomain delegations.
Watch for interfaces that automatically append your domain. Entering a full hostname incorrectly can create a duplicated name. Confirm whether the interface expects a short label or a complete domain.
Provider-specific ALIAS records and root-domain alias handling may need translation. Proxy settings also require special attention. Enabling a proxy can change web traffic, certificates, firewall requirements, and public DNS answers.
For a DNS provider migration, compare service behavior as well as record text. Query each new authoritative nameserver directly before changing delegation. Check record names, values, priorities, and expected responses. If a provider cannot answer before activation, arrange a supported pre-cutover validation method.
Verify MX, SPF, DKIM, and DMARC Separately
Keep existing mail destinations unchanged during this move. Verify every MX target and priority against your mail provider’s current configuration. Confirm the targets resolve correctly.
SPF, the Sender Policy Framework, lists authorized sending services. Preserve its complete value. Publish one SPF policy per hostname; do not create separate policies for each sender.
DKIM, DomainKeys Identified Mail, uses signatures to authenticate messages. Copy every active selector record, including CNAME-based selectors. Do not rotate keys as part of an otherwise unchanged DNS move.
DMARC connects authentication results with the visible sender domain and sets handling policy. Preserve its policy, reporting addresses, and alignment settings. The DMARC overview explains these relationships.
Compare TXT answers, not just dashboard appearance. Providers can represent long values differently. Our guide to handling long TXT records covers that distinction.
Also check mail client discovery records and third-party senders. Preserve forwarding arrangements separately if the old DNS provider supplies them.
Resolve DNSSEC and Registrar Dependencies Before Cutover
DNSSEC needs its own migration plan. A DS record in the parent zone links your domain to its signing keys. A stale DS record can make validating resolvers reject otherwise correct answers.
Determine whether both providers support a coordinated signed migration. That process requires compatible signing arrangements and careful timing. Do not assume importing records also imports signing keys.
If you must migrate through an unsigned stage, remove the parent DS record first. Keep the old signed zone working while cached DS records expire. Verify the parent’s state before switching to unsigned nameservers.
This temporarily removes DNSSEC protection, so obtain approval and follow provider guidance. After the new delegation stabilizes, enable signing and publish the new provider’s DS details.
Check registrar access, multifactor authentication, and domain status in advance. Custom nameservers within your own domain may require glue records: parent-held addresses that prevent circular lookups. Escalate unclear glue or signing arrangements before proceeding.
Change Nameservers With Both Providers Still Running
Freeze unrelated DNS edits just before cutover. Export both zones again and record the current nameservers, DS state, and change time.
At the registrar, replace the old nameservers with the exact destination nameserver set. Editing NS records only inside the old zone does not normally update the parent delegation.
Do not mix old and new nameservers as an improvised transition method. Unless you designed a coordinated multi-provider setup, that approach can produce inconsistent answers.
Keep the old zone active and equivalent throughout the transition. Some resolvers will still ask the old servers while others reach the new ones. Apply any urgent correction to both zones.
A DNS provider migration rarely switches every resolver at once. Use measured delegation and lookup results rather than a fixed “propagation complete” promise.
Validate Website and Email Behavior After the Switch
Check the parent delegation, then query every new authoritative server. Follow with lookups through independent recursive resolvers and tests from separate networks.
- Open the main website and important subdomains over HTTPS.
- Test both IPv4 and IPv6 paths where you publish both address types.
- Confirm redirects, login pages, forms, and certificate renewal dependencies.
- Send external messages into representative mailboxes.
- Send messages outward through each authorized business sender.
- Review recipient authentication results and mail-provider delivery logs.
- Check service discovery, delegated subdomains, and automated DNS updates.
Successful outbound mail does not prove inbound MX routing works. Likewise, a working home connection does not prove all resolvers see the same delegation.
If the website reaches an unexpected destination, trace why visitors reach the old server. Separate DNS results from browser caches and proxy behavior before changing records again.
Retain Rollback Data and Close the Change Deliberately
Keep the old provider account, zone exports, nameserver list, and security details until validation supports retirement. Retain service ownership notes and timestamped test results with the change record.
Rollback is not instantaneous. Restoring delegation still leaves cached answers in circulation. DNSSEC state must also match the restored servers.
When possible, correct a missing record at both providers rather than immediately reversing the entire delegation. For widespread failures, follow the agreed rollback plan and coordinate security changes.
Restore normal TTLs after the transition proves stable. Confirm automatic DNS updates now target the new provider before canceling the old service.
Professional remote assistance may help when access spans several vendors or signing and proxy features complicate the move. Tech Rescue Ops LLC can help inventory dependencies, coordinate a DNS provider migration, and collect validation evidence before you retire the old zone.