The Complete Guide to DNS Records: A, AAAA, CNAME, MX, TXT, and More

DNS Is the Phonebook Your Website Cannot Live Without

Every domain on the internet depends on the Domain Name System to function. DNS translates human-readable domain names into the IP addresses that servers and networks actually understand. When someone types your domain into a browser, DNS is the first system that responds — before your server, before your application, before a single pixel renders on screen. If DNS is misconfigured, nothing else matters.

This guide breaks down the most common DNS record types, explains when and why you use each one, and covers the practical troubleshooting that hosting customers need to know. Whether you are setting up a brand-new domain or debugging why email stopped working after a migration, this is the reference you will come back to.

A Records and AAAA Records

The A record is the most fundamental DNS record. It maps a domain name to an IPv4 address — the familiar four-number format like 203.0.113.50. When a browser resolves your domain, the A record is what ultimately tells it which server to contact.

The AAAA record does the same thing for IPv6 addresses. IPv6 adoption is growing, and having both A and AAAA records ensures your site is reachable regardless of the visitor's network configuration. If your hosting provider supports IPv6, add the AAAA record alongside your A record. There is no downside, and it future-proofs your setup.

You can have multiple A records for the same domain, each pointing to a different IP address. This is a simple form of load balancing called DNS round-robin — the resolver cycles through the addresses, distributing traffic across servers. It is not sophisticated, but it works for basic redundancy.

CNAME Records

A CNAME (Canonical Name) record creates an alias from one domain name to another. Instead of pointing to an IP address, it points to a different hostname. For example, you might create a CNAME record that maps www.example.com to example.com, or to a CDN endpoint like cdn.provider.com.

There is one critical rule: you cannot place a CNAME at the zone apex (the root domain, e.g., example.com without any subdomain). The apex must use A or AAAA records. Some DNS providers work around this limitation with proprietary record types like ALIAS or ANAME, which behave like CNAMEs at the apex. If your setup requires pointing the root domain to a hostname rather than an IP, check whether your DNS provider supports this.

CNAME records are heavily used for CDN integration, SaaS platform custom domains, and any scenario where you want a subdomain to follow the DNS resolution of another hostname.

MX Records

MX (Mail Exchanger) records tell the internet where to deliver email for your domain. Each MX record points to a mail server hostname and includes a priority value. Lower priority numbers are tried first. If the primary mail server is unreachable, the sending server moves to the next highest priority.

A typical MX configuration for a business using a hosted email service might look like this: two MX records, each pointing to a different mail server hostname, with priorities of 10 and 20. This provides redundancy — if one server is down, email delivery still works.

Getting MX records wrong is the number one reason email stops working after a domain migration or DNS change. Always verify MX records after any change using command-line tools like dig MX example.com or online DNS lookup tools. And remember: MX records point to hostnames, not IP addresses. If the hostname itself does not have a valid A record, email delivery will fail silently.

TXT Records

TXT records store arbitrary text data associated with your domain. They are used for a wide variety of purposes, but the most important ones for hosting customers are email authentication and domain ownership verification.

SPF (Sender Policy Framework)

An SPF record declares which servers are authorized to send email on behalf of your domain. It is published as a TXT record and looks something like v=spf1 include:_spf.google.com ~all. Mail servers that receive email from your domain check this record to decide whether the sending IP is legitimate. Without SPF, your emails are far more likely to land in spam folders.

DKIM and DMARC

DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting, and Conformance) also use TXT records. DKIM publishes a public key that receiving servers use to verify email signatures. DMARC defines a policy for what happens when SPF or DKIM checks fail — reject the message, quarantine it, or allow it through with a report.

These three records — SPF, DKIM, and DMARC — form the foundation of email security. If you send any email from your domain (including transactional emails from your application), all three should be properly configured.

Domain Verification

Many services — analytics platforms, search consoles, certificate authorities — verify domain ownership by asking you to add a specific TXT record. These are typically one-time verifications, but some services require the record to remain in place.

CAA Records

Certificate Authority Authorization (CAA) 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 — even if an attacker somehow tricks a CA into validating their control of your domain.

A CAA record might look like 0 issue "letsencrypt.org", meaning only Let's Encrypt can issue certificates. You can list multiple CAs. If no CAA record exists, any CA can issue certificates for your domain. Adding CAA records is a low-effort, high-value security improvement.

NS Records

NS (Name Server) records delegate DNS authority for a domain or subdomain to specific name servers. When you register a domain and point it to your hosting provider's nameservers, you are updating the NS records at the registrar level.

NS records are typically managed at the registrar and rarely changed after initial setup. However, understanding them is important during migrations. If you change hosting providers, you may need to update NS records to point to the new provider's nameservers — and that change takes time to propagate.

TTL Strategy: Getting Cache Timing Right

Every DNS record has a TTL (Time To Live) value, expressed in seconds. TTL tells DNS resolvers how long to cache a record before checking for updates. A TTL of 3600 means the record is cached for one hour.

High TTL values (hours or days) reduce DNS query volume and improve resolution speed. Low TTL values (minutes) mean changes propagate faster but increase DNS query load. The right strategy depends on your situation:

• Stable environments: Use TTLs of 3600 to 86400 (1 hour to 24 hours). Your records rarely change, so long caching is safe and performant.
• Before a migration: Lower TTLs to 300 seconds (5 minutes) at least 48 hours before you make changes. This ensures that when you update the record, the old value is not cached for hours across the internet.
• After a migration: Once you have confirmed the new records are correct and traffic is flowing properly, raise TTLs back to their normal values.

DNS Propagation: Why Changes Are Not Instant

DNS propagation refers to the time it takes for updated records to be reflected across all DNS resolvers worldwide. Because resolvers cache records based on TTL, a change you make right now may not be visible to all users for hours or even days, depending on the old TTL value.

There is no way to force instant global propagation. What you can do is manage expectations: lower TTLs before changes, verify records using multiple DNS checking tools, and plan migrations during low-traffic windows to minimize the impact of stale caches.

Troubleshooting DNS Issues

When something goes wrong with DNS, the symptoms are often vague: "the site is down," "email stopped working," "the certificate validation failed." Here are the commands and steps that help you diagnose quickly.

• dig or nslookup: Query specific record types. dig A example.com shows your A records. dig MX example.com shows mail servers. dig TXT example.com shows SPF, DKIM, and verification records.
• Check from multiple locations: DNS results can vary by geography and resolver. Use online tools that query from multiple global points to confirm propagation status.
• Verify the chain: Make sure NS records point to the right nameservers, those nameservers are responding, and the records hosted there match what you expect.
• Check for typos: An astonishing number of DNS issues come down to a mistyped IP address, a missing dot at the end of a hostname, or a priority value in the wrong field.

Putting It All Together

DNS is not glamorous, but it is foundational. A properly configured DNS zone — with accurate A/AAAA records, correct MX entries, complete SPF/DKIM/DMARC, appropriate TTL values, and CAA restrictions — is the backbone of a reliable, secure, and discoverable web presence.

Take the time to audit your DNS zone at least once a quarter. Remove stale records, verify that email authentication is intact, and make sure your TTL strategy supports your operational needs. When something breaks, DNS is often the first place to look — and the faster you can navigate it, the faster you resolve the issue.