DNS Records Explained While You Actually Change Them: A, AAAA, CNAME, MX, TXT

DNS documentation always seems to start with the history of the domain name system, when all you wanted was to point a domain at a server without breaking your email. I have made every DNS mistake there is — the CNAME on the root domain, the MX record pointing at a CNAME, the "why is my site down" that turned out to be a TTL I set to 24 hours a week earlier. So here is the explanation I wish I had: each record type explained by what you actually use it for, with the mistakes attached.

Think of DNS as the contact card for your domain. Different record types are just different fields on that card.

A record: "this name lives at this IP"

example.com  A  203.0.113.10

This is the fundamental one: it maps a name to an IPv4 address. Your website works because example.com has an A record pointing at your server. Subdomains are just more A records: cloud.example.com A 203.0.113.10 and api.example.com A 203.0.113.10 can point at the same IP (your reverse proxy sorts out the rest — see how that works).

AAAA record is exactly the same thing for IPv6. Add it if your server has a real IPv6 address; do not add it "for completeness" if nothing listens there, or some visitors will try IPv6 and time out.

CNAME: "this name is an alias for that name"

www.example.com  CNAME  example.com

A CNAME says "go look up this other name instead". Useful for pointing www at your root, or blog.example.com at a hosted service that gives you a hostname.

The two rules that bite people:

1. No CNAME at the root domain (example.com itself) on standard DNS. The root must have other records (NS, SOA), and CNAME cannot coexist with them. This is why some providers invented special ALIAS/ANAME records for exactly this job.
2. A CNAME is the only record for that name. If www is a CNAME, it cannot also have its own TXT or MX records.

MX: "mail for this domain goes here"

example.com  MX  10 mail.example.com

MX records control where email gets delivered. The number is a priority — lower wins, higher numbers are backups. If you use Google Workspace, Proton, or any hosted mail, you paste their MX values in and email works. If you later move providers and forget the old MX records, mail goes to the old place and silently vanishes. Ask me how I know.

Note that MX must point to a hostname (which then has an A record), not directly to an IP, and not to a CNAME.

TXT: "here is some text other systems should check"

TXT records are free-form, and in practice they are the internet's proof-of-ownership and mail-reputation system:

• Verification: "prove you own this domain" — Google Search Console, AdSense, Microsoft, everyone asks you to add a TXT record with their token
• SPF: which servers may send mail as your domain — v=spf1 include:_spf.google.com ~all
• DKIM: a public key for signing your outgoing mail
• DMARC: what receivers should do when SPF/DKIM fail — v=DMARC1; p=quarantine; ...

If you set up email and people say your messages land in spam, the answer is almost always SPF/DKIM/DMARC in TXT records, not anything on your mail server.

NS and SOA: mostly not your problem (until you move DNS)

NS records say which nameservers are authoritative for your domain — you set these at the registrar, not in the DNS zone, when you change DNS providers. SOA is zone bookkeeping the provider manages. You can happily run a site for years without touching either, but knowing that NS lives at the registrar explains the classic confusion of "I changed the records in Cloudflare and nothing happened" — because the registrar was still pointing at the old provider's nameservers.

TTL: the knob that decides how long your mistakes last

TTL (time to live) is how long resolvers cache your record, in seconds. A TTL of 3600 means changes can take up to an hour to show everywhere; 86400 means up to a day. This is also why "it works for me but not for you" happens — different resolvers have different cache ages. We go deeper on that in DNS Propagation Explained.

Practical habit: before a planned migration, lower the TTL to 300 a day in advance. Make the change, confirm it works, then raise it back. Your future outages get much shorter.

My pre-flight checklist before touching any record

1. dig example.com NS — confirm which provider is actually authoritative
2. Screenshot the current zone (undo is easier with evidence)
3. Lower TTL if this is a big change
4. Change one thing, then verify with dig @1.1.1.1 and dig @8.8.8.8 from your laptop
5. Check the thing you did not touch — new A records do not break mail, but new MX records definitely can

DNS feels fragile because the feedback is slow and the errors are silent. Once you know which record does what, it becomes one of the most predictable systems you work with.