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

DNS records are the instructions that tell the internet where your domain's services live. A and AAAA records point a name to an IPv4 or IPv6 address, CNAME makes one name an alias of another, MX says which servers accept your email, TXT holds text used for verification and email security, and NS names the servers that are authoritative for your domain. Understanding these six covers almost every change a site owner needs to make.

Key takeaways

• A and AAAA records hold IP addresses. CNAME, MX and NS records hold hostnames.
• A CNAME cannot sit alongside other records for the same name, so it cannot normally be used at the root of a domain.
• MX records must point to a hostname that has an A or AAAA record, never directly to an IP address.
• Only one SPF TXT record is allowed per domain. Merge multiple senders into one record.
• NS records at your registrar decide which DNS provider's records actually count.

How a DNS lookup works, briefly

When someone visits www.example.com, their device asks a recursive resolver (often run by their ISP or a public DNS service). The resolver asks the root servers, then the .com servers, which reply with the NS records for example.com. The resolver then asks those name servers for the record it needs and caches the answer for the record's TTL (time to live), in seconds.

Every record has the same basic shape: a name, a TTL, a class (almost always IN), a type and the data. In zone-file format:

; name          TTL    class  type   data
example.com.     3600   IN     A      192.0.2.10

The trailing dot means the name is fully qualified. Most DNS control panels hide this detail and use @ to mean the root of the domain.

A record: name to IPv4 address

An A record maps a hostname to an IPv4 address. It is the record most websites depend on.

example.com.       3600  IN  A  192.0.2.10
www.example.com.   3600  IN  A  192.0.2.10

You can have several A records for one name, and resolvers will return all of them. That is a simple form of load distribution, but it is not health-checked: if one server is down, some visitors will still be sent to it.

To confirm what a hostname currently resolves to, use Domain into IP. If the result differs from the IP your host gave you, the record is wrong or an old value is still cached.

AAAA record: name to IPv6 address

AAAA (pronounced "quad-A") does the same job for IPv6 addresses.

example.com.  3600  IN  AAAA  2001:db8::10

Only publish an AAAA record if your server actually answers on that IPv6 address. A wrong AAAA record is a subtle failure: visitors on IPv6-capable networks may get timeouts while everyone else sees the site fine, which makes it hard to reproduce.

CNAME record: an alias for another name

A CNAME (canonical name) record says "this name is an alias; go and look up that other name instead".

www.example.com.   3600  IN  CNAME  example.com.
shop.example.com.  3600  IN  CNAME  stores.example.net.

CNAMEs are useful when a third party controls the IP addresses, such as a CDN, a hosted store or a help desk platform. They change their IPs; your alias keeps working.

CNAME rules that trip people up

• No other records at the same name. If shop.example.com is a CNAME, it cannot also have an MX or TXT record.
• Not at the root (apex). The root of a domain must have SOA and NS records, so a standard CNAME cannot be placed there. Some DNS providers offer "ALIAS", "ANAME" or "CNAME flattening" features that behave like a CNAME at the root by returning the target's IP addresses. These are provider features, not a standard record type.
• Point to a name, not an IP. The data of a CNAME is always a hostname.
• Avoid long chains. A CNAME pointing to another CNAME pointing to another adds lookups and points of failure.

MX record: where your email goes

MX (mail exchange) records list the servers that accept email for your domain, each with a priority number. Lower numbers are tried first.

example.com.  3600  IN  MX  10 mx1.example.net.
example.com.  3600  IN  MX  20 mx2.example.net.

Sending servers try mx1 first and fall back to mx2 if it is unreachable. Records with equal priority share the load.

Rules to follow:

• The target must be a hostname with its own A or AAAA record. An MX record pointing to an IP address is invalid, and pointing it to a CNAME is not allowed by the DNS standards, even if some mail servers tolerate it.
• When you move to a new email provider, remove the old MX records. Leftover records mean some mail is delivered to the old system.
• A domain with no MX record may still receive mail at its A record address as a fallback. If a domain should never receive mail, you can publish a "null MX" (0 .) to say so explicitly.

TXT record: verification and email security

TXT records hold arbitrary text. In practice they are used for three main things:

1. Domain verification for services like Google Search Console or Microsoft 365.
2. SPF, which lists the servers allowed to send mail for your domain.
3. DKIM and DMARC, which publish signing keys and email authentication policy.

example.com.                 TXT  "google-site-verification=abc123..."
example.com.                 TXT  "v=spf1 include:_spf.example.net ip4:192.0.2.10 -all"
sel1._domainkey.example.com. TXT  "v=DKIM1; k=rsa; p=MIIBIjANBg..."
_dmarc.example.com.          TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

Common TXT mistakes

• Two SPF records. A domain must have only one TXT record starting with v=spf1. Two records cause SPF to fail. Combine them into one with multiple include: entries.
• Too many SPF lookups. SPF allows at most 10 DNS lookups during evaluation. Each include can trigger more, so long chains of providers can exceed the limit.
• DMARC on the wrong name. The DMARC record lives at _dmarc.example.com, not at the root.
• Removing verification records. Some services re-check verification periodically. Leave the record in place while you use the service.

NS record: who is in charge of your DNS

NS (name server) records name the servers that hold the authoritative copy of your zone.

example.com.  86400  IN  NS  ns1.dnsprovider.example.
example.com.  86400  IN  NS  ns2.dnsprovider.example.

The NS records that matter most are the ones set at your registrar, because those are what the .com (or other top-level domain) servers hand out. If your registrar points to DNS provider A, any records you edit at DNS provider B are ignored. This is the single most common reason a "DNS change didn't work".

You can also use NS records inside your zone to delegate a subdomain to a different provider, for example sending dev.example.com to a separate DNS service.

TTL and propagation

"DNS propagation" is mostly caching. Resolvers keep an answer until its TTL expires, so a record with a TTL of 86400 may be served from cache for up to a day after you change it. Before a planned migration:

1. Lower the TTL of the records you will change (for example to 300 seconds) at least one full old-TTL period in advance.
2. Make the change.
3. Check the result from more than one network.
4. Raise the TTL again once everything is stable.

NS changes at the registrar can take longer, because the top-level domain's own TTLs apply and you cannot lower them.

Checking your records

A lookup tool shows what the world sees, which is not always what your control panel shows. Find DNS Records lists the A, AAAA, CNAME, MX, TXT and NS records for a domain so you can compare them against what you expect. On the command line, dig example.com MX or nslookup -type=TXT example.com do the same job.

Quick reference

Next steps

1. Confirm which DNS provider your registrar's NS records point to.
2. Look up your current records and write down what each one is for.
3. Delete records for services you no longer use, especially old MX and verification entries.
4. Check you have exactly one SPF record and a DMARC record at _dmarc.
5. Lower TTLs before your next migration, not during it.