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

DNS is the internet's phone book: you know a domain name (example.com), and DNS tells you which server it points to, which server accepts its email, and what other information is published about it. Each piece of that information is a record, and each record has a type. An A record maps a name to an IPv4 address, AAAA to an IPv6 address, CNAME makes one name an alias of another, MX names the domain's mail server, and TXT holds free-form text used mostly for ownership verification and email security (SPF, DKIM, DMARC).

If that's all you needed, the table below is the complete summary. After it come the details that usually cause trouble: TTL and DNS "propagation", why a CNAME isn't allowed on the root domain, and how to use dig and nslookup to see what the world actually sees for your domain.

Short answer: A DNS record is a piece of information published for a domain name, and its type determines what it does. A maps a name to IPv4 and AAAA to IPv6, CNAME makes a name an alias of another name, MX names the mail server, TXT holds free text for ownership verification and SPF, DKIM and DMARC, NS lists the domain's name servers, and CAA restricts which certificate authorities may issue SSL certificates for it.

What does DNS actually do?#

When you open example.com in a browser, your operating system asks a resolver (usually your ISP's or local network's DNS server): "What is the address of example.com?" If the resolver already has the answer cached, it returns it. If not, it starts at the root servers, moves on to the .com servers, and finally gets the answer from the domain's authoritative name servers, the servers whose dashboard you entered your records into.

Two things follow from this:

• Edit records only in the dashboard of the provider your domain's name servers point to. If your NS records point to provider A and you create records in provider B's dashboard, nothing happens.
• Resolvers cache answers for a while. That duration is the TTL, covered below.

Types of DNS records#

The examples below use the reserved domain example.com and documentation-only addresses (203.0.113.x and 2001:db8::).

Each line reads, in order: name, TTL in seconds, class (almost always IN), record type and value. Web dashboards usually show only name, type, value and TTL, and fill in the rest. The trailing dot on names (example.com.) means "this name is fully qualified"; most dashboards add that for you too.

A and AAAA#

The simplest and most common records. If your server has IPv6, add an AAAA alongside the A record; if it doesn't, don't create one. A wrong AAAA record is worse than none, because users with IPv6 try it first and get nowhere.

What is a CNAME record?#

A CNAME says "this name is another name for X; go there for any answer." For example, you make www.example.com a CNAME to example.com, so that if the IP ever changes you only update one A record. External services also commonly ask you to CNAME a subdomain to a name in their domain, such as shop.example.com to stores.provider.example.

The key CNAME rule: a name that has a CNAME cannot have any other record. No MX, no TXT, no A. A CNAME means "read everything about this name from somewhere else", so any other record next to it is a contradiction.

MX records#

An MX record says which server should receive mail for @example.com. The number before the server name is the priority, and a lower number means higher priority:

example.com.  3600  IN  MX  10  mail1.example.com.
example.com.  3600  IN  MX  20  mail2.example.com.

Senders try mail1 first and fall back to mail2 if it's unreachable. Two common mistakes: an MX value must be a name, not an IP, and that name must not be a CNAME; it needs its own A or AAAA record.

NS and CAA#

NS records are usually created by your DNS provider, and you just enter the same names at your domain registrar. CAA is less well known but cheap and useful: if you only get certificates from Let's Encrypt, one CAA record stops other authorities from issuing certificates for your domain. If you have CAA and later start using another authority, remember to add it as well, or issuance will fail. Getting a certificate is covered in Free SSL with Let's Encrypt.

TTL and DNS "propagation"#

TTL is a number of seconds that tells resolvers how long to cache an answer. A TTL of 3600 means one hour. What people call "DNS propagation" isn't anything spreading; different resolvers hold on to the old answer until its TTL runs out, then ask again. That's why, after you change a record, some users see the result sooner and others later.

The right way to move a site to a new server:

1. A day or two beforehand, lower the TTL of the record you plan to change (to 300 seconds, say). Do this at least as far ahead as the old TTL.
2. On the day, change the record's value. Most users now reach the new server within minutes.
3. Keep the old server running for a few days; there's always a resolver that ignores TTL.
4. Once everything is stable, raise the TTL back to its usual value (for example 3600).

One exception: changing name servers (NS) happens at the registry level, and its TTL is usually long (often one or two days), so it takes more patience.

Why can't a CNAME go on the root domain?#

The bare domain, example.com with no prefix, is called the apex or zone root. This name always has at least two record types: SOA and NS. The rule above (a name with a CNAME can't have any other record) is broken right there, so the DNS standard doesn't allow a CNAME at the apex. And even if it did, the domain's MX and TXT records would stop working.

Solutions:

• A plain A record on the apex, with CNAMEs only on www and subdomains. The simplest and most standard approach.
• CNAME flattening or ALIAS/ANAME records: some DNS providers let you put something CNAME-like on the apex in their dashboard, but when answering, they resolve the target themselves and return an A record. This is a provider feature, not part of the standard, and it goes by a different name in each dashboard.

SPF, DKIM and DMARC: three TXT records for email#

If you send email from your domain, whether from your own server or through an email service, without these three records your messages have a high chance of landing in spam.

• SPF lists the servers allowed to send email on behalf of your domain. It sits on the domain itself, and each domain must have only one SPF record; if you use several services, include them all in one record.
• DKIM is a public key used to verify the digital signature on your messages. It sits on a name like selector._domainkey.example.com, and your email service gives you its value.
• DMARC publishes your policy: what receivers should do with a message that fails SPF and DKIM, and where to send reports. It sits on _dmarc.example.com.

example.com.                    IN TXT "v=spf1 mx include:_spf.mailprovider.example -all"
mail2026._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
_dmarc.example.com.             IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Start DMARC with p=none, read the reports for a few weeks, and once you're sure every legitimate sender passes SPF or DKIM, move to quarantine and then reject.

Checking DNS records with dig and nslookup#

Your DNS dashboard tells you what you entered; dig tells you what the world sees. On Ubuntu, dig is in the bind9-dnsutils package (sudo apt install bind9-dnsutils); nslookup is available on both Windows and Linux.

# Short answer: value only
dig example.com A +short
dig www.example.com CNAME +short
dig example.com MX +short
dig example.com TXT +short
dig _dmarc.example.com TXT +short

# Full answer, with the remaining TTL in the second column
dig example.com A

To see what the authoritative server answers, bypassing the resolver's cache, find the NS records first and then query one of them directly:

dig example.com NS +short
# Suppose the answer was ns1.example.net
dig @ns1.example.net example.com A +short

If the authoritative answer is correct but your own resolver's is stale, nothing is wrong; you just need to wait out the TTL. If the authoritative answer is wrong too, you edited the record in the wrong place or it wasn't saved.

To see the full query path from the root to the authoritative server:

dig example.com +trace

And the nslookup equivalents:

nslookup example.com
nslookup -type=mx example.com
nslookup -type=txt example.com

Common mistakes#

• Creating records in a dashboard your domain's NS records don't point to.
• Putting a CNAME next to other records, or on the apex.
• An MX that points to an IP or to a CNAME.
• Two separate SPF records for one domain, which effectively invalidates SPF.
• A stale AAAA record forgotten after moving servers.
• Lowering the TTL at the moment of the switch instead of a day ahead.

If you've just got a new server and want to point your domain at it, The first hour on a Linux server covers the next step.

Frequently asked questions#

What is the difference between an A record and a CNAME?#

An A record maps a name directly to an IPv4 address, while a CNAME says the name is an alias of another name and the answer should come from that name. A name with a CNAME can't have any other record, so the root domain usually gets an A record and CNAMEs are kept for www and subdomains.

How long do DNS changes take to propagate?#

It depends on the old record's TTL: resolvers keep the old answer until the TTL expires, so with a TTL of 3600 some users may see the old value for up to an hour. Name server (NS) changes happen at the registry and usually take one to two days.

Which DNS records stop my emails from going to spam?#

You need three TXT records: SPF on the domain itself, listing the servers allowed to send; DKIM on a name like selector._domainkey, holding the public key for message signatures; and DMARC on _dmarc, publishing the policy for messages that fail. Each domain must have only one SPF record.

How do I check my domain's DNS records?#

Use dig, for example dig example.com A +short or dig example.com MX +short, to get the answer the world sees. To bypass the resolver's cache, find the name servers with dig example.com NS +short and then query one of them directly.

Why isn't the DNS record I created working?#

The most common reason is that you created it in a dashboard your domain's name servers don't point to. If the dashboard is right and the authoritative server returns the new value, you only need to wait for the old answer's TTL to expire.

Wrap-up#

DNS works with a small set of record types: A and AAAA for addresses, CNAME for aliases, MX for email, TXT for verification and email security, NS for name servers and CAA for restricting certificate issuance. Most trouble comes from three places: editing in the wrong dashboard, the CNAME-must-stand-alone rule, and ignoring TTL. Lower the TTL before any change, check the authoritative answer with dig afterwards, and if you send email, set up SPF, DKIM and DMARC correctly from day one.