DNS Records Explained: A, AAAA, CNAME, MX, TXT, NS and SOA

The short answer

A DNS record is one line of data in a domain's zone that tells the global Domain Name System how to answer a specific question about that domain. Every record shares the same four-part shape: a name (the hostname it applies to), a TTL (how many seconds resolvers may cache it), a type (A, MX, TXT, and so on), and the data itself. When a device looks up a name, a recursive resolver walks from the root servers down to the domain's authoritative name servers, fetches the matching records, and caches them until the TTL expires. So understanding record types is really just understanding which question each type answers.

In plain terms: an A record maps a name to an IPv4 address and an AAAA record maps it to an IPv6 address, and those are the records that actually point a domain at a server. A CNAME makes one name an alias of another name instead of an IP. An MX record names the mail servers that accept email for the domain, ranked by a preference number. TXT records hold free-form text, most importantly the SPF, DKIM, and DMARC policies that authenticate your mail and the tokens that prove domain ownership. NS records delegate the domain to its authoritative name servers, and the single SOA record carries the administrative metadata for the zone. Reading a lookup is then just a matter of matching the type column to the question you asked.

How a DNS lookup actually resolves

A lookup starts with a stub resolver on your device handing the name to a recursive resolver — your ISP's, or a public one like 1.1.1.1 or 8.8.8.8. If the recursive resolver has no cached answer, it walks the tree: it asks a root server, which points it to the .com (TLD) servers, which point it to your domain's authoritative name servers, which return the real records. The recursive resolver caches the result and hands it back. The authoritative servers hold the source of truth; everyone in between is just caching copies.

A zone is the slice of the DNS namespace that one operator controls, bounded by its own SOA and NS records. Delegating a subzone (say, a subsidiary getting its own name servers) means the parent zone publishes NS records pointing at the child's servers. This is why the same domain can have records served from different providers depending on where each zone is delegated.

TTL is a per-record cache lifetime measured in seconds. Nothing forces a cache to refresh before the TTL runs out, which is why a change you make on the authoritative server is invisible to users still holding a cached copy. What people call 'propagation delay' is almost never propagation — it is old records aging out of resolver caches. The practical move is to lower TTLs (for example to 300 seconds) a day before a planned IP change, make the change, confirm it, then raise them again.

• The recursive resolver does the walking and caching; the authoritative server holds the real records.
• The chain: root servers → TLD servers (.com) → your domain's authoritative name servers.
• A 'zone' is the portion of the DNS tree one operator manages, defined by its SOA and NS records.
• TTL is a per-record cache lifetime in seconds — nothing forces caches to refresh sooner.
• 'Propagation delay' is almost always just stale records sitting in caches until their TTL expires.
• Drop TTLs to ~300s a day before a planned migration, then raise them again once the change is confirmed.

A and AAAA: pointing a name at a server

An A record maps a hostname to a 32-bit IPv4 address written as a dotted quad, for example example.com → 93.184.216.34. This is the workhorse record — it is what makes a name resolve to an actual server. The data field is always a literal IP address, never another hostname. An AAAA record ('quad-A') does the same job for a 128-bit IPv6 address, for example → 2606:2800:220:1::. A dual-stack host publishes both; clients then use the Happy Eyeballs algorithm (RFC 8305) to race IPv4 and IPv6 and use whichever connects first.

A single name can carry several A or AAAA records. Resolvers may hand them back in rotating order, which is the crude technique known as round-robin DNS. It spreads connections across a few IPs, but it is not load balancing and not failover: DNS does not health-check the targets, so a dead server keeps getting its share of clients until you pull its record. For real balancing or failover you put a load balancer behind a single record, or use a DNS provider that health-checks.

One rule that trips people up: the apex (the bare root domain, example.com with no subdomain) must use A/AAAA records, not a CNAME. Providers that offer 'ALIAS' or 'ANAME' at the apex are simply resolving a target hostname on their side and returning its A/AAAA to you.

• A = IPv4 (example.com → 93.184.216.34); AAAA = IPv6 (→ 2606:2800:220:1::).
• The record data is a literal IP address, never another hostname.
• A name may hold several A/AAAA records; resolvers may rotate them (round robin) but do not health-check them.
• Round-robin DNS spreads load crudely but cannot detect or route around a dead server.
• Dual-stack hosts publish both; clients race the two with Happy Eyeballs (RFC 8305).
• The apex/root domain uses A/AAAA (or a provider ALIAS/ANAME), never a plain CNAME.

CNAME: aliasing one name to another

A CNAME (canonical name) record makes one name an alias of another name. When a resolver looks up the alias, it gets back the target name and then resolves that instead, following the chain until it reaches an A/AAAA record. The classic uses are pointing www.example.com at example.com, or pointing a subdomain at a vendor's hostname — a CDN edge, a load balancer, or a SaaS endpoint — so that when the vendor changes their underlying IPs, your record keeps working untouched.

The strict rule that causes most CNAME mistakes: a name that has a CNAME can have no other records of any type (RFC 1034 and RFC 2181). Because the zone apex must carry SOA and NS records, you cannot legally put a CNAME at the apex. That is exactly the gap that provider ALIAS/ANAME (or 'CNAME flattening') fills by resolving the target server-side and publishing A/AAAA for the apex. The same rule means a name with a CNAME cannot also hold MX or TXT records — a common cause of missing email on an aliased subdomain.

CNAMEs are not free. Every hop is an additional resolution step, so long chains add latency; keep them short. A more serious risk is the dangling CNAME: an alias pointing at a cloud resource you have since deleted. If an attacker can claim that now-unused target, they inherit your subdomain — the subdomain-takeover attack. Delete alias records the moment you tear down what they point to.

• CNAME data is a hostname, not an IP; the resolver follows it to an eventual A/AAAA.
• A name with a CNAME cannot coexist with MX, TXT, or any other record type.
• No CNAME at the apex — use A/AAAA or a provider ALIAS/ANAME instead.
• Ideal for subdomains that track a vendor endpoint (CDN, load balancer, SaaS) whose IPs change.
• Each CNAME hop is an extra lookup; avoid long alias chains.
• Delete CNAMEs pointing at torn-down resources — dangling aliases enable subdomain takeover.

MX and TXT: routing and authenticating email

An MX (mail exchanger) record names a server that accepts email for the domain, and each MX carries a preference number. Lower numbers are tried first; equal numbers share the load between servers. It is a priority order, not a percentage split. The target of an MX must be a hostname that itself resolves to an A/AAAA record — it can never be a raw IP address, and per spec it should not point at a CNAME. A special 'null MX' — a single dot with preference 0 (RFC 7505) — is the explicit way to declare that a domain sends and receives no mail at all.

Email authentication lives entirely in TXT records, and there are three that matter. SPF (a TXT beginning v=spf1) lists which servers are allowed to send mail as your domain — and there must be exactly one SPF record; two of them break evaluation. DKIM publishes a public key at selector._domainkey.example.com that receivers use to verify the cryptographic signature on your outbound mail. DMARC, at _dmarc.example.com and beginning v=DMARC1, tells receivers what to do when SPF or DKIM fails (none, quarantine, or reject) and where to send aggregate reports.

TXT records also carry the ownership-verification tokens that services like Google Workspace and Microsoft 365 ask you to publish before they will manage a domain. One quirk to know when pasting long values: a single TXT string maxes out at 255 characters, so long DKIM keys are stored as several quoted strings that the resolver concatenates back together.

• MX preference: the lowest number is tried first; equal numbers balance load — it is priority, not percentage.
• An MX target must be a hostname resolvable to A/AAAA — never an IP literal and never a CNAME.
• Null MX (a single '.' with preference 0, RFC 7505) declares 'this domain accepts no email.'
• Keep exactly one SPF TXT record per domain; multiple SPF records cause evaluation to fail.
• DKIM keys live at selector._domainkey.example.com; DMARC policy lives at _dmarc.example.com.
• Each TXT string caps at 255 characters, so long DKIM keys are split into multiple concatenated strings.

NS and SOA: who is authoritative for the zone

NS records list the authoritative name servers for a zone, and they exist in two places at once: the parent TLD publishes them as the delegation ('the .com servers say example.com lives on ns1/ns2.example.net'), and the zone itself publishes the same set internally. You should run at least two name servers, ideally on separate networks or providers, so a single outage does not take the domain dark. Changing DNS hosting is, at bottom, just changing the NS records at your registrar to point at the new provider's servers.

The SOA (Start of Authority) is a single record at the apex of every zone, and it is the zone's control block. Its fields are MNAME (the primary/master name server), RNAME (the administrative contact, written as an email with the @ replaced by a dot), SERIAL (a version number), REFRESH/RETRY/EXPIRE (timers that govern how secondary servers sync from the primary), and MINIMUM (which, per RFC 2308, now sets how long a 'does not exist' answer is cached).

The serial number is the field to respect operationally. Secondary servers only pull a fresh copy of the zone when the serial increases, so if you edit records but forget to bump the serial, your secondaries silently keep serving the old data. A common convention is YYYYMMDDnn — today's date plus a two-digit counter. Mismatches between the NS listed at the registrar and the NS inside the zone (or missing glue records) produce a 'lame delegation' that resolvers may reject.

• NS delegates a zone; the same server names appear both at the parent TLD and inside the zone.
• Run at least two name servers, ideally on diverse networks or providers.
• Switching DNS providers = updating the NS records at your registrar.
• SOA is single and apex-only, holding the zone's serial number and sync timers.
• SERIAL must increase on every edit or secondary servers won't pull the update (YYYYMMDDnn is common).
• SOA MINIMUM sets how long a negative (NXDOMAIN) answer is cached by resolvers.

How to read a lookup result

The clearest tool is dig. A command like `dig example.com MX` returns output split into sections: QUESTION (what you asked), ANSWER (the records that answer it), AUTHORITY (the zone's NS records), and ADDITIONAL (glue such as the A records for those name servers). Each answer line reads left to right as name, TTL, class (almost always IN for Internet), type, then the record data. Add `+short` to see just the data, `@1.1.1.1` to aim the query at a specific resolver, and `+trace` to watch the full walk from the root. On the header line, `status: NOERROR` with no answer means the name exists but has no record of that type, while `status: NXDOMAIN` means the name does not exist at all.

nslookup is the quick cross-platform equivalent — `nslookup -type=MX example.com` — and is fine for a fast check, though its output is terser. The key skill during a change is telling a cached answer from the authoritative one. Query the authoritative server directly (`dig @ns1.example.net example.com`) and you bypass every cache, so you see the live record regardless of what TTLs are still floating around out there. If the TTL in a repeated query keeps counting down, you are reading a cached copy, not the source.

Most real-world DNS failures are a handful of repeat offenders. Expecting an instant change (it is TTL caching). Trying to put a CNAME at the apex, or on a name that also needs MX/TXT. Pointing an MX at a CNAME. Publishing two SPF records. And, when editing a raw zone file, forgetting the trailing dot — a name written without one is treated as relative and gets the zone name appended, so `mail.example.com` silently becomes `mail.example.com.example.com`.

• `dig example.com A +short` returns just the IP; drop `+short` to see TTL, class, and the full section layout.
• Query the authoritative server directly (`dig @ns1.example.net example.com`) to bypass caches during a change.
• Sections: QUESTION (what you asked), ANSWER (the records), AUTHORITY (the NS set), ADDITIONAL (glue).
• `NXDOMAIN` means the name doesn't exist; `NOERROR` with no answer means it exists but has no record of that type.
• A TTL that decrements on repeated queries means you're reading a cached copy, not the authoritative one.
• Watch the classic errors: CNAME at the apex, MX pointing to a CNAME, two SPF records, and a missing trailing dot in zone files.

Frequently asked questions