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

Every time someone types your domain into a browser or sends you an email, a DNS query happens first. The Domain Name System translates human-friendly names like example.com into IP addresses and tells mail servers where to deliver. Most outages after a “simple” hosting move, and most email delivery problems, come down to one wrong or missing record. This guide covers the records you will actually touch and the timing rules that confuse most people.

How a DNS lookup works

1. Your device asks a recursive resolver (your ISP’s, or a public one such as Cloudflare’s 1.1.1.1 or Google’s 8.8.8.8).
2. If the resolver has no cached answer, it asks a root server, which points to the servers for the top-level domain (.com, .co.uk).
3. The TLD servers point to your domain’s authoritative nameservers (the NS records set at your registrar).
4. The authoritative server returns the record, and the resolver caches it for the record’s TTL.

That caching is why changes are not instant and why two people can see different results at the same moment.

The record types that matter

A and AAAA

The A record is what points your domain at a web server. If your host gives you an IPv6 address too, add an AAAA record; if they don’t support IPv6, don’t add one, because some visitors will try IPv6 first and fail.

CNAME

A CNAME says “this name is the same as that name”. It is ideal for www, for SaaS platforms (shop.example.com → shops.myshopify.com) and for verification records. Rules: a name with a CNAME cannot have any other record type, and the root domain cannot be a CNAME in standard DNS.

MX

MX records tell other mail servers where to deliver email for your domain. Lower numbers have higher priority. Microsoft 365 uses a single MX like example-com.mail.protection.outlook.com; Google Workspace now uses a single smtp.google.com record for new setups. An MX must point to a hostname, never directly to an IP address or to a CNAME.

TXT

TXT records hold text that other systems read: SPF, DKIM and DMARC for email authentication, plus verification strings for Google Search Console, Microsoft 365 and others. Our SPF, DKIM and DMARC guide covers the email side in detail.

NS

NS records decide which company’s servers are authoritative for your domain. If your registrar says the nameservers are Cloudflare’s, edits made in the registrar’s own DNS panel do nothing at all, which is a classic source of “I changed the record and nothing happened”.

CAA

A CAA record restricts which certificate authorities may issue certificates for your domain. It is optional, but if you add one, make sure it includes every CA you use (for example both letsencrypt.org and your CDN’s CA), or renewals will fail.

TTL and propagation

TTL (time to live) is the number of seconds a resolver may cache a record. Common values:

• 300 (5 minutes): good before and during a migration.
• 3600 (1 hour): a sensible default.
• 86400 (24 hours): fine for records that never change.

“Propagation” is not DNS pushing changes outward; it is old cached copies expiring. A practical migration plan:

1. A day or two before the move, lower the TTL of the records you will change to 300.
2. Wait at least the old TTL so caches pick up the short value.
3. Change the record. Most users see the new value within minutes.
4. Once everything is stable, raise the TTL again.

Some ISPs and routers ignore low TTLs and cache longer, so expect a handful of stragglers for a few hours.

Changing nameservers safely

Moving DNS hosting (for example from your registrar to Cloudflare) is riskier than editing a record, because you are swapping the whole zone.

1. Export or copy every record from the old provider: A, AAAA, CNAME, MX, all TXT records (SPF, DKIM selectors, DMARC, verifications), SRV and CAA.
2. Recreate them at the new provider and compare the two zones line by line.
3. Change the nameservers at the registrar. The parent zone’s NS records often have a TTL of 24–48 hours, so old and new servers will both receive queries for a while.
4. Keep the old zone intact for at least 48 hours.
5. Check from outside with the DNS lookup tool, which queries public resolvers rather than your local cache.

The most common casualty is email: a forgotten DKIM selector or MX record means messages bounce or land in spam after the switch.

Useful commands and checks

dig example.com A +short
dig example.com MX +short
dig _dmarc.example.com TXT +short
nslookup -type=ns example.com

To clear your local cache: Windows ipconfig /flushdns; macOS sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. A WHOIS lookup shows the registrar, expiry date and nameservers currently set for the domain. When an A record should point at your own office server, what is my IP shows the public address your connection uses.

Common mistakes

• Editing DNS at the registrar while the nameservers point somewhere else.
• Adding a CNAME for www and an A record for www. Pick one.
• Deleting MX or TXT records during a website move, which silently breaks email.
• Leaving a trailing-dot or duplicated-domain error, e.g. www.example.com.example.com, because the panel appends the domain automatically.
• Letting the domain expire: when it lapses, every record stops resolving at once.

Quick checklist

• Nameservers point to the provider where you actually edit records.
• A/AAAA for the root and www (or a CNAME for www) point to the current host.
• MX records match your email provider; SPF, DKIM and DMARC TXT records exist.
• CAA, if present, lists every certificate authority you use.
• TTLs are lowered before planned changes and raised afterwards.