🍱 Lunchbox Hands

dns

DNS Record Types Explained: A, AAAA, CNAME, MX, TXT and the Rest

What every DNS record type actually does, why you cannot put a CNAME at your root domain, how TTL really works, and how to read SPF, DKIM, DMARC, and CAA records.

DNS is the one piece of infrastructure most developers touch a few times a year, always under pressure, usually in a registrar’s cramped web form. You paste a value someone gave you, click save, and hope. This is the reference for the other case — when you need to know what each record type is for, why the registrar rejected your entry, and what “propagation” is actually doing while you wait.

The record types you’ll actually meet

TypePoints toCommon use
AAn IPv4 addressexample.com → 93.184.216.34
AAAAAn IPv6 addressThe same host over IPv6
CNAMEAnother namewww → example.com, app → myapp.vercel.app
MXA mail server hostname (+ priority)Routing email for the domain
TXTArbitrary textSPF, DKIM, DMARC, domain verification
NSAuthoritative nameserversDelegating the zone to your DNS host
SOAZone metadataSerial number, refresh timers, admin contact
CAACertificate authorities allowed to issueLocking down who can mint your TLS certs
SRVHost + port for a serviceSIP, XMPP, Minecraft, some enterprise apps
PTRA name, from an IPReverse DNS — mail server reputation

You can query every one of these against live nameservers with the free DNS Lookup tool — pick a type, enter a domain, and read the raw answers.

A and AAAA: the ones that point at machines

An A record maps a name to an IPv4 address. An AAAA record (four A’s, because IPv6 addresses are four times the bits — 128 vs 32) does the same for IPv6. Publish both when you can; clients that support IPv6 will generally prefer it, and anyone on IPv4 falls back automatically.

You can have multiple A records for one name. Resolvers hand them out in rotation — poor-man’s round-robin load balancing. It’s not health-aware: if one IP dies, a share of your users keeps getting sent to it until you remove the record.

If you’re not sure what address a name resolves to from your network, What Is My IP shows what the world sees from your side of the connection.

CNAME: the alias, and its one big rule

A CNAME says “this name is really that other name — go look that up instead.” It’s how you point app.example.com at something.herokudns.com without caring what IP that host uses today. The provider changes IPs; your record never moves.

The rule that trips everyone: a name with a CNAME cannot have any other records. That’s not a registrar being picky, it’s RFC 1034. And since your root domain (example.com, called the apex or zone apex) must have NS and SOA records, it can never have a CNAME.

So this is illegal:

example.com.  CNAME  my-app.netlify.app.   ← rejected: apex already has NS + SOA

Which is a real problem, because plenty of hosts only give you a hostname. The workarounds:

  • ALIAS / ANAME / CNAME flattening — a vendor-specific record type (Cloudflare calls it CNAME flattening, Route 53 calls it an Alias record, DNSimple calls it ALIAS). The nameserver resolves the target itself and returns the resulting A records, so what goes on the wire is a legal apex A record. Use this when your DNS host offers it.
  • Redirect the apex. Serve a plain 301 from example.com to www.example.com, put the CNAME on www, and be done. See 301 vs 302 redirects for getting that hop right.
  • Hardcode an A record. Works, but you now own the problem when the provider renumbers.

One more CNAME gotcha: a CNAME on a subdomain silently breaks mail for that subdomain, since the MX lookup follows the alias instead. Rare, but it produces a genuinely baffling outage.

MX: mail routing, and the priority number nobody explains

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

The number is priority, and lower wins. Sending servers try 10 first, fall back to 20 if it’s unreachable. Equal numbers means load-balance between them.

Two rules that cause most MX bugs:

  1. MX must point to a hostname, never an IP address. MX 10 203.0.113.5 is invalid, even though some registrars will happily accept the text.
  2. The target hostname needs its own A/AAAA record and must not be a CNAME. Pointing MX at a CNAME is forbidden by spec and rejected by many receiving servers.

Two MX states most people never meet: a domain with no MX at all still receives mail (senders fall back to its A record), and a domain can publish a Null MX (0 .) that explicitly refuses all mail. Both matter the moment you try to decide whether an email address can actually receive anything — a valid email address is not a deliverable one walks the whole lookup chain.

TXT: the junk drawer that runs email security

TXT records hold arbitrary strings, which is why every service on earth uses them for domain verification (“add this TXT record to prove you own the domain”). More importantly, the entire modern email-authentication stack lives here.

SPF — which servers may send mail as your domain:

v=spf1 include:_spf.google.com include:sendgrid.net -all

-all means “reject anything else” (hard fail); ~all is soft fail. You get exactly one SPF record per domain — two SPF records is a permanent error that breaks authentication for everything. And there’s a hard limit of 10 DNS lookups when evaluating it; each include: costs one, and chains of includes blow the budget silently.

DKIM — the public key used to verify message signatures, published at a selector subdomain:

selector1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

DMARC — what to do when SPF and DKIM fail, published at _dmarc:

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]"

Start at p=none with a rua= address to collect reports, read them for a few weeks, then tighten to quarantine and finally reject. Going straight to p=reject on a domain with unknown senders is how you discover your billing system was sending mail from a service nobody documented.

TXT strings are capped at 255 characters each; longer values (most DKIM keys) get split into multiple quoted chunks that resolvers concatenate. If your DKIM check fails, look for a botched split first.

NS and SOA: who is in charge here

NS records delegate a zone. They exist in two places — at your registrar (which tells the world which nameservers to ask) and in the zone itself. When those disagree, you get the special kind of outage where the site works for you and nobody else, because you’re hitting a cached answer from the old set.

SOA carries zone metadata: the primary nameserver, an admin email (with the @ written as a dot), a serial number, and timers. The serial matters when you run secondaries — if it doesn’t increment, they never pull your changes. Most managed DNS handles this for you.

None of this tells you who registered the domain or when it expires — that’s registry data, not zone data, and it lives in a completely different lookup these days. See WHOIS Is Effectively Dead. Here Is What RDAP Actually Returns for how domain ownership and lifecycle status are actually queried in 2026.

CAA: who’s allowed to issue your certificates

A CAA record restricts which certificate authorities can issue certs for your domain. CAs are required to check it before issuing.

example.com.  CAA  0 issue "letsencrypt.org"
example.com.  CAA  0 issuewild ";"
example.com.  CAA  0 iodef "mailto:[email protected]"

That says: only Let’s Encrypt may issue, nobody may issue wildcards, and email us about violation reports. It’s five minutes of work that closes off a whole class of mis-issuance attack. When you’re inspecting the certificate that actually got issued, the X.509 Decoder will show you its issuer, SANs, and validity window — and how to read an X.509 certificate walks through the fields.

SRV: the one with a port number

SRV is the only common record type that carries a port, which is why service-discovery protocols use it. The name encodes the service and protocol:

_sip._tcp.example.com.  SRV  10 60 5060 sipserver.example.com.
                             ↑  ↑   ↑
                        priority │  port
                              weight

Priority works like MX (lower first). Weight distributes load among equal priorities. Most web developers never write one; if you run XMPP, SIP, Matrix, or some Microsoft 365 features, you will.

PTR: reverse DNS, and why mail admins care

PTR maps an IP back to a name — the inverse of an A record, living in the special in-addr.arpa zone. You usually can’t set it in your own DNS; it belongs to whoever owns the IP block, which means your hosting provider or cloud vendor.

It matters for exactly one thing most people hit: outbound mail. Receiving servers check that your sending IP’s PTR resolves to a name that forward-resolves back to the same IP. No matching PTR is a strong spam signal, and it’s the reason mail from a fresh VPS lands in junk.

TTL and the “propagation” myth

Every record carries a TTL — how many seconds a resolver may cache the answer. There is no DNS-wide push, no propagation wave. Nothing “spreads.” Each resolver just holds its cached copy until the TTL runs out, then asks again. (The full mechanism — including where the 24–48 hour folklore actually comes from — is in DNS propagation is not real.)

Which gives you a practical procedure for any planned change:

  1. Lower the TTL first — to 300 seconds, at least one full old-TTL period before the migration.
  2. Wait out the old TTL so every cache has picked up the short one.
  3. Make the change. It now takes effect within ~5 minutes everywhere.
  4. Raise the TTL back to something sane (3600–86400) once you’re confident.

Skipping step 1 is why a change with a 24-hour TTL takes a day to fully land. And note that some ISP resolvers ignore short TTLs and enforce their own floor, so a slow straggler doesn’t necessarily mean you did anything wrong.

Also worth knowing: negative answers are cached too. The NXDOMAIN TTL comes from your SOA record’s minimum field, so if you look up a name before creating it, that “doesn’t exist” answer sticks around. Never test a hostname until you’ve actually created the record.

Debugging a DNS problem, in order

  1. Query the record type directly, don’t rely on whether the site loads — DNS Lookup supports A, AAAA, MX, TXT, NS, CNAME, SOA, CAA, SRV, and PTR.
  2. Check the NS records match what your registrar has. Mismatched delegation explains a startling share of “DNS is broken” tickets.
  3. Look for a trailing-dot error. example.com without the dot in a zone file becomes example.com.example.com. Registrars vary in whether they add it for you.
  4. Confirm TTLs before you conclude a change didn’t work. You may just be early.
  5. For mail, verify SPF is a single record under 10 lookups, DKIM’s key isn’t truncated, and DMARC is at _dmarc.

Most DNS incidents come down to one of five things: a CNAME where a CNAME can’t go, two SPF records, an MX pointing at an IP, delegation that doesn’t match, or someone reading a cache and calling it broken. Query the records directly and four of the five become obvious immediately.