Skip to content
toolsdocks

Understanding DNS records: A, AAAA, CNAME, MX, TXT and NS

9 min read · Updated 4 October 2026

The Domain Name System (DNS) is the internet's directory. When you type a domain name into a browser or send an email, a resolver asks the DNS servers responsible for that domain a simple question: "what records do you have for this name, of this type?" The answers tell the browser which server to connect to, or tell a mail server where to deliver a message.

Each answer is a resource record. Every record has the same basic parts:

  • a name (for example www.example.com),
  • a type (A, AAAA, CNAME, MX, TXT, NS and so on),
  • a TTL (time to live: how many seconds resolvers may cache it),
  • and the data itself, whose format depends on the type.

Once you understand a handful of record types, most DNS problems become much easier to diagnose. You can follow along by looking up your own domain with the DNS lookup tool, which queries a public resolver and shows every record with its TTL.

A sample zone

Here is a small, realistic set of records for a fictional domain. The addresses come from ranges reserved for documentation, so they will never point at a real server.

Name Type TTL Data
example.com A 3600 192.0.2.10
example.com AAAA 3600 2001:db8::10
www.example.com CNAME 3600 example.com
shop.example.com CNAME 3600 stores.shopprovider.example
example.com MX 3600 10 mail1.example.com
example.com MX 3600 20 mail2.example.com
mail1.example.com A 3600 198.51.100.25
mail2.example.com A 3600 198.51.100.26
example.com TXT 3600 "v=spf1 mx -all"
example.com NS 86400 ns1.dnshost.example
example.com NS 86400 ns2.dnshost.example

The rest of this guide walks through what each line means.

A and AAAA: names to addresses

An A record maps a name to an IPv4 address: four numbers from 0 to 255 separated by dots, such as 192.0.2.10. An AAAA record ("quad-A") does the same for an IPv6 address, such as 2001:db8::10. The name comes from IPv6 addresses being four times as long as IPv4 ones (128 bits instead of 32).

A name can have several A records. If example.com had A records for 192.0.2.10 and 192.0.2.11, resolvers would return both, and clients would usually try them in the order received, which servers often rotate. This is a simple form of load spreading, though it is not real failover: a client may still try an address that is down.

If you publish an AAAA record, make sure the server really accepts connections on that IPv6 address. Many devices prefer IPv6 when it is available, so a stale or wrong AAAA record can make a site fail for some visitors while it works perfectly for others.

CNAME: an alias for another name

A CNAME (canonical name) record says "this name is an alias; go and look up that other name instead". In the sample zone, www.example.com is an alias for example.com, so a resolver that asks for the A record of www gets the CNAME, follows it, and returns the A record of example.com.

CNAMEs are useful when a third party controls the address. If your online shop is hosted by a provider, you point shop.example.com at the hostname they give you. When they move servers, they update their own records and yours keep working.

CNAMEs come with two strict rules:

  1. A name with a CNAME cannot have any other records. You cannot have a CNAME and a TXT record on the same name, for instance. DNS software will reject it, or behave unpredictably if it is allowed.
  2. The root of your domain (the "apex", often written @) cannot be a CNAME, because the apex must always have NS and SOA records. That follows directly from rule 1.

Many DNS providers work around rule 2 with a feature called ALIAS, ANAME or "CNAME flattening": you enter a hostname at the apex, and the provider looks it up itself and publishes the resulting addresses as ordinary A and AAAA records. It behaves like a CNAME for you, but other resolvers only ever see A records.

MX: where email goes

An MX (mail exchanger) record lists a server that accepts email for the domain. Each MX record has two parts: a preference number and a hostname. Sending servers try the lowest number first. In the sample zone, mail goes to mail1.example.com (preference 10); if that server cannot be reached, senders fall back to mail2.example.com (preference 20). Two records with the same number share the load roughly equally.

The numbers are relative, so 10 and 20 mean exactly the same as 1 and 2. Leaving gaps simply makes it easier to insert a server later.

Two details matter:

  • An MX record must point to a hostname, never directly to an IP address. That hostname then needs its own A or AAAA record, as mail1 and mail2 have above.
  • The target should not be a CNAME. Many mail servers tolerate it, but the standards say it should be the real name, and some senders are strict.

If a domain has no MX record at all, senders may try to deliver to the domain's A record instead. If a domain should never receive email, you can publish a "null MX" (a single MX record with preference 0 and a target of .), which tells senders not to try.

TXT: free-form text with important jobs

A TXT record holds arbitrary text. It started as a place for human-readable notes, but today it carries several machine-readable standards:

  • SPF: a TXT record on the domain beginning v=spf1 that lists which servers may send mail for it.
  • DMARC: a TXT record on the special name _dmarc.example.com beginning v=DMARC1, telling receivers what to do with mail that fails checks.
  • DKIM: public keys published at names like selector1._domainkey.example.com.
  • Domain verification: services often ask you to add a TXT record containing a random token to prove you control a domain.

A single text string inside a TXT record can be at most 255 characters. Longer values, such as 2048-bit DKIM keys, are split into several quoted strings in one record, and the receiver joins them back together without spaces. Most DNS control panels do this splitting for you.

A domain can have many TXT records, but it must have only one SPF record. Two records that both start with v=spf1 cause SPF to fail with an error. If you use two email services, merge their include: entries into one record. The email authentication checker reads SPF, DKIM and DMARC for a domain and flags problems like duplicate records or too many DNS lookups.

NS and SOA: who is in charge

NS (name server) records say which servers are authoritative for a domain, meaning the servers that hold the real records rather than cached copies. They appear in two places:

  1. At your registrar, in the parent zone. When you register example.com, the .com registry stores NS records pointing to your DNS host. This delegation is what actually sends resolvers to your provider.
  2. Inside your own zone, where the same NS records are repeated.

The two sets should match. A very common confusion: you edit records in one provider's dashboard, but your registrar's NS records point to a different provider, so nothing you change has any effect. Looking up the NS records for your domain shows immediately which provider is really answering.

Each zone also has exactly one SOA (start of authority) record. It names the primary server and a contact address, and holds a serial number and timers used when copying the zone between servers. Its last field also controls how long resolvers cache a "this name does not exist" answer, which is why a newly created record can sometimes take a while to appear if someone looked it up just before you added it.

Other records you will meet

Type Purpose Example data
CAA Lists which certificate authorities may issue TLS certificates for the domain 0 issue "ca.example.net"
SRV Locates a service with priority, weight, port and host 10 5 5060 sip.example.com
PTR Reverse DNS: maps an IP address back to a name, set by whoever controls the IP range mail1.example.com

PTR records matter mostly for mail servers: many receivers distrust mail from an IP address whose reverse lookup does not match a sensible hostname. You set them through your hosting or IP provider, not in your own domain's zone.

TTL, caching and "propagation"

When a resolver gets an answer, it keeps it for the record's TTL. With a TTL of 3600, a resolver that looked up your A record at 10:00 may keep using the old address until 11:00, even if you changed it at 10:01. There is no central system pushing changes out; "propagation" is really just caches around the world expiring at different times.

A practical plan for moving a site to a new server:

  1. A day or two before the move, lower the TTL on the records you will change, for example from 86400 (one day) to 300 (five minutes).
  2. Wait at least as long as the old TTL, so every cache has picked up the short one.
  3. Change the records. Most visitors now switch within about five minutes.
  4. Once everything works, raise the TTL again to reduce lookup traffic.

Lowering the TTL at the same moment you change the address does not help, because caches still hold the old record with its old, long TTL.

How to check your records

  1. Look up the NS records first to confirm which provider is authoritative.
  2. Look up A and AAAA for both the apex and www.
  3. Look up MX, then the A records of each MX hostname.
  4. Look up TXT on the apex and on _dmarc.
  5. Compare the TTLs with what you expect. A TTL counting down below the value you set means you are seeing a cached answer.

Common mistakes

  • Creating a CNAME at the apex, or a CNAME next to other records on the same name.
  • Editing at the wrong provider, because the registrar's NS records point elsewhere.
  • Missing trailing dot in raw zone files. In zone-file syntax, mail.example.com without a final dot is treated as relative and becomes mail.example.com.example.com. Web dashboards usually handle this, but imported zone files often do not.
  • Two SPF records instead of one merged record.
  • Forgetting www. Visitors type both forms; give both a record and redirect one to the other.
  • Stale AAAA records left behind after a server move, which break the site only for IPv6 users.

FAQ

How long do DNS changes take? For a new name nobody has looked up, usually seconds to minutes. For a changed record, up to the old TTL. Changes to NS records at the registrar can take longer, because the parent zone's NS records often have TTLs of a day or two.

Why does the lookup show a different value from my dashboard? Either you are seeing a cached answer that has not yet expired, or the dashboard belongs to a provider that is not authoritative for the domain. Check the NS records.

Do I need an AAAA record? Only if your server has a working IPv6 address. A site with only A records is reachable by practically everyone; a wrong AAAA record is worse than none.