Guide · Jul 7, 2026 · Updated Oct 5, 2026

A Record vs CNAME vs TXT: DNS Records Explained

DNS is one of those systems everyone relies on constantly and almost nobody looks at directly until something breaks — a domain won't point where it should, email silently stops arriving, or a hosting provider's setup instructions casually mention "add a TXT record" with no explanation of what that actually means. The record types themselves are simple once you see what each one is actually for; the confusion is usually just never having had a reason to learn the vocabulary.

A and AAAA: where a domain actually points

An A record maps a domain directly to an IPv4 address, like 192.0.2.1 — this is the most fundamental record type, since it's what ultimately tells a browser which server to connect to. AAAA does the identical job for IPv6 addresses (something like 2001:db8::1). A domain can have an A record, an AAAA record, both, or in older setups, just the A record — if AAAA comes back empty on a lookup, that simply means the domain isn't configured for IPv6 yet, which is still common and not inherently a problem.

CNAME: an alias, not an address

A CNAME record doesn't point to an IP address at all — it points to another domain name, and tells DNS "to resolve this, go look up that domain instead." This is how www.example.com is commonly set up to follow whatever example.com resolves to, without needing to be kept in sync manually if the underlying IP ever changes. The catch that trips people up: a domain's root (the "apex," like example.com with nothing in front of it) technically can't have a CNAME record per the DNS spec, only subdomains can — which is why apex domain setups sometimes need a different, provider-specific workaround (often called an ALIAS or ANAME record, which behaves like a CNAME but is technically implemented as something else under the hood). The underlying reason for that restriction is covered below, and it isn't arbitrary.

MX: where email for the domain actually goes

MX records point to the mail servers responsible for handling email sent to that domain, each with a priority number — lower numbers are tried first, with the others as fallback. A domain with no MX record isn't necessarily broken; it may simply not be set up to receive email at all, which is normal for plenty of subdomains used purely for hosting assets or a web app. Misconfigured MX records are a classic "email quietly stops arriving with no error message" bug, because the sending server just tries the next mail exchange or gives up — nothing on the sender's end announces that your domain's setup is wrong.

TXT: the general-purpose catch-all

TXT records hold arbitrary text, and unlike the other types, they don't have one specific job — they're used for domain ownership verification (Google Search Console and similar tools ask you to add one to prove you control a domain), SPF and DKIM email authentication records (which help receiving mail servers verify a message actually came from who it claims to), and various other one-off verification schemes that different services invent. A single domain often has several unrelated TXT records at once, each serving a completely different purpose, which is why it's common to see a handful of them stacked up on any domain that's been through a few service integrations.

NS: who's actually authoritative

NS records specify which nameservers are authoritative for a domain — in other words, which servers hold the real, current answer for all of that domain's other records. This is set at the domain registrar level, and it's usually the first thing that has to propagate correctly whenever a domain moves to a new host or DNS provider; get this wrong, and none of the domain's other records matter, because nothing is asking the right server for them in the first place.

"DNS vs DNS zone vs CNAME vs TXT" — these aren't alternatives

One confusion worth clearing up before the record types themselves, because it shows up constantly in how people phrase the question: DNS, a zone, and a record are not four options you pick between. They're three different levels of the same thing, and a record type is the fourth.

DNS is the system — the global, distributed lookup service that turns names into addresses. A zone is an administrative slice of it: the portion of the namespace that one set of nameservers is authoritative for, usually one domain and everything under it that hasn't been delegated elsewhere. A record is a single entry inside that zone. A, CNAME, TXT, MX are the types a record can be. So "CNAME vs TXT" is a real comparison, and "DNS vs DNS zone" isn't — it's like asking whether you'd rather have a filesystem or a folder.

The reason the confusion is so common isn't ignorance, it's the control panels. Providers label the page where you edit records "DNS Zone," "Zone Editor," or "Manage DNS" more or less interchangeably, so the word "zone" reads as a synonym for "the DNS settings screen" rather than as a technical container. It only starts to matter when you hit something that behaves at the zone level rather than the record level — delegating a subdomain to a different provider, exporting or importing a zone file, or a transfer that moves every record at once.

Two records exist in every zone whether you added them or not. SOA (Start of Authority) sits at the top and carries the zone's administrative data: which nameserver is primary, the responsible contact, and the serial number that secondary servers watch to know the zone changed. NS records declare which nameservers are authoritative. Most hosted DNS panels create and manage both for you and don't show the SOA at all, which is why plenty of people manage DNS for years without encountering it.

That pair also explains the apex restriction properly. The real rule isn't "the spec forbids a CNAME on the apex" as an arbitrary prohibition — it's that a CNAME cannot coexist with any other record at the same name, because a CNAME means "everything for this name lives over there instead." The apex is required to hold SOA and NS records, so by definition it already has records, and a CNAME there would contradict them. Subdomains have no such requirement, which is why www can be a CNAME and the bare domain can't.

CNAME vs TXT: which one, and do you need both?

This question usually comes from a setup screen. An email service, an SSL certificate provider, or a site-verification step says "add this TXT record or this CNAME", or lists one of each, and doesn't explain the difference. The two records do opposite things:

Do you need both? If the instructions offer them as alternatives for the same step ("verify with a TXT record or a CNAME"), one is enough. Pick whichever your DNS panel handles more easily. If they are separate steps (a TXT for SPF, CNAMEs for DKIM, another TXT for DMARC at _dmarc), they do different jobs and each one is needed.

Why a CNAME sometimes can't go where you want it. This is the same rule as the apex restriction below: a CNAME can't share a name with any other record. If a name already holds a TXT record (the bare domain almost always does), you can't add a CNAME at that name. That's also why CNAME-based verification uses its own dedicated subdomain instead of the root.

Two practical details. A TXT value is stored as one or more strings of up to 255 characters each, which are joined when read. That's why long DKIM keys show up split into quoted chunks. A CNAME holds exactly one hostname. And when a TXT record is used for ownership verification, leave it in place after the check passes. Some services, Google Search Console among them, re-check periodically and drop your verification if the record disappears. One more email trap: a domain may publish only one SPF record (v=spf1 …). Adding a second for a new email service, instead of merging both into the existing one, makes SPF fail for both services.

Why "it hasn't updated yet" is usually true, not an excuse

DNS records are cached at multiple layers — your own device, your router, your ISP's resolver, public resolvers like Google's or Cloudflare's — each for a duration set by that record's TTL (time to live). A change made at the registrar or DNS provider isn't instantly visible everywhere; every cache holding the old value needs to expire first, which is exactly why the same lookup can return different, seemingly contradictory results depending on where and when it's run.

No record type propagates faster than another. A TXT, a CNAME, and an A record with the same TTL behave the same way. A brand-new name has a head start, because nobody has cached it yet. The exception is a name someone looked up before you created it, including the service's own "Verify" button clicked too early. Resolvers cache the "this name doesn't exist" answer for the zone's negative-caching time (taken from its SOA record, often anywhere from a few minutes to an hour). Until that expires, the new record looks missing even though it's there. Add the record first, wait a few minutes, then click verify.

Check it yourself

FreeToolDev's IP / DNS / SSL Bulk Lookup tool checks A, AAAA, MX, TXT, and NS records for a whole list of domains at once, and shows your own current public IP address instantly at the top of the page — no code, no separate "what's my IP" search needed.