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

Every time you visit a website or send an email, a quiet lookup happens first: your device asks the Domain Name System (DNS) where that name lives. DNS is configured with a handful of record types, and knowing what each one does makes moving a website, setting up email or debugging an outage far less mysterious. This guide covers the records you will actually meet, with real-world examples.

How a DNS lookup works, in 30 seconds

When you type example.com into a browser, your computer asks a recursive resolver, usually run by your internet provider or a public service like Cloudflare's 1.1.1.1. If the resolver doesn't already have the answer cached, it asks the root servers which servers handle .com, asks those which servers are authoritative for example.com, and finally asks the authoritative server for the record it needs. The answer is cached for a period called the TTL (time to live), so the next lookup is instant.

A and AAAA records: where the website lives

An A record maps a name to an IPv4 address such as 93.184.215.14. An AAAA record ("quad-A") does the same for an IPv6 address like 2606:2800:21f:cb07:6820:80da:af6b:8b2c. These are the records your web host asks you to create when you point a domain at a server.

example.com.      3600  IN  A     93.184.215.14
example.com.      3600  IN  AAAA  2606:2800:21f:cb07:6820:80da:af6b:8b2c

A name can have several A records; resolvers return them all and clients spread their connections across them, a simple form of load balancing.

CNAME records: an alias for another name

A CNAME (canonical name) says "this name is really that other name; go look that up instead." It is how you point www.example.com or shop.example.com at a hosting platform without hard-coding its IP addresses, which the platform can then change freely.

www.example.com.  3600  IN  CNAME  example-site.hosting-provider.net.

Two rules trip people up:

• A CNAME cannot coexist with other records on the same name. If www has a CNAME, it can't also have an MX or TXT record.
• You can't put a CNAME on the bare domain (example.com itself), because the apex must carry NS and SOA records. Many DNS providers offer a workaround called ALIAS, ANAME or "CNAME flattening" that behaves like a CNAME but returns A records.

MX records: where email is delivered

MX (mail exchanger) records tell other mail servers where to deliver email for your domain. Each has a priority number, and lower numbers are tried first. Equal priorities share the load.

example.com.  3600  IN  MX  1   aspmx.l.google.com.
example.com.  3600  IN  MX  5   alt1.aspmx.l.google.com.

If you switch email providers, the MX records are what you change. An MX record must point to a hostname, never directly to an IP address or to a CNAME.

TXT records: proof and policy

TXT records hold arbitrary text, and over time they have become the place for verification tokens and email security policies. The three you are most likely to need are:

• SPF lists which servers may send email for your domain, e.g. v=spf1 include:_spf.google.com ~all. Only one SPF record is allowed per domain.
• DKIM publishes a public key (at a name like selector._domainkey.example.com) that receivers use to verify your messages' cryptographic signatures.
• DMARC, at _dmarc.example.com, tells receivers what to do with mail that fails SPF and DKIM, e.g. v=DMARC1; p=quarantine; rua=mailto:reports@example.com.

Since 2024, Google and Yahoo require SPF, DKIM and DMARC for anyone sending large volumes of email, so these records are no longer optional extras. Services like Google Search Console and many SaaS tools also ask you to add a TXT record to prove you own a domain.

NS and SOA records: who is in charge

NS (name server) records list the servers that are authoritative for the domain, which is where all the other records live. They are set at your registrar. This is the most common source of confusion: if your NS records point to Cloudflare but you are editing records at your registrar, your changes do nothing.

The SOA (start of authority) record holds administrative details about the zone: the primary name server, a contact address, a serial number that increments with each change, and timers secondary servers use for refreshing. You rarely edit it by hand.

TTL and "propagation"

DNS changes don't really "propagate". Resolvers simply keep serving the old answer until its TTL runs out. If a record has a TTL of 86,400 seconds (one day), some visitors may see the old value for up to a day after you change it. A useful trick before a planned migration is to lower the TTL to 300 seconds a day in advance, make the switch, then raise it again once everything is stable.

Debugging checklist

1. Check the NS records first. Are you editing DNS at the provider that is actually authoritative?
2. Look up the specific record (A, CNAME, MX…) and compare it character by character with your host's instructions.
3. Watch for a stray trailing dot or a duplicated domain (e.g. www.example.com.example.com), a classic copy-paste mistake.
4. Make sure you don't have a CNAME clashing with other records on the same name.
5. If you changed something recently, compare the old record's TTL with how long ago you made the change.

You can check every record type for any domain, live, with our DNS Lookup tool. It queries public resolvers directly, so you see what the rest of the internet sees.