DNS Record Types Explained: How to Read a Zone Without Guessing

If you have ever opened a DNS panel, seen a wall of A, CNAME, MX, and TXT rows, and quietly closed the tab, you are in good company. Most of us learn DNS by copying a record out of a tutorial and hoping. That approach gets you surprisingly far — right up to the moment something breaks and you cannot tell which row is the guilty one.

This is the guide I wish someone had handed me years ago. It is not a list of definitions to memorise. It is a way to read a zone and predict what it will actually do.

Why zones make competent people feel stupid

A DNS zone is a small database with an awkward interface. Every row answers exactly one question: for this name, what should a resolver return? That is the whole idea. The confusion comes from three things stacked on top of each other.

First, the same name can hold several records of different types at once. Second, some records are aliases that point at other names, which point at still other names. Third, nothing in the panel tells you which row wins when two of them disagree.

Once you accept that a zone is a lookup table with a handful of rules, it becomes readable. The rest of this article is those rules, in roughly the order you will meet them. Try it on DNS Checkers Lookup All DNS Records

Read the owner name before the record type

Beginners look at the type column first. Operators look at the owner name. That is the name the record is attached to, and it is where most bugs live.

Two names that look identical usually are not. In most panels @ means the apex — example.com with nothing in front of it. A blank name sometimes means the same thing and sometimes means "the name you were editing last", which is a genuinely dangerous ambiguity. www means www.example.com. And *.example.com is a wildcard that catches every name with no record of its own, excluding the apex itself.

Here is the classic failure. Someone adds an A record for www pointing at a new server, but users type the bare domain into the browser. The apex still points at the old host, so some visitors see the old site and others see the new one. Nothing is technically broken. The record was simply attached to the wrong name.

A habit worth forming: when a change does not seem to take effect, re-read the owner name character by character before you touch anything else. Roughly half the DNS tickets I have ever investigated ended there.

A and AAAA: the addresses

An A record maps a name to an IPv4 address. An AAAA record maps a name to an IPv6 address. They are independent, and a host can have one, the other, or both.

If you publish both, modern clients generally prefer IPv6 when it works. That is exactly why a broken AAAA record is so annoying: the site loads instantly for most people and hangs for everyone whose network resolves the bad address first. If you are not running IPv6 yet, the honest fix is to publish no AAAA record at all rather than a placeholder pointing somewhere that does not answer.

There is a quieter problem with A records: stale IPs. Hosts change addresses, load balancers get rebuilt, and an old record keeps sending a slice of your traffic to a machine that no longer belongs to you. Comparing your zone against what the host actually reports is a five-second check worth doing after any infrastructure change.

CNAME: the alias rule that breaks when you ignore it

A CNAME says "this name is another name — go ask there." It is an alias, not a redirect, and it carries the full result of the target. If shop.example.com is a CNAME to example.myshopify.com, then every record type at the target comes back for the alias too.

The rule that catches people is this: a CNAME must be the only record at its owner name. You cannot have a CNAME and an MX record on the same name. You cannot have a CNAME and a TXT record. This is not a recommendation from your DNS provider — it is part of how the protocol is defined, and providers that let you do it are setting a trap.

The second trap is the apex. You cannot put a CNAME at example.com itself, because the apex must also carry SOA and NS records, which the CNAME rule forbids. This is why providers invented ALIAS or ANAME records: they behave like a CNAME at the apex but are resolved server-side into real addresses. If your provider offers one, that is what it is for. If you are on a plain CNAME-only panel, point the apex at A/AAAA records and keep the alias on www.

MX: where mail goes, and why priority matters less than you think

MX records tell the world which servers accept mail for your domain. Each one has a preference number, and lower wins. 10 is tried before 20.

Two myths are worth clearing up. First, the numbers are relative, not absolute — what matters is the ordering among your own MX records, not whether you used 10 or 100. Second, a higher-priority backup server is not a queue that mail waits in. If your primary is reachable and refuses the recipient, the sending server does not silently escalate to the backup; it reports the failure. MX priority is about which host answers first, not about automatic failover for bad mailboxes.

Also remember that MX records must point at hostnames, never at bare IP addresses. And if you have a CNAME at the same name as your MX records — which you cannot, per the rule above — you have found your mail outage.

TXT: the drawer where email policy lives

TXT records were designed to carry arbitrary text, and the internet has used them for exactly that. Today they hold SPF policies, DKIM public keys, DMARC instructions, site-verification strings, and the occasional "owned by" note.

TXT records have a 255-character limit per string, and long values are split into chunks that the receiver concatenates. Most panels handle this for you, but if you paste a 300-character SPF record into a form and it complains, that is why.

The genuinely important detail for deliverability is that you must have exactly one SPF record. Two SPF TXT records on the same domain is a permanent error, and receivers will fail authentication rather than guess which one you meant. When you add a new sending service, merge its include into the existing record instead of adding a second one.

NS and SOA: who is in charge, and for how long

NS records delegate authority. They name the servers that are allowed to answer authoritatively for your zone. When someone says "your nameservers changed", they mean these records, and they live at the registrar as the delegation plus inside the zone as the published set.

An easy way to confuse yourself is to edit records at a DNS provider that is no longer authoritative. If the registrar points elsewhere, your edits are just notes in a notebook nobody reads. Always confirm the NS set before you start debugging anything else.

SOA records are the zone's metadata: primary server, responsible contact, serial number, and four timers. Two of those timers matter in everyday work. The refresh and retry values govern how secondary servers check for updates, and the last field — the minimum — doubles as the negative-caching TTL. That means it controls how long a "this name does not exist" answer is remembered. If you create a brand-new record on a zone with a very high SOA minimum, some resolvers may keep telling people it does not exist for longer than you expect.

SRV, CAA, PTR: the records you meet less often

SRV records describe where a service lives. Their owner names follow a rigid pattern — _service._protocol.name — and they carry priority, weight, port, and target. They are common for voice, chat, and directory services, and they are unforgiving about that naming pattern.

CAA records restrict which certificate authorities may issue certificates for your domain. A CAA record with tag issue names the allowed CA, and issuewild does the same for wildcard certificates. If you publish CAA and forget to include every CA your team actually uses, renewals start failing months later when nobody remembers this record exists. It is a strong control, and strong controls deserve a calendar reminder.

PTR records do reverse lookups: they map an IP address back to a hostname, and they live under in-addr.arpa in a zone owned by whoever holds the IP block. You usually cannot create them in your own DNS panel. They matter most for mail servers, and we cover them properly in a separate article.

TTL: the number that decides how long a mistake lives

Every record carries a time to live, in seconds, telling resolvers how long they may keep a copy. A TTL of 3600 means "trust this answer for an hour."

TTL is the single most useful lever you have during a change, and the one people ignore until it hurts. A long TTL is efficient and cheap. A short TTL is agile and slightly noisier. Neither is wrong; they are trade-offs, and the trade-off matters most in the window around a migration.

If you are about to move a record, lower the TTL well before you move it — not at the same time. We walk through the timing in the TTL guide linked below, because getting that order wrong is the most common self-inflicted outage in DNS.

A ten-minute audit routine

If you want a habit that catches most zone problems, run this once a quarter:

1. Pull every record type with an all-records lookup and read the owner names top to bottom.
2. Check that apex and www point where you think they do.
3. Confirm there is exactly one SPF TXT record, and that its includes match your real senders.
4. Verify MX hosts resolve and actually accept mail.
5. Look for records pointing at hosts that no longer exist.
6. Check CAA still lists every CA you use.
7. Note the TTLs on anything you plan to change soon.

None of that requires deep expertise. It requires patience and a place to write down what you found. The DNS Checkers validation tool exists to make step one fast. Try it on DNS Checkers Open DNS Checkers Tools

Where to go next

Records are the vocabulary; timing is the grammar. Once you can read a zone, the next thing worth learning is how changes travel through caches, which is what DNS propagation really means. After that, take the same zone and look at what it says about your email — because your TXT and MX records are quietly deciding whether your mail gets delivered or filed away.