Skip to content

June 6, 2026 · 10 min read

DNS Records Explained (A, AAAA, MX, TXT, CNAME)

What each DNS record type does — A and AAAA for addresses, MX for email, CNAME for aliases, TXT for verification and SPF/DKIM, NS for nameservers — plus TTL and propagation in plain English.

Every time you open a website, send an email, or verify a domain, you're reading DNS records — the small text entries that tell the internet where your domain points. This guide explains the record types you'll actually meet, what each one looks like, and how TTL and propagation decide when your changes go live. You can see all of these for any domain with our DNS lookup tool.

Quick answer

RecordPurposePoints toExample value
AIPv4 addressAn IPv4 address104.16.132.229
AAAAIPv6 addressAn IPv6 address2606:4700::6810:84e5
CNAMEAliasAnother hostnameexample.com.
MXEmail routingA mail-server hostname + priority10 mail.example.com.
TXTText / verificationFree textv=spf1 include:_spf.google.com ~all
NSNameserversThe authoritative DNS serversns1.example.com.

A single domain usually has several types at once — A/AAAA for the website, MX for email, TXT for verification, and NS delegating who answers for it.

A and AAAA — addresses

The two address records are the workhorses of DNS. Both answer the question "what IP do I connect to?" — they just speak different versions of the Internet Protocol.

  • A record → an IPv4 address (104.16.132.229)
  • AAAA record → an IPv6 address (2606:4700::6810:84e5)

A domain can publish both; a client uses whichever its network supports (modern devices prefer IPv6 when available). If a site loads on one device but not another, mismatched or missing AAAA records are a classic culprit. For the difference between the two protocols, see IPv4 vs IPv6 Explained.

CNAME — aliases

A CNAME (canonical name) record says "this name is really another name." It's how www.example.com can point at example.com, or how a custom domain points at a hosting provider like myapp.netlify.app.

Two rules trip people up:

  1. No CNAME at the apex. You can't put a CNAME on the root domain (example.com) next to required records like MX and NS. Providers offer "ALIAS"/"ANAME"/"flattening" to work around this.
  2. A CNAME can't coexist with other record types on the same name. The alias is the answer.

MX — where email goes

MX (mail exchange) records route email. When another server wants to email you@example.com, it looks up your MX records to find the receiving mail servers.

Priority   Mail server
10         aspmx.l.google.com.
20         alt1.aspmx.l.google.com.
  • The lower the priority number, the higher the preference — senders try 10 before 20.
  • MX records point to hostnames, not IPs, and those hostnames need their own A/AAAA records.
  • No MX records usually means the domain can't receive email.

TXT — verification and email authentication

TXT records hold free-form text, and they quietly do some of the most important jobs in DNS:

  • SPF — lists which servers may send mail for your domain: v=spf1 include:_spf.google.com ~all
  • DKIM — publishes a public key used to sign your outgoing mail.
  • DMARC — sets a policy for what to do with mail that fails SPF/DKIM.
  • Domain verification — strings like google-site-verification=… that prove you own the domain.

If your email is landing in spam, your TXT (SPF/DKIM/DMARC) records are the first place to look.

NS — who's in charge

NS (nameserver) records list the authoritative servers for a domain — the servers that hold the real answers. When you move DNS to Cloudflare, Route 53, or another provider, you're changing the NS records at your registrar. Everything else (A, MX, TXT…) lives on whatever nameservers the NS records point to.

TTL and propagation — why changes aren't instant

Every record carries a TTL (time to live) in seconds — how long a resolver is allowed to cache it.

example.com.   300   IN   A   104.16.132.229
               ↑ TTL = cache this answer for 300s (5 min)

After you edit a record, resolvers that already cached the old value keep serving it until the TTL expires. That's why a change can look live for you but stale for someone else — they're holding a cached copy. Worldwide, full propagation can take up to 48 hours.

Pro tip: before a planned migration, lower the TTL (e.g. to 300s) a day ahead. Then the cutover clears in minutes instead of hours.

You can see whether a change has propagated by comparing resolvers: if Cloudflare 1.1.1.1 and Google 8.8.8.8 return different answers for the same record, the change is still rolling out (or the domain uses geo/split-horizon DNS). Our DNS tool runs that comparison for you and flags whether the two big public resolvers agree.

Reading records like a pro

  1. Site won't load on some networks? Check A and AAAA.
  2. Email bouncing? Check MX, then SPF/DKIM/DMARC in TXT.
  3. Custom domain not pointing right? Check the CNAME (and remember: not at the apex).
  4. Just moved providers? Confirm the NS records at your registrar.
  5. Change not showing up? It's TTL — compare resolvers and wait out the cache.

Want the full picture for your own domain? Run a DNS lookup — it shows A, AAAA, MX, TXT, NS, and CNAME records with their TTLs, lets you switch between Cloudflare and Google resolvers, and checks propagation. For how lookups travel the wire, read What Is DNS Resolution and DNS over HTTPS.