DNS Records Explained: A, CNAME, MX, TXT and More

DNS, the Domain Name System, translates names like www.example.com into the information computers need to connect: IP addresses, mail servers and other settings. Each piece of that information is stored as a DNS record. If you run a website, you'll eventually need to add or change records to point a domain at a host, set up email, or verify ownership for a service.

This guide explains what each common record type does, with examples, and covers how TTL and caching actually work, including why "waiting for DNS to propagate" is a misleading way to think about changes.

How a DNS lookup works#

When a browser needs the address for www.example.com, it asks a recursive resolver, usually run by your internet provider, your company or a public DNS service. If the resolver doesn't have the answer cached, it works down the hierarchy:

1. It asks a root server where to find .com.
2. It asks the .com servers which nameservers are responsible for example.com.
3. It asks those authoritative nameservers for the record it needs.
4. It caches the answer for as long as the record's TTL allows.

The authoritative nameservers are where your records live, usually at your DNS host, web host or registrar.

A sample zone#

Here's a small set of records for a fictional domain, in standard zone file format. The IP addresses come from ranges reserved for documentation.

example.com.        3600  IN  SOA    ns1.dnshost.example. hostmaster.example.com. (
                                      2026091101 ; serial
                                      7200       ; refresh
                                      3600       ; retry
                                      1209600    ; expire
                                      3600 )     ; negative caching TTL
example.com.        86400 IN  NS     ns1.dnshost.example.
example.com.        86400 IN  NS     ns2.dnshost.example.
example.com.        3600  IN  A      192.0.2.10
example.com.        3600  IN  AAAA   2001:db8::10
www.example.com.    3600  IN  CNAME  example.com.
example.com.        3600  IN  MX     10 mail1.mailhost.example.
example.com.        3600  IN  MX     20 mail2.mailhost.example.
example.com.        3600  IN  TXT    "v=spf1 include:_spf.mailhost.example -all"
_dmarc.example.com. 3600  IN  TXT    "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
example.com.        3600  IN  CAA    0 issue "letsencrypt.org"

Each line has a name, a TTL in seconds, a class (IN, almost always), a type and the data.

A and AAAA records#

An A record maps a name to an IPv4 address. An AAAA record maps it to an IPv6 address. These are the records that point your domain at your web server, and you can publish several A records for one name to spread traffic across servers.

Only publish an AAAA record if your server actually accepts connections over IPv6. Visitors on IPv6 networks will try it, and if nothing answers, the site can seem slow or broken for them.

CNAME records#

A CNAME makes one name an alias of another. The resolver follows it and looks up the target instead.

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

CNAMEs are handy when a service gives you a hostname rather than an IP address: if the service changes its IPs, your record keeps working.

The key rule comes from RFC 1034: if a CNAME record is present at a name, no other data should be present at that name. In practice:

• You can't have a CNAME and an MX or TXT record on the same name.
• You can't put a CNAME on the bare domain (example.com), because the zone apex must have SOA and NS records.

Many DNS providers work around the second limitation with features called ALIAS, ANAME or CNAME flattening, which resolve the target behind the scenes and answer with A and AAAA records.

MX records#

MX records tell other mail servers where to deliver email for your domain. Each has a priority number, and lower numbers are tried first. In the sample zone, mail1 (priority 10) is tried before mail2 (priority 20).

An MX record should point to a hostname that has its own A or AAAA records, not directly to an IP address or to a name that's a CNAME. Hosted email services give you the exact values to enter.

NS records#

NS records list the authoritative nameservers for a domain. They matter in two places:

1. At the registrar, where you set the domain's nameservers. This creates the delegation in the parent zone, such as .com.
2. In your zone, where the same nameservers should be listed.

When you move DNS to a new provider, you change the nameservers at your registrar. If the registrar and the zone disagree, you can get inconsistent results.

TXT records#

A TXT record holds free-form text. It has become the standard place for email policies and for ownership proofs: services like Google Search Console often ask you to add a TXT record with a unique string to verify you control the domain.

SPF#

SPF lists which servers may send email for your domain. It's a TXT record starting with v=spf1, as defined in RFC 7208.

example.com.  3600  IN  TXT  "v=spf1 include:_spf.mailhost.example ip4:192.0.2.25 -all"

Here, include: authorizes the email provider's servers, ip4: authorizes one specific server, and -all says everything else should fail. ~all is a softer "softfail".

Two rules catch people out:

• Publish only one SPF record per domain. When you add a sending service, merge it into the existing record.
• SPF evaluation is limited to 10 DNS lookups. Each include, a, mx and similar term counts. Stack too many services and SPF fails with a permanent error.

DKIM#

DKIM lets receiving servers verify a cryptographic signature on your email. Your email provider gives you a public key to publish at a selector under _domainkey:

selector1._domainkey.example.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

DMARC#

DMARC tells receiving servers what to do with mail that fails SPF and DKIM alignment, and where to send reports. It's published at _dmarc, per RFC 7489. The p= policy can be none (monitor only), quarantine (treat as suspicious) or reject. A sensible approach is to start with p=none, read the reports to confirm all your legitimate senders pass, then tighten the policy.

SOA record#

Every zone has exactly one SOA (Start of Authority) record. It names the primary nameserver and a contact mailbox (written with a dot instead of @), and sets timing values: a serial number that increases when the zone changes, refresh, retry and expire timings used by secondary nameservers, and a negative caching TTL, which controls how long resolvers may cache the fact that a name doesn't exist. Managed DNS services handle the SOA for you, but that last value explains a common frustration covered below.

CAA records#

A CAA record lists which certificate authorities may issue SSL/TLS certificates for your domain, as defined in RFC 8659.

example.com.  3600  IN  CAA  0 issue "letsencrypt.org"
example.com.  3600  IN  CAA  0 issuewild ";"
example.com.  3600  IN  CAA  0 iodef "mailto:security@example.com"

This allows one certificate authority, blocks wildcard certificates, and gives an address for reporting violations.

CAA is a good safeguard that's easy to forget. If you switch certificate providers and your CAA record doesn't list the new one, issuance and renewal will fail. After any certificate change, check your site with our SSL Checker, and see SSL certificate errors for troubleshooting.

TTL: how caching really works#

Every record has a TTL (time to live) in seconds, telling resolvers how long they may cache the answer. 3600 means one hour. Long TTLs mean fewer lookups but slower changes; short TTLs mean faster changes and more queries.

A practical routine for planned changes, such as moving to a new host:

1. A day or two before, lower the TTL on the records you'll change, for example to 300 (five minutes).
2. Wait at least as long as the old TTL, so caches pick up the short one.
3. Make the change.
4. Once everything works, raise the TTL again.

Why "propagation" is a myth#

People often say DNS changes need up to 48 hours to "propagate", as if the change is pushed across the internet. Nothing is pushed. Your authoritative nameservers serve the new record immediately. What you're waiting for is resolvers letting their cached copies expire, based on the TTL they received.

That explains the delays people actually see:

• The old TTL is what matters. If a record had a 24-hour TTL, some resolvers may keep the old answer for up to 24 hours after you change it.
• Nameserver changes depend on the parent zone. Delegation records in TLD zones often have long TTLs, sometimes up to two days, which is where the "48 hours" folklore comes from.
• Negative answers are cached too. If someone looked up a record before you created it, their resolver may cache "doesn't exist" for the SOA's negative caching period.
• Browsers and operating systems add their own caching.

To see what your authoritative servers are really serving, query them directly instead of relying on your local resolver:

dig +short example.com A @ns1.dnshost.example
dig +short example.com MX
dig +short TXT _dmarc.example.com

Check your records#

To see a domain's current records in one place, use our DNS Lookup. It's useful for confirming a change went live, troubleshooting email delivery, and seeing which services another domain uses. For more on reading those clues, see how to find who owns a domain.

A quick checklist before you walk away from any DNS change: A and AAAA records point at servers that answer; there's no CNAME on the bare domain; MX records point to hostnames; you have exactly one SPF record within the lookup limit; DKIM and DMARC are published; CAA lists every certificate authority you use; and TTLs are back to normal.

DNS looks intimidating because of the syntax, but each record answers one simple question. Once you know which question each type answers, most DNS problems become straightforward to diagnose.