Changing nameservers looks deceptively small: replace two hostnames at the registrar and wait. In reality, you are moving the directory that tells the internet where your website, email, verification records, APIs, and delegated subdomains live. I would not click Continue until every production record has an owner and an expected answer.

What changes in a full Cloudflare setup

  • The registrar/parent zone delegates your domain to the two Cloudflare nameservers assigned to that zone.

  • Cloudflare becomes authoritative for the DNS records you create there.

  • Proxied web records return Cloudflare anycast addresses so supported traffic passes through its reverse proxy.

  • DNS-only records return their configured origin/target and do not receive Cloudflare HTTP proxy caching/security.

  • Changing authoritative DNS does not move hosting, mailboxes, application data, domain registration, or automatically repair an incomplete zone.

Separate the registrar, DNS provider, and host

  • The registrar manages registration and parent-level nameserver/DS settings.

  • The authoritative DNS provider answers records for the domain; this moves to Cloudflare in a full setup.

  • The web origin serves application content and may remain at the existing host.

  • The mail provider handles SMTP/mailboxes and depends on MX plus supporting A/AAAA/CNAME/TXT records.

  • A reseller or hosting panel can hide these boundaries; confirm where each change must actually be made.

Create a change record and rollback plan

  • Record current registrar, authoritative nameservers, account owners, DNSSEC/DS state, renewal/contact status, and recovery methods.

  • Export the complete old zone and take timestamped screenshots/text of values, TTLs, priorities, proxy-equivalent intent, comments, and provider-only features.

  • Define rollback: restore old nameservers, restore correct DS state, and keep the old DNS zone active/unchanged until the migration has been stable beyond cached delegation TTLs.

  • Schedule during a staffed low-risk period; retain registrar, old DNS, Cloudflare, origin, and mail-provider access.

  • Do not combine nameserver, origin, mail, host, certificate, and application migrations unless a coordinated plan requires it.

Capture the current public DNS baseline

External Linux or macOS shellbash
domain=example.com
dig +short NS "$domain"
dig +short A "$domain"
dig +short AAAA "$domain"
dig +short CNAME "www.$domain"
dig +short MX "$domain"
dig +short TXT "$domain"
dig +short CAA "$domain"
dig +dnssec DS "$domain"
ns1.old-provider.example.
ns2.old-provider.example.
192.0.2.20
10 mail.example.com.
...

Public queries reveal only records you remember to ask for

  • Replace example.com; the shown addresses/names are documentation placeholders.

  • Capture answers from multiple resolvers and query the current authoritative servers directly.

  • Inventory subdomains from application, certificate, mail, analytics, deployment, support, monitoring, source, and provider records—not DNS enumeration alone.

  • TXT is a record type, not one value; preserve SPF, verification, DMARC, DKIM, MTA-STS, BIMI, and service tokens according to providers.

  • A zone transfer (AXFR) is often disabled; use the provider export/API when available.

Inventory records by business function

  • Website: apex, www, media/static, API, origin aliases, redirects, preview/staging, IPv4 and IPv6.

  • Email: MX, mail host addresses, SPF, DKIM selectors, DMARC, autodiscover/autoconfig, verification, MTA-STS/TLS reporting, and vendor CNAMEs.

  • Services: VPN, SSH, SFTP, Git, VoIP, chat, calendar, CI/CD, monitoring, status, object storage, SaaS custom domains, and webhooks.

  • Delegation: child-zone NS records and associated glue at the parent/registrar where required.

  • Certificates/ownership: CAA, ACME DNS challenges, Google/Search Console, Microsoft, Apple, payment, social, and vendor tokens.

  • Wildcards and split-horizon/internal DNS: determine whether they belong in the public Cloudflare zone at all.

Lower TTLs only when it helps

  • Lower changeable record TTLs ahead of origin cutovers if the current provider permits it and caches have time to expire.

  • Nameserver delegation has parent/registry/recursive caching behavior that a record TTL setting may not control directly.

  • Cloudflare proxied records use Cloudflare-managed DNS TTL behavior.

  • Very low TTLs do not fix wrong data and can increase query load/dependency.

  • Restore deliberate TTLs after the migration; document what can change quickly and what should remain stable.

Add the domain to the correct Cloudflare account

  1. Sign in with an organization-controlled Cloudflare account protected by strong MFA and recovery.

  2. Choose Add a domain and enter the registrable domain such as example.com, not a URL or path.

  3. Select the plan based on documented requirements; current pricing and feature limits can change.

  4. Let Cloudflare scan, then treat every imported record as unverified until compared with the authoritative inventory.

  5. Add missing records and remove only entries proven obsolete.

  6. Record the two Cloudflare-assigned nameservers exactly; do not borrow nameservers from another zone/account.

Choose proxy status per record

  • Proxy A, AAAA, or CNAME records serving compatible HTTP/HTTPS traffic when you want Cloudflare’s reverse-proxy features.

  • Keep mail hosts and other non-HTTP services DNS-only; Cloudflare’s standard orange-cloud proxy does not proxy ordinary SMTP/IMAP/SSH.

  • MX and TXT records are inherently DNS-only. An MX target should resolve to a DNS-only mail-host address.

  • Keep third-party ownership-verification CNAMEs DNS-only unless the provider explicitly supports proxying; flattening can also prevent direct CNAME verification.

  • Some SaaS/CDN targets forbid or special-case an additional proxy; follow both providers’ supported architecture.

  • Proxy status can hide the current origin address in new queries, but historical DNS, mail hosts, certificates, or other records may still reveal it.

A representative Cloudflare DNS table

cloudflare-dns-inventory.txttext
A      @                  192.0.2.20          Proxied
CNAME  www                example.com         Proxied
A      mail               192.0.2.30          DNS only
MX     @         10       mail.example.com    DNS only
TXT    @                  v=spf1 ...          DNS only
TXT    _dmarc             v=DMARC1; ...       DNS only
CNAME  selector1._domainkey  vendor.example.  DNS only
CAA    @         0        issue "letsencrypt.org"  DNS only

The values are a shape, not a template

  • Documentation IPs and abbreviated TXT policies must never be copied into a production zone.

  • Use exact values, priorities, quoting, names, and TTLs from your hosting/mail/security providers.

  • Multiple TXT records at one owner name are normal; do not merge unrelated values into one invalid string.

  • SPF has semantic limits and must be designed—not duplicated casually.

  • CAA can prevent certificate issuance if the intended CA is absent; inventory all certificate automation first.

Validate Cloudflare’s pending zone before delegation

External shell; use the assigned Cloudflare nameserverbash
cf_ns=alice.ns.cloudflare.com
domain=example.com
dig @"$cf_ns" "$domain" A +noall +answer
dig @"$cf_ns" "$domain" MX +noall +answer
dig @"$cf_ns" "selector1._domainkey.$domain" CNAME +noall +answer
dig @"$cf_ns" "_dmarc.$domain" TXT +noall +answer
... answers from the staged Cloudflare authoritative zone ...

Direct authoritative queries catch omissions before users do

  • Use the exact nameserver assigned in the dashboard, not the placeholder.

  • Compare expected type, owner, content, priority, TTL behavior, and proxy status implications.

  • For proxied web names, the answer will generally be Cloudflare anycast addresses rather than the origin.

  • Test every critical hostname and record type from the inventory, including negative expectations and delegated subzones.

  • Automate the comparison without logging secret tokens more broadly than necessary.

Handle DNSSEC in the correct order

  1. Determine whether a DS record is active at the registrar/parent and capture the current DNSSEC state.

  2. Before changing nameservers in a standard full setup, disable old DNSSEC/remove the old DS using provider/registrar guidance and wait for the parent state to reflect the change.

  3. Change nameservers to Cloudflare and confirm the zone becomes Active and resolves correctly.

  4. Enable DNSSEC in Cloudflare to generate the new DS parameters.

  5. Publish those exact DS values at the registrar, then validate the chain from multiple resolvers.

Check DS and validation state

External shellbash
dig +dnssec DS example.com
dig +dnssec A example.com @1.1.1.1
dig +dnssec A example.com @8.8.8.8
... parent DS state ...
... validated A response or SERVFAIL diagnostic ...

Test through validating recursive resolvers

  • The DS query shows the parent-published delegation signer state, subject to cache.

  • A successful ordinary query alone does not prove DNSSEC validation; inspect status flags/tool output with a DNSSEC-aware validator.

  • Resolvers can cache old delegation/DS data for different periods, so test more than one.

  • If validation fails, stop unrelated record changes and compare parent DS, Cloudflare DNSSEC values, DNSKEY, delegation, and timing.

  • Do not disable DNSSEC permanently as a substitute for fixing the chain.

Change nameservers at the registrar

  1. Confirm domain registration is active, unlocked only if the registrar requires it for this operation, and administrative contacts/recovery are available.

  2. Enter only the two exact Cloudflare-assigned nameservers; remove old/extra authoritative servers for a standard full setup.

  3. Save and record the registrar’s confirmation/time.

  4. Use Cloudflare’s Check nameservers function and query the parent/recursive delegation independently.

  5. Keep the previous zone serving identical data during the transition so cached resolvers receive consistent answers.

Verify delegation from the DNS root downward

External shellbash
dig +trace NS example.com
dig +short NS example.com @1.1.1.1
dig +short NS example.com @8.8.8.8
... delegation chain ...
alice.ns.cloudflare.com.
bob.ns.cloudflare.com.

Cloudflare Active is useful, not the only proof

  • +trace walks delegations using iterative queries and helps locate parent/child mismatch.

  • Public recursive resolvers may temporarily show old or new nameservers due to caching.

  • The final steady state should list exactly the assigned Cloudflare nameservers for a standard full setup.

  • Check DNS from regions/networks important to users and monitor DNS errors, mail, web, APIs, and third-party services.

  • Do not repeatedly toggle nameservers during normal cache transition; that creates competing histories.

Test web traffic through Cloudflare

External shellbash
curl -sS -I https://example.com/
curl -sS -I https://www.example.com/
curl -sS -o /dev/null -w '%{http_code} %{url_effective} %{redirect_url}\n' http://example.com/sample
HTTP/2 200
server: cloudflare
cf-ray: ...
...
301 http://example.com/sample https://www.example.com/sample

DNS success does not prove application success

  • Test apex/www, HTTPS certificate, canonical redirects, meaningful paths, query strings, forms, login, API, media, robots.txt, and sitemap.

  • Confirm proxied names show Cloudflare edge headers/address behavior and DNS-only services bypass it as intended.

  • A 521/522/525/526 response points to origin connectivity/TLS configuration rather than missing DNS alone.

  • Set SSL/TLS to Full (strict) only after the origin presents a valid matching certificate.

  • Check logs/client-IP restoration through trusted Cloudflare headers and origin restrictions before security enforcement.

Prove email still works

External shellbash
dig +short MX example.com
dig +short A mail.example.com
dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short CNAME selector1._domainkey.example.com
10 mail.example.com.
192.0.2.30
"v=spf1 ..."
"v=DMARC1; ..."
vendor.example.

DNS checks precede real mail-flow checks

  • The MX target and its address must match the mail provider and remain DNS-only where ordinary mail protocols are used.

  • Validate SPF syntax/evaluation, DKIM signatures/selectors, DMARC alignment/reporting, reverse DNS, and provider-specific records.

  • Send inbound and outbound messages across independent providers, then inspect full headers and delivery logs.

  • Do not use a website-only smoke test to approve a DNS migration; email failures can surface hours later.

  • Monitor bounces, authentication reports, queues, and user clients throughout cached delegation transition.

CNAME flattening and verification records

  • Cloudflare flattens an apex CNAME because DNS standards normally prohibit an ordinary apex CNAME alongside required zone records.

  • Proxied CNAMEs return Cloudflare IP addresses rather than the literal target.

  • Flattening all CNAMEs can break third-party verification that expects to query the exact CNAME target.

  • Keep verification CNAMEs DNS-only and unflattened when the vendor requires it.

  • Delegated subdomains with NS records are answered by their delegated provider; do not create conflicting assumptions in the parent zone.

Protect accounts and automate safely

  • Use organization ownership, strong MFA, recovery codes, multiple accountable administrators, and scheduled access review.

  • Use API tokens restricted to the minimum zone and DNS permissions; avoid global API keys.

  • Store tokens in a secrets manager, rotate them, and prevent exposure in shell history, CI logs, repositories, WordPress settings exports, and tickets.

  • For infrastructure as code, import/reconcile existing state before applying and require reviewed plans.

  • Cloudflare account access plus registrar access can redirect an entire domain; protect both independently.

Monitoring after activation

  • Authoritative NS/DS/DNSKEY health and DNS resolution from multiple regions/resolvers.

  • Web availability, status, TLS expiry/chain, redirects, performance, origin reachability, and Cloudflare errors.

  • Mail inbound/outbound delivery, SPF/DKIM/DMARC, queues, bounces, and verification endpoints.

  • Critical APIs, webhooks, VPN/SSH/service hosts, SaaS validation, and delegated subdomains.

  • Unexpected DNS/config changes through audit logs/alerts and periodic zone exports.

  • Domain registration renewal, contact/recovery status, registrar lock, and nameserver drift.

Rollback without making DNS less consistent

  • If the Cloudflare zone is incomplete and impact is severe, restore the exact old nameservers and matching DNSSEC/DS state according to the prepared plan.

  • Keep Cloudflare and old zones serving compatible records while recursive caches transition.

  • Do not delete the new zone, old zone, records, or certificates during rollback diagnosis.

  • Understand that cached resolvers may use both delegations until TTLs expire; rollback is not instant.

  • Preserve timestamps, query results, audit logs, registrar changes, and service symptoms for root-cause analysis.

  • Correct the staged zone and repeat only after a full inventory/diff and approved window.

Troubleshooting map

  • Zone remains Pending: registrar nameservers do not exactly match, extra servers remain, or delegation has not updated.

  • SERVFAIL after cutover: stale/incorrect DS and DNSSEC chain are prime suspects; compare parent DS and Cloudflare keys.

  • Website works but email fails: missing/wrong MX, mail address, SPF/DKIM/DMARC, or mail host was proxied.

  • A subdomain is missing: scan omitted it, wildcard/delegation behavior differs, or the record lives in another zone/provider.

  • Verification CNAME fails: it is proxied/flattened or a child NS delegation sends queries elsewhere.

  • Origin is unreachable: proxy points to wrong IP/port, firewall blocks Cloudflare, Host/SNI routing is wrong, or origin TLS fails.

  • Some users see old service: delegation/record caches are still transitioning or resolver/IPv6 answers differ.

  • Too many redirects: edge TLS mode, origin scheme detection, and application redirect rules disagree.

Migration completion checklist

  • Old zone export and full service inventory are retained.

  • Cloudflare zone matches every required record, priority, target, and intentional TTL behavior.

  • Proxy status is deliberate; mail/non-HTTP/verification records are DNS-only where required.

  • Old DNSSEC DS was handled before delegation; new Cloudflare DNSSEC validates after activation.

  • Registrar lists only the assigned Cloudflare nameservers.

  • Website, TLS, redirects, APIs, mail authentication/delivery, verification, and delegated zones pass external tests.

  • Old DNS stays available through transition; rollback and accountable access remain ready.

  • Monitoring, API-token hygiene, registrar/domain renewal, audit logs, and periodic zone backups are operational.

Continue configuring the edge

Primary references