DNS Setup for WordPress: Complete Guide

Getting DNS wrong when launching a WordPress site is one of the most common causes of downtime, broken email, and SSL certificate failures. Whether you are moving an existing WordPress install to a new host, configuring a brand-new domain, or troubleshooting a site that refuses to load, understanding exactly which DNS records to create — and in what order — saves hours of frustration. This guide covers every record type you will need, the exact values to enter in your DNS zone, propagation timelines, and how to verify everything is working before you go live.

Understanding What DNS Does for a WordPress Site

DNS translates your domain name into the IP address of the server running WordPress. Without the correct records in place, visitors, search engines, and your own browser cannot find your site. Beyond basic name resolution, DNS also controls where your email is delivered, whether your CDN serves your static assets, and whether your SSL certificate can be issued automatically. Every one of these functions depends on a different record type inside your DNS zone.

• A record — maps your domain to an IPv4 address
• AAAA record — maps your domain to an IPv6 address
• CNAME record — creates an alias pointing to another hostname
• MX record — routes inbound email
• TXT record — used for domain verification, SPF, DKIM, DMARC
• NS record — delegates DNS authority to your nameservers

Step 1: Find Your WordPress Host IP Address

Log in to your hosting control panel — cPanel, Plesk, Kinsta, WP Engine, SiteGround, Cloudways, or whatever your provider uses — and locate your server's IP address. It is usually shown on the hosting dashboard, in the welcome email, or under a section labelled "Server Information" or "Account Details". Write it down; you will paste it into every A record you create.

If your host uses a load balancer or assigns a hostname instead of an IP (common on managed WordPress hosts like WP Engine and Kinsta), they will give you a CNAME target such as yoursite.wpengine.com or dc2.kinsta.cloud. In that case you will use a CNAME record for the www subdomain instead of an A record, but you still need an A record for the root domain — more on that below.

Step 2: Log In to Your DNS Provider

DNS is managed wherever your domain's nameservers point. This is usually one of three places:

1. Your domain registrar (Namecheap, GoDaddy, Porkbun, Google Domains/Squarespace, Hover)
2. Your hosting provider's DNS (if you pointed nameservers there)
3. A third-party DNS service (Cloudflare, AWS Route 53, DNSimple)

If you are not sure where DNS is hosted, run a quick NS lookup. Use our DNS Lookup tool to query the NS records for your domain — the results will tell you exactly which company is authoritative for your zone.

Step 3: Create the Core A Records

You need two A records: one for the root domain (@ or blank) and one for www. Both should point to the same server IP unless your host tells you otherwise.

If your host provides a CNAME target instead of an IP, the www record becomes:

Note: you cannot use a CNAME for the root domain (@) because the DNS specification forbids it. Hosts that use CNAME-only setups (like Kinsta) require you to use a DNS provider that supports CNAME flattening or ALIAS records at the root — Cloudflare, DNSimple, and Route 53 all support this. If your current registrar does not, move your DNS to Cloudflare for free.

Step 4: Configure the WWW Redirect at the Application Level

DNS gets traffic to your server, but the choice between yourdomain.com and www.yourdomain.com as your canonical URL is made inside WordPress and your web server. Set your preferred URL in WordPress under Settings > General (both WordPress Address and Site Address fields). Then enforce the redirect in your web server config or via a plugin so every request ends up at the canonical version. This prevents duplicate content issues with search engines.

Step 5: Set Up Email MX Records

If you send or receive email at your domain, MX records are mandatory. Your email provider will give you the exact values. Common setups:

Google Workspace:

Microsoft 365:

Delete any existing MX records from your registrar or host before adding these. Old MX records left in place split your mail flow and cause sporadic delivery failures.

Step 6: Add SPF, DKIM, and DMARC TXT Records

Without these three records, email from your WordPress site (contact forms, WooCommerce order confirmations, password resets) will land in spam or be rejected outright.

SPF — tells receiving mail servers which IPs are allowed to send on behalf of your domain:

DKIM — a cryptographic signature. Your email provider generates the key; you paste the TXT record they give you. It will look something like:

DMARC — sets policy for handling messages that fail SPF or DKIM. Start with monitoring mode:

Step 7: Domain Verification TXT Records

Google Search Console, Bing Webmaster Tools, and your hosting provider may ask you to add a TXT record to verify domain ownership. These records do nothing to DNS routing — they are just a proof-of-ownership mechanism. Add them exactly as provided, usually at the root (@):

Multiple TXT records on the same name are allowed and normal.

Step 8: Set Up Cloudflare (Optional but Recommended)

Cloudflare acts as a reverse proxy, CDN, and DNS provider simultaneously. For most WordPress sites it is free and provides meaningful performance and security benefits. To use it, sign up at cloudflare.com, add your domain, import your existing DNS records (Cloudflare auto-imports them), then update your domain's nameservers at your registrar to the two Cloudflare nameservers shown in the dashboard.

Key Cloudflare settings for WordPress:

• Set SSL/TLS mode to Full (Strict) — never use Flexible, which creates redirect loops with WordPress
• Enable Always Use HTTPS under SSL/TLS > Edge Certificates
• Install the Cloudflare plugin in WordPress and enable APO (Automatic Platform Optimisation) for caching at the edge
• Proxy status (orange cloud) should be ON for A and CNAME records that point to your WordPress server; keep it OFF (grey cloud) for mail records

Step 9: Understanding Propagation and TTL

Once you save DNS records, changes do not appear everywhere instantly. Resolvers around the world cache records for the duration of the TTL (Time To Live) value. A TTL of 3600 means up to one hour of caching. Before a major migration, lower your TTLs to 300 (5 minutes) at least 24 hours in advance so propagation is faster when you make the switch.

Full global propagation typically takes 1 to 48 hours depending on the previous TTL. Your ISP's resolver caching is usually the longest delay, not the authoritative nameserver itself.

Step 10: Verify Your DNS Records Are Correct

Do not assume the records saved correctly. Verify each one from the command line or an online tool. On macOS and Linux:

On Windows, use nslookup:

The values returned should exactly match what you entered in your DNS panel. If they do not match yet, wait for TTL to expire and try again.

Common DNS Mistakes That Break WordPress

• Leaving old A records pointing to the old server. Most DNS panels keep existing records when you add new ones. Delete the old A record before or immediately after adding the new one.
• Cloudflare SSL set to Flexible. This causes an infinite redirect loop because WordPress forces HTTPS internally while Cloudflare serves plain HTTP to the origin. Always use Full (Strict).
• Missing www record. If only the root domain has an A record, www visitors get a DNS error. Always create both.
• CNAME on the root domain. Not valid DNS. Use ALIAS/ANAME or switch to a DNS provider that supports CNAME flattening.
• Duplicate SPF records. You can only have one SPF TXT record on the root. Merge all include statements into a single record.
• Forgetting to update nameservers after changing hosts. Your DNS zone edits at the new host do nothing if your registrar still points NS records at the old host.

DNS Checklist Before Going Live

1. A record for root domain points to correct server IP
2. A record (or CNAME) for www points to correct server IP or hostname
3. WordPress Site URL and WordPress URL match in Settings > General
4. MX records updated to your email provider
5. SPF, DKIM, and DMARC TXT records in place
6. SSL certificate issued and valid (check padlock in browser)
7. Cloudflare SSL mode set to Full (Strict) if using Cloudflare
8. Old conflicting records deleted
9. Propagation confirmed from multiple global locations
10. Test form submission, order confirmation email, and password reset email delivered successfully

Troubleshooting After DNS Changes

If your site is not loading after updating DNS, work through these checks in order. First, confirm propagation has actually reached your location — flush your local DNS cache before testing:

Then test using Google's public resolver to bypass your ISP's cache:

If Google resolves the correct IP but your browser still shows the old site, your local ISP cache is the culprit — wait for TTL expiry or use a VPN to test from a different resolver. If Google also returns the wrong IP, your DNS records were not saved correctly; log back into your DNS panel and verify the records are actually there.

For SSL errors after moving to a new server, the certificate usually needs to be re-issued. On cPanel hosts, go to SSL/TLS > Let's Encrypt and issue a new certificate. On Cloudflare, the edge certificate is automatic — wait 15 minutes after DNS propagation and it will provision itself. If you see a certificate for the old server's hostname, your browser has cached an old HSTS or OCSP response; try an incognito window first.