DNS Records Explained: A, AAAA, CNAME, MX, TXT, and NS (with an Audit Checklist)

DNS is the control plane of your online presence. It decides where your website points, where your email is delivered, and how other services discover your infrastructure. Small DNS mistakes can cause big outages — or silent security issues that only show up when it’s too late.

This guide explains the DNS records you’ll see most often, why they matter, and how to audit them quickly.

DNS in one paragraph

The Domain Name System translates human-friendly names (like example.com) into technical records (like IP addresses). Clients query DNS resolvers, which fetch authoritative answers from your domain’s nameservers.

Two practical consequences:

• Changes are not instant everywhere. DNS answers are cached based on TTLs.
• Your authoritative configuration matters. Misconfigured records propagate to everyone.

The record types you should know

A record (IPv4 address)

An A record maps a hostname to an IPv4 address:

www.example.com.  300  IN  A  203.0.113.10

Use cases:

• Website hosting
• API endpoints
• Any service reachable over IPv4

AAAA record (IPv6 address)

An AAAA record maps a hostname to an IPv6 address:

www.example.com.  300  IN  AAAA  2001:db8::10

If you publish AAAA records, make sure your IPv6 path is actually healthy. “Broken IPv6” can harm user experience because clients often prefer IPv6 and only fall back after a delay.

CNAME record (alias)

A CNAME points one name to another name:

www.example.com.  300  IN  CNAME  example.net.

Rules of thumb:

• A CNAME generally should not coexist with other records at the same name (because it’s an alias).
• It’s common for www to be a CNAME, while the “apex” (example.com) uses A/AAAA/ALIAS/ANAME patterns depending on DNS provider features.

MX record (mail exchange)

An MX record tells the world where to deliver email for a domain:

example.com.  300  IN  MX  10  mail1.example.com.
example.com.  300  IN  MX  20  mail2.example.com.

The lower number is higher priority. If you have multiple MX records, make sure they are valid hostnames that resolve to A/AAAA records.

TXT record (metadata, verification, and email auth)

TXT records are a flexible “text payload” record type used for:

• Domain verification for third-party services
• Security and policy metadata
• Email authentication (SPF / DKIM / DMARC)

Example SPF TXT:

example.com.  300  IN  TXT  "v=spf1 ip4:203.0.113.10 -all"

Example DMARC TXT:

_dmarc.example.com.  300  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

NS record (nameservers)

NS records define which nameservers are authoritative for your domain:

example.com.  86400  IN  NS  ns1.example-dns.net.
example.com.  86400  IN  NS  ns2.example-dns.net.

NS records are “foundational.” If they’re wrong or inconsistent, everything else becomes unreliable.

(Optional but valuable) CAA record (certificate issuance control)

CAA records tell certificate authorities which issuers are allowed to issue TLS certificates for your domain.

Even a basic CAA policy can reduce mis-issuance risk:

example.com.  300  IN  CAA  0 issue "example-ca.com"

If you don’t understand CAA yet, you can still audit whether one exists and whether it matches your intended posture.

TTL, caching, and “why isn’t my change live yet?”

DNS responses are cached based on TTL (time to live). Common pitfalls:

• You lowered the TTL after a change — but caches already stored the old TTL.
• You updated one nameserver but not the others (inconsistent zone state).
• Your resolver is pinned to a stale answer.

If you’re doing a migration, lower TTLs in advance (often 24–48 hours ahead) so caches expire quickly when you flip records.

The DNS audit checklist (do this on every important domain)

Availability & control

• NS records match your intended authoritative nameservers.
• Domain registration contact paths are up to date (to avoid losing access).
• DNS changes are documented and access is limited to trusted admins.

Website delivery

• @ (apex) and www both resolve correctly (A/AAAA/CNAME as intended).
• AAAA exists only if IPv6 is correctly supported end-to-end.
• No stale records remain from old hosting or staging environments.

Email delivery & spoofing resistance

• MX records exist (if you expect to receive email).
• SPF exists and is valid (only one SPF TXT record).
• DKIM selectors exist (if your mail system signs).
• DMARC exists and policy is intentional (start with monitoring, then enforce).

Common DNS mistakes (and how to fix them)

Mistake: allowing “naked hostnames” as domains

Inputs like chatterbox (no public suffix like .com) aren’t real domains on the public internet. In tooling and validation, reject these early to avoid confusing output and wasted lookups.

Mistake: multiple SPF records

Only one SPF TXT record should exist at the root. If you have multiple, merge them into one record. Multiple SPF records can cause SPF to fail unpredictably.

Mistake: CNAME at the apex with other records

The apex (example.com) often needs MX, TXT, and sometimes other records. A pure CNAME at the apex can conflict with that. Use an alias mechanism supported by your DNS host if you need apex-level indirection.

Mistake: publishing AAAA before IPv6 is ready

If IPv6 routing or firewalling is partially broken, users can experience slow loads due to timeouts. Validate IPv6 reachability before publishing AAAA records broadly.

Troubleshooting commands you can copy/paste

Check A/AAAA:

dig A example.com +short
dig AAAA example.com +short

Check MX:

dig MX example.com +short

Check TXT:

dig TXT example.com +short
dig TXT _dmarc.example.com +short

Check authoritative NS:

dig NS example.com +short

FAQ

Do I need AAAA records?

Only if your infrastructure is IPv6-capable end-to-end. Otherwise, it’s fine to stay IPv4-only — but plan an IPv6 rollout if you serve global audiences.

My DNS changes “work for me” but not for others. Why?

Caching. Different resolvers respect TTLs and cache independently. Validate using a few different resolvers and wait for TTL expiry.

What’s the fastest way to get a high-level view of my DNS records?

Use Domain Lookup to see common record types in one place, then verify details with dig when you need authoritative answers.