DNS Records Explained: What Each Record Type Actually Does

The short answer: a DNS record is one line in your domain's instruction book, and each type answers a different question. The A record says which server hosts your website, the MX record says where your mail goes, the TXT record proves you own the domain to other services, and the NS record says which name servers are in charge of the whole list. When a site "goes down after a DNS change," the cause is almost always one wrong line in that list — or one old line that resolvers are still caching. This post explains every record type you will actually meet, shows you how to read a lookup result, and names the mistakes that take sites offline.

The record types, in one table

Every record has the same shape: a name, a type, a value, and a TTL (time to live) saying how long resolvers may cache it. The types below are the ones that cover nearly every real-world setup; the record definitions themselves go back to RFC 1035, the original DNS specification, and later standards added the rest. For a cross-check of the full type list, including provider-specific variants, Google Cloud's DNS records overview is a useful second reference.

Two details in that table trip people up. First, MX and NS values are hostnames, not IP addresses — they must end with a dot in zone-file syntax, and they must themselves resolve, which is why an MX record pointing at a CNAME is a classic misconfiguration. Second, a CNAME cannot coexist with any other record for the same name, which is why you cannot put a CNAME at the bare domain (the apex) where the SOA and NS records already live: providers solve that with their own alias or flattening records instead.

How a lookup actually flows

When you type a domain into a browser, your device asks a resolver, and the resolver walks the chain: it asks a root server who handles the top-level domain, asks that server who handles your domain, and finally asks your domain's authoritative name server for the record itself. Each answer carries a TTL, and every resolver along the way caches it for that long. That cache is why DNS changes feel slow: the change itself is instant at the authoritative server, but resolvers keep serving the old answer until its TTL expires. A TTL of 3600 seconds means up to an hour of stale answers; a TTL of 300 means five minutes. The practical habit follows directly: before any migration, lower the TTLs of the records you plan to change a day or two ahead, so the eventual switch propagates in minutes instead of hours.

Reading a real lookup result

Run a lookup for a domain and you get a set of sections like this (values below are illustrative, for a fictional example domain):

example.com.    3600    IN    A       192.0.2.91
example.com.    3600    IN    AAAA    2001:db8::1
example.com.    3600    IN    MX      10 mail.example.com.
example.com.    3600    IN    NS      ns1.example.com.
example.com.    3600    IN    TXT     "v=spf1 include:_spf.example.com ~all"

Read it left to right: the name, the TTL in seconds, the class (IN, for Internet — nearly always), the type, and the value. The lookup tells you four things at a glance: the site has both IPv4 and IPv6 addresses, its mail goes to one server, its DNS is delegated to one name server, and it publishes an SPF policy for its mail. If any of those lines is missing, the corresponding service fails in a specific way: no A record means the site does not resolve at all, no MX record means mail bounces or falls back to the A record (which is rarely what anyone wants), and no TXT record means verification checks and spam filters start failing quietly. To see a live version of this for any domain, run a free DNS lookup — it shows every record type with its TTL and gives a straight resolves-or-not verdict, so you are reading real answers instead of guessing from symptoms.

The mistakes that take sites offline

• CNAME at the apex. Putting a CNAME on the bare domain conflicts with the SOA and NS records that must live there. Use your provider's alias/flattening record for apex pointing, and keep CNAMEs for subdomains.
• MX pointing at a CNAME. Mail servers expect an MX target that resolves directly to an address record. Point MX at a hostname with its own A record, and end the value with a dot in zone files.
• Changing records without lowering TTL first. A record with a 24-hour TTL changed at noon keeps serving the old value to cached resolvers until the next day. Lower TTLs before migrations, then raise them again once things settle.
• Confusing "not propagated" with "cached." If a record shows correctly from one resolver and wrongly from another, that is caching, not propagation — the authoritative answer is already right, and the stale resolver just needs its TTL to expire. Cloudflare's DNS records guide makes the same distinction: records live on authoritative servers, and TTL controls how often resolvers refresh them.
• TXT records with broken quoting. SPF and verification strings are picky about spaces and quotes. One stray character invalidates the whole string, and the failure shows up as someone else's spam filter rejecting your mail — far from the record you edited.
• Forgetting the trailing dot. In zone-file syntax, a name without a trailing dot is treated as relative to the zone, so mail.example.com without the dot can silently become mail.example.com.example.com. Most provider dashboards add the dot for you, but raw zone files do not.

Choosing a DNS lookup tool

When you compare DNS lookup tools, the useful ones share four traits: they query public resolvers rather than your own device (so a broken local cache cannot fool them), they show every record type in one view instead of making you query type by type, they display each record's TTL so you can tell caching from a real error, and they give a plain resolves-or-not verdict instead of a raw dump you have to interpret. A tool missing the TTL column will send you chasing "propagation" problems that are really just caches waiting out their timers. The lookup linked above covers all four, and it is the fastest way to check whether a record change has actually taken effect from the internet's point of view rather than your laptop's.

When a record problem looks like something else

Not every DNS failure is a record problem. If the domain itself does not exist anywhere, resolvers answer NXDOMAIN — "this name does not exist" — which is a different failure from a missing A record on a real domain (where the name exists but has no address) and from a record that exists but is cached stale elsewhere. The symptoms overlap in the browser (the site "can't be reached" either way), which is why the first diagnostic step is always a lookup from outside your own network: it tells you whether the problem is your device, the domain's records, or just a cache. For the full device-vs-domain diagnosis and the fixes for each case, see our guide to fixing dns_probe_finished_nxdomain — it starts exactly where this post ends, with a lookup result in hand.

FAQ

What is a DNS record?
A DNS record is one instruction in your domain's zone: a name, a type, a value, and a TTL. Together, a domain's records tell the internet where its website lives, where its mail goes, which name servers answer for it, and which services are allowed to verify or certify it.

Which DNS record points a domain to a website?
The A record for IPv4, and the AAAA record for IPv6. A CNAME can also do the job indirectly for a subdomain, by pointing it at another name that itself has an A or AAAA record — but a CNAME cannot sit at the bare domain, where the SOA and NS records already live.

What does an MX record do?
It names the mail servers that accept email for a domain, with a preference number each — lower numbers are tried first. Without MX records, sending servers fall back to the domain's A record, which is almost never the mail server you intended.

Why is my site still showing the old version after I changed DNS?
Because resolvers cached the old record for its TTL. If the TTL was 3600 seconds, expect up to an hour of stale answers; the authoritative change itself is immediate. Lower TTLs before your next migration, and check from a public resolver rather than your own device to see the real answer.

What is the best free DNS lookup tool?
The best free DNS lookup tools are the ones that query public resolvers (not your own cache), show all record types with their TTLs in one view, and give a clear resolves-or-not verdict. Those three traits matter more than any extra feature: without TTLs you cannot tell a cache problem from a record problem, and without a public resolver you cannot tell a device problem from a domain problem.

What does "DNS record not found" mean?
It means the name exists in DNS but has no record of the type you asked for — for example, a domain with an A record but no MX record returns "not found" for an MX query. That is different from NXDOMAIN, where the name itself does not exist at all. Check which case you have with a full lookup before changing anything.

How long does DNS propagation really take?
There is no single propagation time: it is the TTL of the old record, per resolver, plus any name-server change (which can take up to 48 hours to reach every resolver). For ordinary record edits with a 300-second TTL, most of the internet sees the change within minutes; for name-server changes, plan on a day or two of mixed answers.