DNS Records Explained: A, AAAA, CNAME, MX, TXT and How to Read Them

DNS is the phone book of the internet, and like a phone book it has different kinds of entries for different purposes. When a site does not load, email bounces, or a domain-verification step fails, the answer is almost always in the DNS records — if you know which record type to look at. Here is the short list you actually encounter, and how to check them.

The records you meet most

• A — maps a hostname to an IPv4 address. example.com → 93.184.216.34. This is the workhorse; when someone says "point the domain at the server," they usually mean an A record.
• AAAA — the same idea for IPv6. example.com → 2606:2800:.... Increasingly required as IPv6 adoption grows.
• CNAME — an alias from one name to another name (not an IP). www.example.com → example.com. The resolver then looks up the target's A/AAAA records. Great for pointing subdomains at a platform's hostname.
• MX — mail exchange. Tells the world which servers accept email for the domain, with a priority number (lower = tried first). If email bounces, MX records are the first place to look.
• TXT — arbitrary text, used for verification and email authentication: domain-ownership proofs, plus SPF, DKIM, and DMARC records that fight spoofing.
• NS — the nameservers authoritative for the domain. Getting these wrong means none of your other records are consulted.

To see what a hostname resolves to right now, the Hostname to IP tool performs a live lookup through a public resolver, which reflects what most of the internet currently sees — useful for confirming a change has taken effect.

The CNAME-at-the-apex trap

The most common DNS mistake: trying to put a CNAME on the apex (the bare example.com, sometimes written @). The DNS spec does not allow a CNAME to coexist with the other records an apex must have (like SOA and NS), so it either fails or behaves unpredictably. Subdomains like www can be CNAMEs freely; the apex generally needs an A/AAAA record — or a provider-specific feature (ALIAS, ANAME, or CNAME flattening) that resolves the target to an IP behind the scenes.

Propagation is really caching

When you change a record and it "hasn't propagated yet," what is actually happening is caching. Every record has a TTL (time to live); resolvers cache the old value until the TTL expires. If you plan a change, lower the TTL a day ahead so the switchover is fast. To check whether a change has landed on a widely-used resolver, look it up with Hostname to IP; if it still returns the old address, a resolver is likely still holding the cached value until its TTL runs out.

From a record to an investigation

DNS records are also the starting point for triaging something suspicious. If a hostname resolves to an IP you do not recognize, follow the trail:

• Attribute the IP — its geolocation and owning network — with IP Lookup.
• Check registration and ownership with WHOIS Lookup.
• Confirm the IP falls in an expected range with the CIDR / IP Converter.

A domain that suddenly resolves to a hosting provider you do not use can signal a misconfiguration or a hijacked zone; the DNS & IP Troubleshooting guide walks through that workflow.

The takeaway

Most DNS problems are one of a few things: the wrong record type (A vs CNAME), a CNAME where the apex needs an A, or a TTL-cached old value that just needs time. Know what each record does, check the live answer with Hostname to IP, and DNS stops being a black box.