Most DNS “outages” aren’t Cloudflare failures. They’re human mistakes. Common causes include a missing TXT record, an MX record that didn’t get copied, or the orange-cloud proxy enabled on the wrong hostname.
This walkthrough shows how to migrate to Cloudflare DNS with a deliberate, test-first workflow. The goal is to keep your site, APIs, and email running normally.
You’ll lower TTLs ahead of time. Then you’ll import and clean up the zone in Cloudflare.
After that, you’ll verify answers from Cloudflare’s authoritative nameservers. Finally, you’ll switch nameservers with a clear rollback path.
The process is the same on shared hosting, a VPS running Nginx/Apache, or dedicated hardware.
Before you start: what “no downtime” actually means
Nameserver changes don’t flip everywhere at once. During propagation, different resolvers may query different authoritative servers.
You get “no downtime” when:
- Your old DNS zone stays online and correct until propagation is done.
- Your Cloudflare zone is complete (web + mail + verification records) before you switch nameservers.
- Important records have low TTL in advance, so stale caches drain quickly.
Set aside a 30–60 minute change window.
After the switch, leave the old DNS zone untouched for at least 48 hours. Keeping it longer is fine.
Prerequisites checklist (5 minutes)
- Access to your domain registrar (where you change nameservers).
- Access to your current DNS provider (to edit TTL / export zone).
- A Cloudflare account with permission to add zones.
- A list of services using DNS: website/app, mail, subdomains, third-party verifications.
If you’re also moving the site to new infrastructure (VPS/dedicated), do that first.
Cut DNS only after the new origin is stable.
HostMyCode documents a straightforward hosting migration flow here: migrations.
Step 1 — Inventory your existing DNS zone (don’t trust memory)
Start with the authoritative source: your current DNS host. If it supports zone export, export it and save a copy.
If it doesn’t, you can still build a reliable inventory with dig.
Find the current authoritative nameservers
dig NS example.com +shortWrite down what you get back. Those nameservers must keep answering correctly until your Cloudflare cutover finishes.
Pull key records you must not break
Replace example.com with your domain:
# Web
for t in A AAAA CNAME; do dig $t example.com +short; done
# Common subdomains
for h in www api app mail; do
for t in A AAAA CNAME; do
echo "$h $t"; dig $t $h.example.com +short;
done
done
# Email
for t in MX TXT; do dig $t example.com +short; done
# SPF/DMARC/DKIM (names vary)
dig TXT _dmarc.example.com +short
# DKIM selectors depend on your mail provider; examples:
dig TXT selector1._domainkey.example.com +short
dig TXT selector2._domainkey.example.com +shortSave the output somewhere you can refer to during the import. Pretty doesn’t matter here; completeness does.
If you run your own mail server, slow down and double-check every mail-related record.
One missing DKIM selector can wreck deliverability until you notice.
If you need a refresher, HostMyCode covers SMTP setup and authentication records here: Set Up Postfix SMTP With SPF/DKIM on Ubuntu VPS and Set Up DKIM, SPF, And DMARC For A Domain.
Step 2 — Lower TTL ahead of time (the part people skip)
Lower TTLs at your current DNS provider before you touch anything in Cloudflare. This gives caches time to drain.
With drained caches, the nameserver flip converges quickly.
- For web records (A/AAAA/CNAME): set TTL to 300 seconds (5 minutes).
- For MX and mail-related TXT records: also use 300 seconds during the cutover window.
- Do this at least 12–24 hours in advance if your TTLs are currently high (e.g., 3600–86400).
Avoid dropping TTL to 60 “just in case”. Five minutes is short enough for a safe cutover, without unnecessary resolver churn on active zones.
Verify TTL changes are actually published
Pick a record you changed, query it, and check the TTL in the answer. Example (A record):
dig example.com A +noall +answerYou should see something like:
example.com. 300 IN A 203.0.113.10Step 3 — Add the domain to Cloudflare (and choose the right plan)
In the Cloudflare dashboard:
- Click Add a site.
- Enter
example.com(the root domain, notwww). - Select a plan (Free works for many sites; paid plans add advanced WAF features and support).
Cloudflare will scan/import DNS records. Treat that scan as a draft.
You still need to validate it against your inventory.
Step 4 — Import and normalize DNS records in Cloudflare
Go to DNS → Records. Compare Cloudflare’s zone to what you captured in Step 1.
Do this line by line for anything that matters.
Web records: A/AAAA/CNAME
- @ (root) usually has an A record to your server IP (or a CNAME depending on your setup).
- www is commonly a CNAME to
@or an A record to the same IP. - API/app subdomains often point to separate hosts or load balancers.
Common mistake: forgetting www.
If the root loads but www fails, this is usually the reason.
Email records: MX, SPF, DKIM, DMARC
With providers like Google Workspace, Microsoft 365, Zoho, or hosted SMTP services, your DNS usually includes:
- One or more MX records
- An SPF TXT record at
@(often starts withv=spf1) - One or more DKIM records (TXT or CNAME under
selector._domainkey) - A DMARC TXT record at
_dmarc
Critical Cloudflare setting: keep mail-related hostnames DNS only (gray cloud). Cloudflare’s proxy is for HTTP(S), not SMTP/IMAP/POP.
If you proxy mail.example.com and it’s used for SMTP, mail will fail.
Verification records: don’t lose your integrations
TXT verification records are easy to miss because they don’t affect your homepage.
You notice them later, when search console ownership breaks or a SaaS integration starts complaining.
Review your old zone for TXT records that aren’t SPF/DMARC. Make sure they exist in Cloudflare with the same hostname and value.
CAA records (optional, but check)
If you use CAA records to restrict certificate authorities, copy them over exactly.
A bad CAA value can block certificate issuance or renewal.
Step 5 — Decide what gets proxied (orange cloud) vs DNS-only
Cloudflare proxying is useful, but only in the right places.
Start conservative, then expand later if you need to.
- Proxy (orange cloud):
example.com,www, and HTTP(S)-only app subdomains likeapporapiif they serve web traffic. - DNS only (gray cloud):
mail,smtp,imap,pop,autodiscover,cpanel,whm,directadmin,plesk, and anything not strictly HTTP(S).
If you run a hosting control panel, don’t proxy it unless you understand Cloudflare Spectrum/advanced options.
This is one of the most common self-inflicted cutover outages.
Step 6 — Pre-cutover testing: verify DNS and origin health
Before you switch nameservers, confirm two things:
- Cloudflare’s DNS zone answers correctly for every critical record.
- Your origin server still serves the site properly when accessed directly.
Test Cloudflare DNS answers (without switching nameservers)
Once Cloudflare creates the zone, it assigns two authoritative nameservers.
You can query them directly and confirm the zone is correct before any traffic depends on it.
Find the Cloudflare nameservers in the dashboard (they look like abby.ns.cloudflare.com and rick.ns.cloudflare.com), then run:
# Query Cloudflare's authoritative nameserver directly
CFNS1=abby.ns.cloudflare.com
dig @${CFNS1} example.com A +noall +answer
dig @${CFNS1} www.example.com CNAME +noall +answer
dig @${CFNS1} example.com MX +noall +answer
dig @${CFNS1} example.com TXT +noall +answer
dig @${CFNS1} _dmarc.example.com TXT +noall +answerCompare these answers with your inventory from Step 1. If anything is missing or different, fix it now.
Don’t wait until after the nameserver switch.
Test your origin server directly
If you plan to proxy web traffic, Cloudflare becomes the public entry point.
Your origin still needs to serve cleanly on 80/443.
On your VPS/dedicated server, verify your web server configuration and service status:
# Nginx
sudo nginx -t
sudo systemctl status nginx --no-pager
# Apache (if applicable)
sudo apachectl -t
sudo systemctl status apache2 --no-pager || sudo systemctl status httpd --no-pagerFrom your laptop, you can test the origin by forcing DNS resolution with curl (replace ORIGIN_IP):
ORIGIN_IP=203.0.113.10
curl -I --resolve example.com:443:${ORIGIN_IP} https://example.com/You want a clean 200/301 and a certificate situation you understand.
If TLS on the origin is still half-configured, fix that first.
This guide walks through a clean setup: Configure HTTPS with Let’s Encrypt on a VPS.
Step 7 — Switch nameservers at your registrar (the actual cutover)
Once Cloudflare DNS is complete and tested, open your registrar.
Replace your existing nameservers with the two Cloudflare nameservers assigned to the zone.
After you save the change, propagation begins. Don’t “tidy up” the old DNS zone yet.
Leave it exactly as-is.
Verify nameserver propagation
Run these from a terminal.
If you can, run them from a second network too (for example, a phone hotspot). This helps you avoid being misled by local resolver cache:
# Check what NS the world is seeing
whois example.com | grep -i "Name Server" | head
# Ask your default resolver
dig NS example.com +short
# Ask a public resolver
dig NS example.com @1.1.1.1 +short
dig NS example.com @8.8.8.8 +shortOnce you consistently see Cloudflare nameservers across resolvers, most traffic is now using Cloudflare DNS.
Step 8 — Post-cutover checks: website, API, email, and SSL
Run these checks in order. They catch the most common failures quickly.
1) HTTP(S) responses
curl -I https://example.com/
curl -I https://www.example.com/If you see 521, 522, or 525 after proxying is enabled, the issue is almost always origin reachability or TLS mode/config.
- 521: origin web server refused connection (service down, firewall blocked).
- 522: connection timed out (wrong IP, firewall, routing, server overloaded).
- 525: SSL handshake failed (certificate problems, wrong TLS config).
If your site already had 502 trouble behind Nginx/PHP-FPM, address that first. This guide is a solid reference: Nginx 502 Bad Gateway Fix on Ubuntu VPS.
2) DNS record spot checks from different resolvers
# Check A/AAAA
for r in 1.1.1.1 8.8.8.8 9.9.9.9; do
echo "Resolver: $r";
dig A example.com @$r +short;
dig AAAA example.com @$r +short;
done
# Check MX
for r in 1.1.1.1 8.8.8.8; do
echo "Resolver: $r";
dig MX example.com @$r +short;
done3) Email deliverability sanity check
Send a test email from your domain to a Gmail/Outlook address and confirm it arrives.
Then reply and confirm you receive it.
If outbound mail breaks right after the DNS move, the usual culprit is missing or changed SPF/DKIM/DMARC.
Re-check Cloudflare for:
- SPF TXT at the root
- DKIM selector records
- DMARC at
_dmarc
Step 9 — Cloudflare SSL/TLS mode that won’t surprise you
In Cloudflare, open SSL/TLS.
For most production sites in 2026, the safest default is:
- SSL/TLS encryption mode: Full (strict)
- Always Use HTTPS: enabled (if your app supports HTTPS cleanly)
Full (strict) requires a valid certificate on your origin. That’s the point.
It prevents silent downgrade and keeps your security posture consistent.
Step 10 — Lock down the origin (optional, but smart)
Once the cutover is stable, you can restrict origin access so only Cloudflare can reach it.
This reduces direct-to-IP probing and attack traffic.
How you do it depends on your stack. On a VPS you control, start with firewall rules and careful allowlists.
For a baseline Ubuntu approach, see: Set Up UFW Firewall on Ubuntu for a Web Server.
Warning: don’t lock down the origin until you’re confident propagation is complete and Cloudflare is configured correctly.
Locking too early looks exactly like a “Cloudflare outage” to users.
Running this on real infrastructure: quick notes for VPS and hosting users
On VPS and dedicated setups, DNS changes often overlap with IP changes, TLS changes, or reverse-proxy changes.
Keep those projects separate.
Stabilize the origin first, then migrate DNS.
- If you need a stable Linux host for your origin, start with a HostMyCode VPS and keep DNS on Cloudflare, registrar, or both (with a clear primary).
- If you don’t want to manage OS patching and web stack hardening, managed VPS hosting is the safer choice for production websites.
- If you’re moving platforms, schedule the move and the DNS cutover separately. HostMyCode can handle assisted moves via migrations.
If you’re aiming for a true zero-downtime move (old and new servers in parallel, low TTL, staged SSL), follow a cutover runbook.
This one is built for that workflow: DNS cutover tutorial for a new VPS.
Troubleshooting: the fastest fixes for common cutover failures
Problem: Website works on root but not on www
- Check that
wwwexists (CNAME to@is typical). - Verify:
dig www.example.com +short
Problem: Mail stopped working after the move
- Confirm MX records match the old zone exactly.
- Make sure mail hostnames are DNS-only (gray cloud), not proxied.
- Re-check SPF/DKIM/DMARC records for typos and quotes.
Problem: You see Cloudflare 522 timeouts
- Verify the A record points to the correct origin IP.
- Confirm port 443 is reachable:
nc -vz ORIGIN_IP 443 - Check your firewall allows Cloudflare (or temporarily open 80/443 to validate).
Problem: Some users see the old site, some see the new one
- This is normal during propagation if TTLs were high.
- Keep both old and new origins serving the same content during the window.
- Wait for caches to expire; don’t “fix” it by making random record edits.
Wrap-up: your safe Cloudflare DNS migration checklist
- Lower TTL on the old DNS provider (300s) at least 12–24 hours ahead.
- Inventory every record: web, subdomains, mail, and verification TXT.
- Import to Cloudflare, then compare against your inventory line by line.
- Set proxying intentionally (orange for HTTP; gray for mail/control panels).
- Query Cloudflare’s authoritative NS directly with
dig @nsbefore cutover. - Switch nameservers at the registrar, then verify from multiple resolvers.
- Keep the old DNS zone running for at least 48 hours as a rollback safety net.
If you’re doing this as part of a move to a new server, don’t gamble on an unstable origin.
A properly sized HostMyCode VPS keeps the backend steady while Cloudflare handles DNS and edge caching.
If you’re changing DNS because you’re also changing hosts, keep it linear: move the site first, confirm it’s healthy, then switch nameservers. HostMyCode can run your origin on a managed VPS hosting plan and help with migrations so the DNS cutover stays predictable.
FAQ
How long does it take to migrate to Cloudflare DNS?
The nameserver change can propagate in minutes, but some resolvers cache longer.
With TTL set to 300 seconds the day before, most sites stabilize within 30–60 minutes.
Should I proxy my DNS records through Cloudflare?
Proxy (orange cloud) only for HTTP(S) services. Keep SMTP/IMAP/POP and most control panel hostnames DNS-only (gray cloud).
Do I need to change my A record IP when switching to Cloudflare?
No. Cloudflare DNS can point to the same origin IP you already use. The nameserver migration is separate from any server migration.
Can I roll back if something goes wrong?
Yes. The clean rollback is changing nameservers back to your previous DNS provider at the registrar.
That’s why you keep the old DNS zone unchanged for at least 48 hours.
Will switching to Cloudflare affect email deliverability?
Not if you copy mail-related records exactly and keep mail hostnames DNS-only.
Deliverability problems after a DNS move usually come from missing DKIM/DMARC records or incorrect SPF.