DNS (Domain Name System) is the system that translates human-readable domain names like example.com into the numeric IP addresses that computers use to find each other on the internet. DNS records are the individual entries in this system, each serving a specific purpose, from pointing your domain to a web server to routing email to the right mail server. Without DNS, you would need to remember IP addresses for every website you visit.
How DNS Resolution Works Step by Step
When you type a domain name into your browser, a series of lookups happens before the page loads. Understanding this process helps you troubleshoot issues and set reasonable TTL values:
- Browser cache: Your browser first checks its own cache to see if it already knows the IP address for the domain. If you visited the site recently, the answer might already be stored locally.
- Operating system cache: If the browser does not have it cached, it asks the operating system, which maintains its own DNS cache.
- Recursive resolver: If neither cache has the answer, your computer sends a request to a recursive DNS resolver, typically operated by your internet provider (ISP) or a public service like Cloudflare (1.1.1.1) or Google (8.8.8.8).
- Root nameserver: The resolver queries one of the 13 root nameserver clusters. The root server does not know the final IP address, but it knows which nameservers are responsible for the top-level domain (.com, .org, .de, etc.).
- TLD nameserver: The resolver queries the TLD nameserver for .com (or whatever the extension is). This server responds with the authoritative nameservers for the specific domain.
- Authoritative nameserver: Finally, the resolver queries the authoritative nameserver for example.com, which returns the actual IP address from the A (or AAAA) record.
- Response: The resolver sends the IP address back to your browser, which can now connect to the web server and load the page.
This entire process typically takes 20 to 100 milliseconds. Once resolved, the result is cached at multiple levels, so subsequent visits are faster.
All Common DNS Record Types Explained
DNS supports many record types, each with a distinct role. Here are the ones you will encounter when managing a WordPress site:
- A Record: The most fundamental record type. It maps a domain name to an IPv4 address (e.g.,
example.comto93.184.216.34). You can have multiple A records for the same domain to distribute traffic across multiple servers (round-robin load balancing). - AAAA Record: The IPv6 equivalent of the A record. Maps a domain to an IPv6 address (e.g.,
2606:2800:220:1:248:1893:25c8:1946). As IPv6 adoption grows, having AAAA records alongside A records ensures your site is reachable on both protocols. - CNAME Record: Creates an alias from one domain to another. For example, you might point
www.example.comtoexample.com, orshop.example.comtomyshop.shopify.com. Important limitation: a CNAME cannot coexist with other record types at the same name (you cannot have both a CNAME and an MX record for the same subdomain). - MX Record: Specifies which mail servers handle email for your domain. Each MX record has a priority value (lower number means higher priority). If your primary mail server is down, email will be delivered to the server with the next-lowest priority number.
- TXT Record: A versatile record that stores arbitrary text data. Its most common uses are SPF records for email authentication, DKIM keys, DMARC policies, and domain verification for services like Google Search Console or Microsoft 365.
- NS Record: Specifies the authoritative nameservers for your domain. When you register a domain, you set NS records to point to your DNS provider (e.g., Cloudflare, Route 53, or your hosting company's nameservers). Changing NS records effectively delegates control of your domain's DNS to a different provider.
- SOA Record: The "Start of Authority" record contains administrative information about the DNS zone, including the primary nameserver, the email address of the DNS administrator, the zone's serial number, and timing values for how often secondary nameservers should check for updates.
- SRV Record: Specifies the host and port for specific services. Used less commonly for websites, but relevant for services like SIP (VoIP), XMPP (chat), or Microsoft Active Directory.
- CAA Record: Certificate Authority Authorization records specify which certificate authorities are allowed to issue SSL/TLS certificates for your domain. This is a security measure that prevents unauthorized CAs from issuing certificates for your site. For example, you might set a CAA record that only allows Let's Encrypt to issue certificates for your domain.
SPF, DKIM, and DMARC for Email Authentication
If your WordPress site sends email (contact form notifications, WooCommerce order confirmations, password resets), email authentication is critical. Without it, your emails are more likely to land in spam folders or be rejected entirely. These three standards work together and are all configured through DNS TXT records:
- SPF (Sender Policy Framework): A TXT record that lists which servers are authorized to send email on behalf of your domain. For example,
v=spf1 include:_spf.google.com include:sendgrid.net -allsays that Google and SendGrid are authorized senders, and all other servers should be rejected. Without SPF, anyone can forge emails that appear to come from your domain. - DKIM (DomainKeys Identified Mail): Adds a digital signature to every outgoing email. The public key is published as a DNS TXT record, and the receiving mail server uses it to verify the signature. This proves the email was not tampered with in transit and actually came from your server.
- DMARC (Domain-based Message Authentication, Reporting, and Conformance): Builds on SPF and DKIM by telling receiving mail servers what to do when authentication fails. You can instruct them to reject the email, quarantine it (put it in spam), or just monitor and report. A basic DMARC record looks like:
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com
Setting up all three is especially important if you use a transactional email service (like Mailgun, SendGrid, or Amazon SES) to send WordPress emails. Without proper authentication, your order confirmations and password reset emails may never reach your customers.
TTL and What It Means for DNS Propagation
Every DNS record has a TTL (Time to Live) value, measured in seconds. This tells DNS resolvers how long they can cache the record before checking for an update. Common TTL values are:
300(5 minutes): Good for records that change frequently or when you are preparing for a migration.3600(1 hour): A reasonable default for most records.86400(24 hours): Appropriate for records that rarely change, like NS records.
When people talk about "DNS propagation taking up to 48 hours," they are referring to the time it takes for cached records around the world to expire and be refreshed with new data. If your current TTL is set to 86400 seconds (24 hours), resolvers that cached the old record could keep using it for up to 24 hours after you make a change.
A practical tip: if you are planning a server migration or DNS change, lower the TTL to 300 seconds a day or two before the switch. That way, when you update the records, the old cached values expire within 5 minutes, and the transition is much smoother.
DNS and CDN Configuration
When you set up a CDN (Content Delivery Network) like Cloudflare, you typically change your DNS to route traffic through the CDN. There are two common approaches:
- CNAME setup: You create a CNAME record pointing your domain to the CDN's edge server (e.g.,
example.com.cdn.cloudflare.net). This is common with CDN providers like KeyCDN, BunnyCDN, or AWS CloudFront. The limitation is that CNAME records at the zone apex (the bare domain,example.comwithout www) technically violate the DNS specification, although some providers work around this with proprietary solutions. - NS/Full proxy setup: With Cloudflare's full setup, you change your domain's NS records to point to Cloudflare's nameservers. Cloudflare then manages all your DNS records and proxies traffic through its network. This is the most common approach because it allows Cloudflare to work at the zone apex without CNAME limitations.
WordPress-Specific DNS Considerations
When setting up DNS for a WordPress site, there are a few things to keep in mind:
- Domain pointing: Your A record should point to your hosting server's IP address. If you are on shared hosting, your host will provide the IP. On a VPS or dedicated server, use the server's public IP address. Make sure both
example.comandwww.example.comresolve correctly (either through an A record and a CNAME, or two A records). - Email setup: Many WordPress hosts do not include email hosting. If you use Google Workspace or Microsoft 365 for email, you need to set the correct MX records and add SPF/DKIM TXT records as specified by your email provider. Getting these wrong means your contact form notifications might not arrive.
- Subdomain setup: For WordPress multisite with subdomain configuration, or if you run a staging site at
staging.example.com, you need additional A records or CNAME records for each subdomain. Wildcard DNS records (*.example.com) can simplify this for multisite installations. - Domain verification: Google Search Console, Facebook Business, Pinterest, and other services ask you to verify domain ownership by adding a TXT record. These records do not affect your site's functionality; they simply prove you control the domain.
What InspectWP Checks
InspectWP retrieves and displays the DNS records for your WordPress site's domain, including A, AAAA, MX, TXT, NS, and CNAME records. This gives you a quick overview of your DNS configuration without needing to log into your DNS provider's dashboard. It helps you verify that your domain is pointing to the right server, that MX records are configured for email delivery, and that essential TXT records (like SPF) are in place. Spotting a misconfigured or missing record here can save you hours of debugging email delivery problems or connectivity issues.