Developer Tools·4 min read

DNS Records Explained: A, CNAME, MX, and TXT

You changed your DNS settings an hour ago and the site still points at the old server. Is something broken, or just slow? You can't answer that without knowing what each record actually does. This is dns records explained from a working developer's angle: which record types matter day to day, how an A record differs from a CNAME in a real domain setup, and why your email deliverability lives inside plain TXT strings. By the end, zone file edits should feel much less like guesswork.

Open the tool All insights

The change that hasn't propagated is usually just cached

You point a domain at a new host, and an hour later half your team sees the new site while you still see the old one. Nothing is propagating anywhere. Every DNS record carries a TTL, a time to live, and resolvers across the internet keep serving their cached answer until that timer runs out. If the old record had a TTL of 86400 seconds, some users can see stale data for a full day.

The professional move is boring: drop the TTL to 300 a day before a migration, make the change, then raise it back once traffic settles on the new address.

You can also check what the world currently sees instead of waiting it out. Run dig example.com from a terminal, or nslookup on Windows, and compare the answer with the value you entered. If public resolvers already return the new address, your record is correct and the stragglers are just caches counting down to zero.

DNS records explained, one job per type

Each record answers exactly one question.

A maps a hostname to an IPv4 address, and AAAA does the same for IPv6. CNAME says this name is an alias, go ask that other name. MX lists the servers that accept the domain's mail, in priority order. TXT holds arbitrary strings that other systems read for policy and verification. NS names the servers that hold authority over the zone itself. The reference also covers the types you meet less often, like PTR for reverse lookups, SRV for service discovery, and SOA for zone metadata, each with a realistic sample value.

The a record vs cname distinction comes with a structural rule worth memorizing: a CNAME can't coexist with any other record at the same name, which is why it's forbidden at the domain apex, where SOA and NS records must live.

A record vs CNAME in one real setup

The two-line pattern behind most production domains.

Here's the standard arrangement. The apex gets an address record: example.com A 76.76.21.21. The subdomain gets an alias: www CNAME example.com. Now www resolves in two steps, first to example.com, then to the IP, and when your host's address changes you edit exactly one record.

Pointing www at the IP directly with a second A record works too, right up until the migration where someone updates one record and forgets the other. For the awkward case where you want alias behavior at the apex itself, providers offer vendor-specific ALIAS records, and the table lists those alongside the official types.

The TXT records deciding whether your email lands

Deliverability trouble sends everyone to the same corner of DNS eventually. If you've searched spf dkim in txt records after a batch of newsletters hit spam, here's the decoded version. SPF is a TXT record at the domain root, something like v=spf1 include:_spf.example.com ~all, listing which servers may send mail on your behalf. DKIM is a public key published in a TXT record at selector._domainkey, letting receivers verify a message wasn't altered in transit. DMARC, a TXT record at _dmarc, tells receivers what to do when those checks fail.

One historical trap: the dedicated SPF record type is deprecated. Modern zones publish the v=spf1 string in an ordinary TXT record, and the reference flags the dead type so you don't reach for it.

Zone edits that take sites and mail down

The classic self-inflicted outages, collected from years of postmortems:

Adding a CNAME at the apex. Some providers reject it silently, others accept it and break your MX and TXT records in the process.
Migrating while the TTL is still high, then spending hours wondering why visitors keep landing on the old server.
Pointing MX at a CNAME. The standard requires mail exchanger targets to be hostnames with address records.
Publishing two v=spf1 strings on one domain. Receivers treat multiple SPF policies as a permanent error and may reject your mail outright.
Deleting the old A record before confirming the new one resolves from a network outside your own.

Reading this reference like an operator

Search by job rather than by name: typing mail into the box surfaces MX, and typing verification finds TXT, which helps when you know the goal but not the terminology. Compare your value against the Example column before saving, since a large share of zone file errors are format slips like a missing priority number on an MX entry. And copy record type names straight into Terraform files or support tickets so they arrive exact.

After DNS resolves, different tools take over

This reference stops at the moment a name becomes an address. If the domain resolves but the site answers strangely, the HTTP Status Codes table decodes whatever came back, from redirect chains to 503 maintenance pages. And when you want to poke the newly resolved endpoint from a script instead of a terminal, cURL to Code converts your test command into fetch, axios, or Python without retyping a single header.