DNS Records Explained: A, AAAA, MX, CNAME, TXT, NS

Every time you type a domain name into your browser, a complex chain of lookups happens behind the scenes to translate that human-readable name into a machine-readable IP address. The system responsible for this translation is the Domain Name System (DNS), and the instructions that make it work are called DNS records.

Think of DNS as the phonebook of the internet. Just as a phonebook maps a person’s name to their phone number, DNS maps domain names like example.com to IP addresses like 93.184.216.34. But DNS does far more than simple name-to-address translation. Different DNS record types handle email routing, domain aliases, security verification, and nameserver delegation.

Whether you’re a web developer deploying a new site, a sysadmin migrating email providers, or a small business owner trying to verify your domain with Google Workspace, understanding how DNS records work is essential. Misconfigured DNS records are one of the most common causes of website downtime, email delivery failures, and failed SSL certificate issuance. In this guide, we’ll break down every major DNS record type with real-world examples you can reference when managing your own domains.

How DNS Works (Brief Overview)

Before diving into individual record types, it helps to understand how DNS works at a high level. For a more detailed walkthrough of the full resolution chain, see our guide on how DNS works. When you enter www.example.com in your browser, the following DNS lookup process occurs:

1. Recursive Resolver — Your device sends the query to a DNS resolver (typically provided by your ISP or a service like Google Public DNS at 8.8.8.8). The resolver acts as an intermediary and does the heavy lifting.
2. Root Nameserver — If the resolver doesn’t have the answer cached, it contacts one of the 13 root nameserver clusters. The root server doesn’t know the IP address directly, but it knows which servers are authoritative for .com.
3. TLD Nameserver — The resolver then queries the Top-Level Domain (TLD) nameserver for .com, which responds with the authoritative nameservers for example.com.
4. Authoritative Nameserver — Finally, the resolver queries the authoritative nameserver for example.com, which holds the actual DNS records. This server returns the A record (or whichever record was requested), and the resolver passes the IP address back to your browser.

This entire process typically completes in under 100 milliseconds, and the result is cached at multiple levels to speed up subsequent lookups. The DNS records stored on that authoritative nameserver are what we’ll explore in detail below.

Common DNS Record Types

There are dozens of DNS record types defined in various RFCs, but most domain owners will only work with six or seven regularly. Here’s what each one does and when you’ll encounter it.

A Record (Address Record)

The A record is the most fundamental DNS record type. It maps a domain name directly to an IPv4 address, which is how browsers know where to send HTTP requests for your website. Nearly every domain on the internet has at least one A record.

example.com.    300    IN    A    93.184.216.34

When you set up web hosting, the first thing your provider typically asks you to do is create an A record pointing your domain to their server’s IP address. You can also create A records for subdomains — for example, pointing blog.example.com to a different server than your main site.

It’s worth noting that you can have multiple A records for the same domain name, each pointing to a different IP address. This is called round-robin DNS and is a basic form of load balancing where resolvers rotate through the available addresses.

AAAA Record (IPv6 Address Record)

The AAAA record (pronounced “quad-A”) is the IPv6 equivalent of the A record. It maps a domain name to a 128-bit IPv6 address instead of a 32-bit IPv4 address. The name “AAAA” reflects the fact that an IPv6 address is four times the length of an IPv4 address.

example.com.    300    IN    AAAA    2606:2800:0220:0001:0248:1893:25c8:1946

AAAA records exist because IPv4 address space is exhausted. IPv4 provides roughly 4.3 billion unique addresses, which seemed like more than enough in the 1980s but ran out as billions of devices came online. IPv6 provides approximately 340 undecillion addresses — enough for the foreseeable future. Our guide on IPv4 vs. IPv6 explains the technical differences in detail. If your hosting provider supports IPv6, you should create both A and AAAA records so your site is reachable over either protocol.

CNAME Record (Canonical Name Record)

A CNAME record creates an alias that points one domain name to another domain name (not to an IP address). When a resolver encounters a CNAME, it follows the chain and performs an additional lookup on the target domain to get the final IP address.

www.example.com.    3600    IN    CNAME    example.com.

The most common use of a CNAME record is pointing the www subdomain to the apex (bare) domain. CNAME records are also widely used when connecting to third-party services — for example, pointing shop.example.com to shops.myshopify.com or docs.example.com to a GitHub Pages URL.

There is one critical rule to understand about CNAME records: a CNAME cannot coexist with any other record type at the same name. This means you cannot place a CNAME at your apex domain (example.com) because the apex already needs NS records and usually SOA records. This is a common source of confusion, and it’s the reason many DNS providers offer proprietary solutions like ALIAS or ANAME records that behave like CNAMEs at the apex. Understanding the difference between a DNS A record vs CNAME is fundamental: A records point to IP addresses directly, while CNAMEs point to other domain names.

MX Record (Mail Exchanger Record)

The MX record tells the internet where to deliver email for your domain. When someone sends an email to user@example.com, the sending mail server performs a DNS lookup for MX records on example.com to find out which mail server should receive the message. If you’ve ever wondered what is an MX record — it’s the DNS record that makes email work.

example.com.    3600    IN    MX    1  aspmx.l.google.com.
example.com.    3600    IN    MX    5  alt1.aspmx.l.google.com.
example.com.    3600    IN    MX    5  alt2.aspmx.l.google.com.
example.com.    3600    IN    MX    10 alt3.aspmx.l.google.com.
example.com.    3600    IN    MX    10 alt4.aspmx.l.google.com.

Priority values are what make MX records unique among DNS record types. They allow you to define primary and backup mail servers. In the example above, aspmx.l.google.com (priority 1) is the preferred server. If it’s down, the sending server tries the alternates in order of their priority values. Two servers with the same priority (like the two priority-5 servers above) will receive mail in a round-robin fashion.

Getting MX records wrong is one of the fastest ways to break email delivery for your entire domain. If you’re migrating between email providers, always verify your MX records are correct after making changes — you can check DNS records for any domain using a DNS lookup tool.

TXT Record (Text Record)

TXT records store arbitrary text data associated with a domain name. Originally designed for human-readable notes, TXT records have become one of the most important DNS record types for security and verification. If you’re asking what is a TXT record used for, the answer is almost always email authentication or domain verification.

;; SPF record - authorizes mail servers to send on behalf of your domain
example.com.    3600    IN    TXT    "v=spf1 include:_spf.google.com ~all"

;; DMARC record - email authentication policy
_dmarc.example.com.    3600    IN    TXT    "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

;; Google domain verification
example.com.    3600    IN    TXT    "google-site-verification=abc123def456..."

The three most common uses for TXT records are:

• SPF (Sender Policy Framework) — Specifies which mail servers are authorized to send email on behalf of your domain. Without an SPF record, your emails are far more likely to land in spam folders.
• DKIM (DomainKeys Identified Mail) — Uses cryptographic signatures to verify that email content hasn’t been tampered with in transit. DKIM keys are published as TXT records at specific subdomains.
• DMARC (Domain-based Message Authentication) — Builds on SPF and DKIM to tell receiving servers what to do when authentication fails (reject, quarantine, or do nothing) and where to send aggregate reports.

TXT records are also how services like Google Search Console, Microsoft 365, and various CDN providers verify that you own a domain. They’ll give you a unique string to add as a TXT record, then check for its presence to confirm ownership.

NS Record (Nameserver Record)

NS records specify which nameservers are authoritative for a domain or subdomain. They are the foundation of how DNS delegation works — when you register a domain and point it to a hosting provider’s nameservers, you’re setting NS records at the registrar level.

example.com.    86400    IN    NS    ns1.examplehost.com.
example.com.    86400    IN    NS    ns2.examplehost.com.
example.com.    86400    IN    NS    ns3.examplehost.com.

There are two places where NS records matter. First, at the registrar level — these are the nameserver settings you configure when you buy a domain (e.g., setting Cloudflare’s nameservers). Second, within your DNS zone file — these NS records should match what the registrar has and can also be used to delegate subdomains to different nameservers entirely. For example, you might delegate api.example.com to a different DNS provider than your main domain.

Other DNS Record Types Worth Knowing

Beyond the six core record types above, there are several others you may encounter:

• SOA (Start of Authority) — Every DNS zone has exactly one SOA record. It contains metadata about the zone including the primary nameserver, the responsible administrator’s email, the zone serial number, and refresh/retry intervals. You rarely need to edit this directly.
• SRV (Service Record) — Specifies the host and port for specific services. Commonly used by Microsoft Active Directory, SIP/VoIP services, and some game servers. SRV records include priority and weight values for load balancing.
• CAA (Certification Authority Authorization) — Specifies which certificate authorities are permitted to issue SSL/TLS certificates for your domain. Adding CAA records is a security best practice that prevents unauthorized CAs from issuing certificates.
• PTR (Pointer Record) — The reverse of an A record. Instead of mapping a domain to an IP, a PTR record maps an IP address back to a domain name. PTR records are essential for reverse DNS lookups and are commonly checked by mail servers to verify sender legitimacy. Our article on what is reverse DNS covers PTR records and email deliverability in depth.

How to Check DNS Records

Knowing how to check DNS records is a practical skill that comes up regularly during site migrations, email troubleshooting, and SSL certificate setup. There are two main approaches: command-line tools and web-based tools.

Command-Line Tools

The two most common command-line tools for DNS lookups are nslookup (available on Windows, macOS, and Linux) and dig (available on macOS and Linux, installable on Windows).

# Look up A records
nslookup example.com

# Look up MX records
nslookup -type=mx example.com

# Look up TXT records
nslookup -type=txt example.com

# Query a specific DNS server
nslookup example.com 8.8.8.8

# Look up A records
dig example.com A

# Look up all record types
dig example.com ANY

# Look up MX records with short output
dig example.com MX +short

# Trace the full resolution path
dig example.com +trace

Online DNS Lookup Tools

If you prefer a visual interface or need to check DNS records from a different geographic location, online tools are the way to go. You can check DNS records for any domain using our DNS lookup tool, which queries multiple record types simultaneously and shows results in a clean, readable format.

When to Check DNS Records

There are several common scenarios where checking DNS records is essential:

• Website migration — After changing hosting providers, verify that A records and CNAME records point to the new server before assuming the migration is complete.
• Email troubleshooting — If emails are bouncing or landing in spam, check MX records for correct mail server configuration and TXT records for proper SPF, DKIM, and DMARC setup. DNS issues are one of the most common causes of network problems; see our network connectivity troubleshooting guide for a step-by-step approach.
• SSL certificate issuance — Many SSL providers (especially Let’s Encrypt with DNS-01 challenges) require you to create specific TXT records for domain validation. Verifying these records are in place saves time and failed attempts.
• Nameserver changes — After updating NS records at your registrar, checking propagation ensures the new nameservers are responding correctly before you make further changes.

DNS Propagation and TTL

DNS propagation is the process by which updated DNS records spread across the global network of recursive resolvers. When you change a DNS record, that change doesn’t take effect everywhere simultaneously — and understanding why requires knowing how TTL works.

TTL (Time to Live) is a value set on every DNS record that tells resolvers how long (in seconds) they should cache the record before requesting a fresh copy from the authoritative nameserver. A TTL of 3600 means resolvers will serve the cached version for one hour before checking for updates.

300     = 5 minutes   (good for records that change frequently)
3600    = 1 hour      (standard default for most records)
14400   = 4 hours     (common for stable records)
86400   = 24 hours    (typical for NS records and stable configs)

When you update a DNS record, resolvers that have the old record cached will continue serving it until their cached copy expires based on the TTL. This is why DNS changes aren’t instant. In practice, most DNS changes propagate within 15 minutes to 4 hours. The commonly cited “up to 48 hours” timeframe is a worst case that accounts for resolvers that don’t strictly honor TTL values or have very long cache durations.

Pro tip: If you know you’re going to make DNS changes, lower the TTL to 300 seconds (5 minutes) at least 24 hours before the planned change. This ensures that by the time you make the actual switch, most resolvers have the short TTL cached, and your new records will propagate much faster. After the change is confirmed, you can raise the TTL back to a longer duration.

Common DNS Mistakes to Avoid

Even experienced administrators make DNS configuration errors. Here are the most common mistakes and how to avoid them:

• Using a CNAME at the apex domain — As discussed earlier, placing a CNAME record at the zone apex (example.com) violates the DNS specification because it conflicts with the required SOA and NS records. If you need CNAME-like behavior at the apex, use a DNS provider that offers ALIAS or ANAME records, or use an A record instead.
• Incorrect MX priority values — Setting all MX records to the same priority when your provider expects a specific hierarchy, or accidentally giving a backup server the lowest (highest-priority) number. Always follow your email provider’s recommended MX configuration exactly.
• Missing SPF, DKIM, or DMARC records — Without proper email authentication DNS records, your domain is vulnerable to spoofing and your legitimate emails are more likely to be flagged as spam. At a minimum, every domain that sends email should have an SPF TXT record. Domains that do not send email should publish "v=spf1 -all" to explicitly prevent spoofing.
• High TTL before a migration — If your DNS records have a 24-hour TTL and you change your A record to point to a new server, some users will continue reaching the old server for up to a full day. Always lower TTL values well in advance of planned changes.
• Forgetting trailing dots in zone files — In raw DNS zone file syntax, fully qualified domain names end with a dot (e.g., example.com.). Omitting the trailing dot can cause the DNS server to append the zone name, resulting in records like example.com.example.com. Most managed DNS dashboards handle this automatically, but it’s a common issue when editing zone files directly.
• Not verifying after changes — Always confirm your DNS changes are working correctly by using a DNS lookup tool or command-line tools. Don’t assume the change worked just because you saved it in the dashboard.

Frequently Asked Questions