DNS records explained: A, AAAA, CNAME, MX, TXT and the rest

DNS is the layer that turns a name into an address, and the layer people touch once a year and then have to relearn from scratch. Here is every record type you will actually encounter.

The record types

A and AAAA

Map a hostname to an IP address. A for IPv4, AAAA for IPv6. These are the terminal records - everything else eventually resolves to one of them.

example.com.      300  IN  A     93.184.215.14
example.com.      300  IN  AAAA  2606:2800:21f:cb07:6820:80da:af6b:8b2c

CNAME

An alias. It says "this name is really that name - go look that up instead". Used for pointing www at your apex, or a subdomain at a hosting provider's hostname.

Two rules people break constantly:

• A CNAME cannot coexist with other records at the same name. That is why you cannot put a CNAME at the apex: the apex must carry NS and SOA records, and a CNAME forbids siblings.
• CNAMEs cost an extra lookup. A chain of three CNAMEs is three round trips before the browser gets an address.

For the apex, use an A record, or your provider's ALIAS/ANAME record, which is a proprietary flattening that resolves the target and serves an A record in its place.

MX

Where email for this domain goes. Multiple records with priority numbers; lower is preferred.

example.com.  3600  IN  MX  10 inbound-a.mail-provider.com.
example.com.  3600  IN  MX  20 inbound-b.mail-provider.com.

An MX record must point at a hostname, never an IP address, and never at a CNAME.

TXT

Free-form text, which in practice means verification and email authentication:

• SPF - v=spf1 include:_spf.provider.com ~all. Lists who may send mail as you. Exactly one SPF record per domain; two is a permanent error that breaks delivery.
• DKIM - a public key at a selector subdomain, used to verify message signatures.
• DMARC - v=DMARC1; p=none; rua=mailto:... at _dmarc.yourdomain.com. Tells receivers what to do when SPF and DKIM fail.
• Domain verification - Google, Microsoft and most SaaS vendors verify ownership with a TXT record.

If your email lands in spam, these three are the first place to look, in that order.

NS

Which nameservers are authoritative for the zone. Set at your registrar, and the reason a DNS change at the wrong provider does nothing - you edited a zone nobody is asking.

SOA

Start of authority: the primary nameserver, the administrator's email, and the timers governing zone transfers. You will almost never edit it.

CAA

Which certificate authorities may issue certificates for your domain. Optional, cheap, and a real defence against mis-issuance.

TTL, and the only time it matters

TTL is how many seconds resolvers may cache a record. The value only matters around changes.

The pattern for any migration:

1. A day before: lower the TTL on the records you will change to 300.
2. Wait for the old TTL to expire. If it was 86400, that is a full day. This is the step people skip.
3. Make the change. Most resolvers pick it up within five minutes.
4. A day after: raise it back to 3600 or higher.

Skip step one and your change takes as long to propagate as the old TTL, with no way to speed it up. "DNS propagation" is not a mysterious global process - it is other people's caches expiring on the schedule you set.

Debugging in order

When something does not resolve:

1. Check the NS records at the registrar. If they point at a provider you are not editing, nothing else matters.
2. Query a public resolver directly rather than trusting your machine's cache.
3. Check for a conflicting CNAME. A CNAME plus any other record at the same name is invalid, and providers handle the conflict differently.
4. Check the TTL of the old record to know how long you are waiting.
5. Check for a trailing dot. example.com and example.com. in a record value mean different things in most zone editors - without the dot, the zone name gets appended, producing example.com.example.com.