You switch your domain's email from Gmail to Microsoft 365. You log into your registrar, update the MX records, save. Microsoft's setup wizard says "DNS not yet propagated." You wait. Half an hour later, half your test emails arrive at the old Gmail account and half at the new Microsoft 365 one. Eight hours after that, everything settles. What actually happened?
DNS is the phone book of the internet, except it's a phone book that contains other phone books, the phone books cache each other's answers for a while, and you rarely talk to the original. This is the practical tour of what each record type does, how caching plays out, and why "DNS propagation" takes the time it does.
A and AAAA — the address records
The two record types you'll see most often. A records map a hostname to an IPv4 address — example.com → 93.184.216.34. AAAA (read "quad-A") records map a hostname to an IPv6 address. A domain can — and these days usually does — carry both. The client picks based on what it can route: a dual-stack laptop will prefer AAAA, an IPv4-only mobile connection will use A.
A single hostname can have multiple A records. This is the simplest form of load balancing — round-robin DNS. google.com returns a different IP every few seconds, and your browser picks one. It's crude, but it works, and it pre-dates real load balancers. For anything beyond "spread traffic across two boxes," most operators use a CDN or a real load balancer that does health checking; round-robin DNS has no way to notice that one of the IPs is down and stop handing it out.
MX — mail routing
MX records list the mail servers that accept mail for the domain. Each MX has a numeric priority — lower number means more preferred. Mail senders try the lowest-priority MX first, fall back to higher-priority ones if it's unreachable. Without an MX record, the domain can't receive mail. (The legacy fallback to an A record on the bare domain was deprecated years ago and no longer reliable.)
The Gmail-to-Microsoft-365 example at the top of this guide is an MX swap. Before: 10 aspmx.l.google.com. After: 0 yourdomain-com.mail.protection.outlook.com. The half-and-half delivery window happens because some resolvers have already picked up the new MX while others still hold the cached old one — and sending servers follow whichever MX their resolver gives them.
TXT — verifications, SPF, DKIM, DMARC
TXT records carry arbitrary text. In theory they can contain anything; in practice they carry a few specific kinds of data.
Verification records. Most providers (Google, Microsoft, AWS, Stripe, dozens more) ask you to add a TXT record with a token they generated, so they can confirm you control the domain before they let you claim it. These look like google-site-verification=abc123….
SPF. A TXT record starting v=spf1 that lists which servers are allowed to send mail as your domain. Recipients use SPF to drop or flag spoofed mail.
DKIM. A TXT record at a specific subdomain (selector._domainkey.example.com) holding a public key. Your mail server signs outgoing messages with the private half; recipients verify the signature against the published public key.
DMARC. A TXT record at _dmarc.example.com telling recipients what to do when a message fails SPF or DKIM — quarantine, reject, or just report. DMARC is the policy that ties SPF and DKIM together.
CNAME, NS, SOA, CAA — the supporting cast
CNAME aliases one hostname to another. www.example.com CNAME example.com means "whatever example.com resolves to is the answer for www.example.com too." CNAMEs can't sit at the apex of a domain — you can't have example.com CNAME someotherdomain.com. Most DNS providers offer a non-standard "ALIAS" or "ANAME" record that achieves the same thing at the apex by doing the CNAME-flattening on the server side.
NS records list the authoritative nameservers for the zone. When you change your DNS provider, this is the record that moves — you're telling the parent zone "ask these nameservers about this domain now."
SOA carries zone metadata: the primary nameserver, an admin email, a serial number incremented on every change, and the refresh / retry / expire / minimum TTL values that secondary nameservers use to decide when to re-pull the zone.
CAA records control which Certificate Authorities are allowed to issue TLS certificates for the domain. If you add a CAA record naming only Let's Encrypt, no other CA will issue a cert for the domain — a defence against rogue or compromised CAs.
How propagation actually works
The cliché "DNS changes take 24 to 48 hours" is half right. The actual answer is: changes propagate as fast as the slowest cache in the chain expires. Every DNS record has a TTL — the number of seconds a resolver should hold the cached answer before re-querying. A TTL of 300 means the answer stays cached for 5 minutes. A TTL of 86400 means a full day.
If you know you're about to make a DNS change, drop the TTL on the affected record to something small (300 or 600 seconds) at least one TTL period before the change. Then when you make the actual change, caches expire within minutes rather than hours. After the change has stabilised, you can put the TTL back up.
One gotcha: NXDOMAIN responses are cached too. If a name didn't exist and you've just created it, resolvers that previously asked and got "no such name" will hold that negative answer until its minimum-TTL expires (set in the SOA record, typically 1 to 24 hours). This is the "why isn't my new subdomain working yet?" trap.
The other thing worth knowing: "global propagation" isn't a coordinated event. There's no central authority that pushes the new record out to every resolver in the world. What actually happens is each resolver independently fetches the new answer when its old cache expires, and different resolvers expire at different times. Sites that show a map of "DNS propagation across global resolvers" are just querying a handful of public resolvers and showing which ones have the new answer yet — handy for monitoring, but the underlying picture is a thousand independent caches each ticking down on their own.
When to use the DNS lookup tool here
The DNS lookup tool queries Cloudflare's DoH endpoint directly, so the answer you see is whatever Cloudflare currently has — not whatever your local cache or your ISP's resolver happens to remember. When you've just changed a record, that's the closer-to-truth answer. It's also useful from a phone or a locked-down work machine where you don't have dig or nslookup available.
Related reading
If you're trying to confirm whether IPv6 is reaching you, the check if IPv6 is working guide is the practical companion — DNS will happily hand out an AAAA record your network can't route. To see the IP your own connection looks like to the outside world, the what is my IP page is the matching read.