Every domain has a set of DNS records sitting behind it, and most people only ever interact with one of them -- usually by accident, when a website or email stops working after a hosting change. DNS isn't just "the thing that turns a domain into an IP address." It's closer to a small database of rules that controls where traffic goes, where mail gets delivered, and who's allowed to say a domain belongs to them.
The record types that actually matter
A handful of record types cover almost everything you'll ever deal with:
- A record -- points a domain (or subdomain) to an IPv4 address. This is the one most people think of as "DNS."
- AAAA record -- the same thing, but for IPv6 addresses.
- CNAME record -- points a domain to another domain name instead of an IP directly. Common for subdomains that ride on a third-party service (like a CDN or a hosted app).
- MX record -- tells the internet which mail servers handle email for that domain, and in what priority order.
- NS record -- lists the nameservers that are authoritative for the domain, i.e. which servers get asked first when someone looks up any record for it.
- TXT record -- holds arbitrary text. It's the catch-all, and it does more heavy lifting than its name suggests.
Why TXT records are doing more work than you'd guess
TXT records started as a place for free-form notes, but they've become the backbone of email trust and domain verification. SPF records (which list which servers are allowed to send mail on a domain's behalf) live in TXT. DKIM keys (which let a receiving mail server verify a message wasn't tampered with) live in TXT. And when Google, Microsoft, or pretty much any SaaS platform asks you to "verify domain ownership," they're asking you to add a specific TXT record as proof you control the DNS.
If you've ever wondered why fixing an email deliverability problem often means editing DNS instead of an email client setting, this is why -- the trust signals live at the DNS layer, not the mail server.
Why changes don't show up instantly
Every DNS record has a TTL (time to live), measured in seconds, that tells other servers how long they're allowed to cache the answer before asking again. A record with a one-hour TTL means anyone who already looked up that domain in the last hour is still working from the old answer. This is why DNS changes are described as "propagating" -- it's not that the change is slow to apply, it's that cached copies of the old answer are still valid until their TTL expires. If you're planning a DNS change ahead of a migration, lowering the TTL a day or two in advance is the standard trick to make the actual cutover faster.
Checking a domain's current setup
Before troubleshooting mail delivery, chasing a "site not resolving" issue, or verifying a change actually went live, it helps to see the current records directly rather than guessing from browser behavior. The DNS Lookup tool pulls A, AAAA, MX, TXT, NS, and CNAME records for any domain, so you can confirm what's actually published before spending time debugging the wrong layer.