Skip to main content

DNS Records Explained: A, AAAA, CNAME, MX, TXT and the Rest of the Zone

A practical guide to DNS record types — what A, AAAA, CNAME, MX, TXT, NS, SOA and SRV do, how to read a zone, plus TTL, propagation and common setups.

Published By Li Lei
#dns #networking #devops #sysadmin

DNS Records Explained: A, AAAA, CNAME, MX, TXT and the Rest of the Zone

Every domain you have ever visited resolved through a small pile of text records sitting on a name server. Most of the time you never see them. Then one day a vendor tells you to "just add a CNAME," your email starts landing in spam, or a site refuses to load on the apex domain, and suddenly you need to know exactly what each record type does. This guide walks through the record types you actually meet in production, shows you how to read a zone, and covers the two things that trip people up most: TTL and propagation.

The Core Records: A, AAAA, CNAME

These three carry most of the web. Each does one specific job.

A maps a name to an IPv4 address. app.example.com → 203.0.113.10. That is the whole job — point a hostname at a v4 IP.

AAAA maps a name to an IPv6 address, like 2001:db8::1. It is the IPv6 sibling of A, and on a modern setup you usually want both an A and an AAAA so clients on either stack can reach you.

CNAME is different. It does not point at an IP at all — it aliases one name to another name. www.example.com CNAME → app.example.com, and the resolver then follows that chain until it hits the A/AAAA records at the end. The rule of thumb: A and AAAA are leaf records that end the lookup, while a CNAME is a pointer that hands the resolver another name to chase.

The one place CNAME cannot live is the zone apex — the bare example.com. The spec says a name with a CNAME may have no other records, but the apex is required to carry SOA and NS records, so the two cannot coexist. If a SaaS only gives you a hostname for your apex, you reach for a provider ALIAS/ANAME or CNAME flattening, which resolve the target server-side and answer with A/AAAA at the root.

Mail and Text: MX and TXT

MX routes mail. An MX record names a mail server and a priority number: example.com MX 10 mail1.example.com and MX 20 mail2.example.com. Lower numbers win, so senders try priority 10 first and fall back to 20. One catch worth memorizing — an MX target must be a hostname with its own A/AAAA records, never a CNAME. Pointing MX at a CNAME is forbidden and quietly breaks delivery on strict receivers.

TXT holds arbitrary text strings, and that flexibility is why it carries so much weight. TXT records hold your SPF policy (v=spf1 include:_spf.google.com ~all), DKIM public keys, DMARC policy, and the verification strings that Google, Microsoft, and dozens of SaaS tools ask you to paste in to prove you own the domain. A hard rule lives here too: publish exactly one SPF record. Two v=spf1 TXT records make receivers return PermError, which downstream often reads as "no SPF at all" — merge every sender into a single line with multiple include= mechanisms instead.

The Plumbing: NS, SOA, SRV

NS records list the authoritative name servers for a zone — the servers that hold the real answers. They are how delegation works: the .com servers point at your NS records, and your NS records point queries at the right place.

SOA (Start of Authority) is the one administrative record every zone must have at the apex. It names the primary name server and the zone's admin contact, and carries the serial number and timers that secondary servers use to decide when to refresh their copy.

SRV records advertise both the host and the port of a named service so a client can discover them without the user typing a port. The service label must start with an underscore — _xmpp-client._tcp, _sip._tls, _ldap._tcp for Active Directory, _minecraft._tcp for a game server. Two traps: the underscore is mandatory, and the SRV target must be a real A/AAAA hostname, never a raw IP and never a CNAME. Browsers ignore SRV entirely, so it does nothing for a plain website.

Reading a Small Zone

Here is a minimal but realistic zone file for example.com. Read it top to bottom:

$TTL 3600
example.com.        IN  SOA   ns1.example.com. admin.example.com. (
                              2026061301 ; serial
                              7200 3600 1209600 3600 )
example.com.        IN  NS    ns1.example.com.
example.com.        IN  NS    ns2.example.com.
example.com.        IN  A     203.0.113.10
www.example.com.    IN  CNAME example.com.
example.com.        IN  MX    10 mail.example.com.
mail.example.com.   IN  A     203.0.113.20
example.com.        IN  TXT   "v=spf1 include:_spf.google.com ~all"

Walking it: the SOA and two NS records establish that this is an authoritative zone with the apex carrying its required records. The apex A sends example.com to 203.0.113.10 — note it is an A, not a CNAME, because the apex cannot alias. www is a CNAME pointing back at the apex, so it inherits the same IP without duplicating it. The MX record routes mail to mail.example.com at priority 10, and crucially mail.example.com has its own A record (203.0.113.20) rather than being a CNAME, satisfying the MX rule. The TXT record publishes a single SPF policy authorizing Google Workspace to send. That is a complete, working domain in eight lines.

TTL and Propagation

Every record carries a TTL (Time To Live) in seconds — $TTL 3600 above means one hour. TTL controls how long a resolver is allowed to cache the answer before asking again. A high TTL like 86400 (a day) reduces query load and is fine for records that rarely move; a low TTL like 300 (five minutes) lets you change a record and have the world pick it up quickly.

This is the whole secret to clean migrations. Before you move a server, drop the TTL on the affected records to 300 a day ahead of time. Then when you flip the IP, resolvers holding the old answer expire it within five minutes instead of a full day. "Propagation" is just the sum of every cached copy aging out — there is no magic switch, only TTLs expiring. Once the move is verified, raise the TTL back up.

I learned this the slow way. Years ago I cut over a mail server during a maintenance window with the MX record still sitting on a 24-hour TTL, congratulated myself on a clean switch, then spent the next day fielding "where's my email" messages while half the internet's resolvers cheerfully delivered to a box that no longer existed. Now the first thing I touch before any cutover is the TTL, a full day early — it costs nothing and it has saved every migration since.

Common Setups at a Glance

Three patterns cover most real-world DNS work:

  • A website: an A (and ideally AAAA) at the apex, a CNAME on www pointing back to it, or a provider ALIAS/flattening if your host only gives you a hostname for the root.
  • Email: an MX (or two, with priorities) pointing at real A/AAAA mail hosts, plus a single TXT SPF record, a DKIM key in TXT, and a DMARC TXT policy you tighten gradually from p=none to p=reject.
  • Domain verification: a TXT record holding the exact token the vendor gives you, left in place so they can re-check ownership later.

If you want to sanity-check what each record type expects before you paste it into a control panel, the DNS Record Explainer lists all 18 common types with syntax, copy-paste examples, and the gotchas that have burned production teams. And once your services are reachable, the HTTP Status Explorer is handy for decoding what the server says back. DNS is small, declarative, and unforgiving of one-character mistakes — read the record type carefully and most of the surprises disappear.

Made by Toolora · Updated 2026-06-13