DNS — the Domain Name System — is the internet's phone book. When someone types your domain into a browser, DNS translates that human-readable name into an IP address so servers can connect. For WordPress site owners, understanding DNS is not optional: every host migration, email setup, and CDN configuration runs through it.
What Is DNS and Why Does It Affect Your WordPress Site?
DNS is a globally distributed database that maps domain names to server addresses. Every time someone visits your site, their browser queries a DNS resolver — usually provided by their ISP or a service like Google (8.8.8.8) or Cloudflare (1.1.1.1) — which returns the IP address your domain points to. Your WordPress site then loads from that IP.
The records you configure in your DNS zone file determine where your website lives, where your email goes, and whether third-party services like Google Workspace or Mailchimp can verify they're allowed to send on your behalf. Misconfigure any of these and parts of your site stop working — silently, often hours after the change.
According to Verisign's Domain Name Industry Brief, there are over 350 million registered domain names as of 2024 — each one depending on DNS working correctly. Yet DNS is one of the least understood layers of web infrastructure for site owners.
What Do A, CNAME, MX, and TXT Records Actually Do?
Each DNS record type has a specific job. Here's a practical breakdown:
| Record Type | What It Does | Common WordPress Use |
|---|---|---|
| A | Maps a domain/subdomain to an IPv4 address | Points example.com to your host's server IP |
| AAAA | Maps to an IPv6 address | Same as A record, for IPv6-capable servers |
| CNAME | Aliases one domain name to another | Points www.example.com to example.com; used for CDN subdomains |
| MX | Specifies mail servers for a domain | Routes email to Google Workspace, Zoho, or Microsoft 365 |
| TXT | Stores arbitrary text data | SPF, DKIM, DMARC, and domain verification records |
| NS | Nameserver records — where DNS is authoritative | Set by your domain registrar; points to your DNS provider |
| TTL | Time To Live (seconds) — cache duration | Controls how long resolvers cache a record before rechecking |
A records are the most critical record for your WordPress site. When you change hosting providers, updating the A record for example.com (and usually www) to your new host's IP is the core of the migration from a DNS perspective.
CNAME records cannot be used on the root domain (example.com) itself — only on subdomains. This is a technical DNS constraint called the "CNAME at apex" problem. If your CDN or load balancer requires a CNAME at the root, your DNS provider needs to support CNAME flattening (Cloudflare calls this CNAME flattening; AWS Route 53 calls it ALIAS records).
MX records point your domain's email to a mail server. They are entirely independent of where your website is hosted. If your site is on one host and your email is on Google Workspace, your MX records point to Google's servers — your A record change doesn't touch them, and shouldn't.
TXT records cover three things most WordPress site owners will encounter:
- SPF (
v=spf1 include:_spf.google.com ~all) — tells receiving servers which IPs can send email as your domain - DKIM — a cryptographic signature record your email provider gives you to verify message integrity
- DMARC — policy record that tells receiving servers what to do with mail that fails SPF/DKIM checks
- Domain verification — Google Search Console, Facebook Business Manager, and others drop a TXT record to prove domain ownership
What Happens to DNS When You Change WordPress Hosts?
When you migrate to a new host, your domain still points to your old server until you update your DNS records. The migration process has a DNS window — a period where some visitors hit the old server and some hit the new one, depending on which resolver's cached records they're using.
Here's the sequence that actually happens:
- You update the A record at your DNS provider to the new host's IP
- Your DNS provider broadcasts the change
- Resolvers worldwide check in when their cached TTL expires
- They fetch the new IP and start routing traffic to the new host
- Old resolvers that haven't refreshed yet still send visitors to the old server
This is "propagation" — and it's not a fixed 48 hours. It's entirely dependent on the TTL value your records were set to before the change. If your TTL was 86,400 seconds (24 hours), resolvers can cache the old IP for up to 24 hours. If you pre-lowered your TTL to 300 seconds (5 minutes) before the migration, most of the world is on the new IP within an hour.
If you're planning a migration, our guide to migrating from GoDaddy to managed WordPress hosting walks through exactly when and how to handle the DNS handoff alongside the file and database transfer.
Why Does Email Break During WordPress Migrations?
Email breaks for one consistent reason: MX records (and associated TXT records) get accidentally deleted or not carried over when DNS management moves from one provider to another.
This typically happens when a site owner transfers their domain to a new registrar, or switches from their web host's nameservers to a third-party DNS provider like Cloudflare. When nameservers change, the DNS zone that was on the old nameservers doesn't automatically follow. You're starting with a blank zone on the new provider, and if you only configure the A record to make the site work, email stops immediately.
What to audit before nameserver changes:
- All MX records (name, value, priority)
- All TXT records — especially SPF, DKIM, and DMARC
- Any CNAME records for email subdomains (e.g.,
mail.example.com,smtp.example.com) - Subdomains used by email marketing tools (Mailchimp, Klaviyo, and similar services often require CNAME records for tracking subdomains)
You can export your current zone file before making any changes. Most DNS providers have an export function — or you can query your zone manually with dig AXFR yourdomain.com @yournameserver if the DNS provider allows zone transfers. Screenshot every record before touching nameservers.
According to Proofpoint's 2024 Email Fraud Defense report, 81% of organizations experienced email fraud in the prior year — much of it enabled by misconfigured or missing SPF/DKIM/DMARC records. Migrations are one of the highest-risk moments for those records to get dropped.
TTL and Propagation: What's Actually True?
TTL is not a countdown to when your change takes effect. It's a cache expiry — the maximum time a resolver will hold the old record before re-querying. The moment a resolver's cache expires, it fetches the new record instantly.
Here's the practical implication:
- If TTL is 86,400 (24 hours) and you change your A record, some resolvers won't see the new IP for up to 24 hours
- If you pre-lowered TTL to 300 (5 minutes) 24+ hours before the change, the propagation window is about 5 minutes for most resolvers
- After the migration is stable, raise TTL back to 3,600 or 86,400 to reduce DNS query load
What "propagation" actually means: DNS resolvers around the world cache records based on TTL. When a record changes, they all refresh independently as their cache expires. There's no central push — it's a pull model. The "48-hour propagation" myth comes from an era of slow TTLs and less reliable DNS infrastructure. Modern DNS with a low TTL is effectively near-instant.
One exception: your own machine. Your operating system and browser maintain their own DNS cache. On macOS, sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder. On Windows, ipconfig /flushdns. If you've just updated your DNS and you can't see the change on your machine but others can, flush your local cache first.
Pre-Migration DNS Checklist
Before you touch a single DNS record or nameserver, run through this:
24–48 hours before migration:
- Log into your DNS provider and export or screenshot every record
- Lower TTL on A, CNAME, and MX records to 300 seconds
- Document your current nameservers (the NS records)
- Verify your new host's IP address (confirm with them — don't guess)
At migration time:
- Update A record for root domain (
@orexample.com) to new host IP - Update A or CNAME record for
wwwsubdomain - Verify MX records are intact and unchanged
- Verify all TXT records (SPF, DKIM, DMARC, verification) are unchanged
- If switching nameservers: re-enter every record in the new DNS zone before flipping NS records at registrar
After migration:
- Test email send and receive within 10 minutes of DNS changes going live
- Use
dig A yourdomain.comto verify propagation from multiple vantage points (dnschecker.org is useful here) - Confirm SSL certificate issues — some hosts auto-provision SSL only after DNS resolves to their IP
- After 48 hours, raise TTL back to 3,600 or higher
- Confirm no
404errors from permalink structures — if your new host runs NGINX, check the NGINX WordPress permalinks guide for rewrite rule configuration
NS Records: The Record That Controls All Other Records
NS (nameserver) records are configured at your domain registrar and tell the internet which DNS servers are authoritative for your domain. Every other record — A, MX, TXT — is managed at the nameserver level, not the registrar level.
This distinction matters because:
- Changing NS records at your registrar delegates DNS management to a new provider (e.g., Cloudflare)
- Your registrar's DNS zone and your new DNS provider's zone are separate — records don't transfer automatically
- NS record propagation has the same TTL-based behavior as other records, but registrars often set very long TTLs (24–48 hours) on NS records specifically
If you're moving to Cloudflare for DNS (which is a reasonable choice for WordPress sites given their free DDoS mitigation and CNAME flattening), Cloudflare's zone import tool can scan your existing DNS and attempt to import records automatically. It gets most of them — but always verify manually, especially DKIM records, which often have unusual subdomains.
How Managed Hosting Handles DNS for You
When you're on a platform that understands DNS at the infrastructure level, migrations become substantially less stressful. At TopSyde, the onboarding process includes a pre-migration DNS audit — we pull your existing records before touching nameservers, carry them into the new zone, and verify email is working before we declare the migration complete.
Our AI-powered WordPress monitoring also catches DNS-related failures post-migration — including SSL certificate errors that happen when DNS propagation is incomplete when the certificate was first provisioned. These are the kinds of silent failures that show up hours after a migration and aren't obvious from an uptime check alone.
If you're evaluating whether managed hosting is the right fit for your site, what managed WordPress hosting is and what it covers is a solid starting point before comparing plans.
TopSyde plans start at $89/mo per site and include migration support, DNS audit, and a 99.9% uptime SLA — so the DNS handoff isn't something you navigate alone.
Frequently Asked Questions
How long does DNS propagation actually take?
Propagation time depends entirely on the TTL value set on your records before the change. If TTL was 300 seconds, most resolvers update within 5–30 minutes. If TTL was 86,400 seconds (the default on many registrars), it can take up to 24 hours. The "48-hour" rule is a myth from outdated infrastructure — lower your TTL 24 hours before a migration to minimize the window.
Why did my email stop working after changing my WordPress host?
Email uses MX records, which are independent of your web hosting A records. The most common cause is that MX records (and SPF/DKIM TXT records) weren't carried over when nameservers changed or when DNS was reconfigured at the new host. Always export your full DNS zone before any migration and verify MX and TXT records are intact after the change.
Can I use Cloudflare DNS without changing my hosting provider?
Yes. Cloudflare acts as a DNS proxy — you update your registrar's NS records to point to Cloudflare's nameservers, then manage all your DNS records through Cloudflare. Your hosting provider doesn't change. This gives you Cloudflare's CDN, DDoS mitigation, and analytics on top of your existing host, with no server migration required.
What is a CNAME and when should I use it instead of an A record?
A CNAME maps one domain name to another domain name (rather than an IP address). Use a CNAME when a service provider gives you a hostname rather than an IP — for example, a CDN endpoint like d1234.cloudfront.net. You cannot use a CNAME on your root domain (example.com) — only on subdomains (www.example.com, cdn.example.com). For root domains, use an A record or a DNS provider that supports ALIAS/CNAME flattening.
What's the difference between my domain registrar and my DNS provider?
Your domain registrar is where you registered and pay for your domain name (GoDaddy, Namecheap, Google Domains, etc.). Your DNS provider is where the zone file that contains your DNS records lives — and it's controlled by which nameservers your registrar is pointed at. By default they're often the same company, but you can delegate DNS to a separate provider like Cloudflare while keeping your registrar unchanged.
Topics
DevOps & Security Lead
12+ years DevOps, Linux & cloud infrastructure certified
Marcus leads infrastructure and security at TopSyde, managing the server fleet and AI monitoring systems that keep client sites fast and protected. Former sysadmin turned WordPress hosting specialist.
