DNS Record Types Explained: A, AAAA, CNAME, MX, TXT, NS

Open the DNS panel for a freshly registered domain and you are greeted by a wall of abbreviations: A, AAAA, CNAME, MX, TXT, NS. It looks intimidating, but every DNS record says the same simple thing — "when someone asks for this name, hand back this value". The record type just tells resolvers what kind of value it is: an IP address, another name, a mail server, or a blob of text.

This guide walks through the nine record types you will actually touch in practice, each with a real example value, and finishes with a line-by-line tour of the complete record set for a small-business domain. If you want to see any of this live, paste a domain into the DNS lookup tool and follow along with real answers.

Address records: A, AAAA, and the alias CNAME

The foundation of DNS is turning a name into an IP address. An A record holds an IPv4 address; an AAAA recordholds an IPv6 address (IPv6 addresses are four times as long as IPv4 — hence four A's).

• A — example.com → 93.184.216.34 (IPv4)
• AAAA — example.com → 2606:2800:21f:cb07:6820:80da:af6b:8b2c (IPv6)
• CNAME — www.example.com → example.com (delegate to another name)

A CNAMEdoes not store an IP at all — it says "the real answer lives under that other name, go ask there". That makes it perfect for pointing at a hosting provider whose IPs change under the hood. But CNAMEs come with two hard rules:

• No coexistence — once a name has a CNAME, it may not carry any other record type. A CNAME redirects every question about that name, so an MX or TXT sitting next to it would be contradictory.
• Never at the apex — the bare domain (example.com) must always have SOA and NS records, and by the rule above a CNAME cannot share the name with them. That is exactly why the standard pattern is: CNAME on www, an A record (or a provider extension like ALIAS/ANAME/CNAME flattening) on the root.

Mail records: MX plus TXT for SPF, DKIM and verification

An MX (Mail eXchanger) recordanswers "which server accepts mail for this domain?". Its value has two parts: a priority number and a hostname, e.g. 10 aspmx.l.google.com. Lower numbers are tried first; equal numbers share the load. One rule trips people up constantly: the MX target must be a hostname, never a raw IP — and that hostname must resolve via A/AAAA, not via a CNAME.

A TXT record is a free-form text container. It began life as a notepad, but today it carries the machinery of email authentication and service ownership:

• SPF — "v=spf1 include:_spf.google.com ~all": the list of servers allowed to send mail as this domain.
• DKIM — a public key published at a name like selector1._domainkey, used to verify mail signatures.
• Ownership verification — "google-site-verification=abc123...": how Search Console and similar services prove you control the domain.

Infrastructure and security records: NS, SOA, CAA, PTR

You rarely edit these day to day, but they are the skeleton of the zone.

• NS (Name Server) — example.com → ns1.dnshost.com.: which name servers are authoritative for the domain (delegation). This is what you change when switching DNS providers, and it is the slowest change to propagate worldwide.
• SOA (Start of Authority) — exactly one per zone. It names the primary server and admin contact and carries the serial (a zone version number that increments on every edit) plus refresh/retry/expire timers for secondary servers. Your DNS provider manages it automatically.
• CAA (Certification Authority Authorization) — 0 issue "letsencrypt.org": restricts which certificate authorities may issue SSL certificates for the domain. With no CAA record, any CA may issue. It is a cheap, worthwhile security upgrade.
• PTR (Pointer) — 34.216.184.93.in-addr.arpa → example.com: the reverse lookup, mapping an IP back to a name. Crucially, you do not set it in your domain's DNS panel — it lives with whoever owns the IP, i.e. your ISP or hosting provider. If you run your own mail server, a missing or mismatched PTR is a fast track to the spam folder.

The reference table

TTL is how long resolvers may cache an answer, in seconds. If you plan to change a value, lower its TTL a day or two ahead — the full sequence of a safe migration is covered by the DNS change checklist.

Worked example: a small business, record by record

Say a fictional shop, acme-store.com, hosts its website on a cloud server and uses Google Workspace for email. Here is everything its zone actually needs:

Read it line by line. A visitor typing www.acme-store.com hits the CNAME, which hands the question to the root, whose A record returns 203.0.113.10 — connection made. Mail sent to info@acme-store.comfollows the MX to Google's servers, while mail from the domain is validated by receivers against the SPF TXT and the DKIM key. The verification TXT unlocks Search Console, and CAA locks certificate issuance down to one CA. Notice how the root name carries A, MX, TXT and CAA side by side — which is precisely why a CNAME could never live there.

Once you have entered a set like this, verify each type answers as intended with a DNS lookup, and if you just made changes, confirm resolvers worldwide have picked them up with the DNS propagation checker.