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

Updated 27 September 2026 · 6 min read

DNS turns a name like example.com into the addresses and settings that make websites and email work. Each domain has a zone made up of records, and most "the site is down after the move" or "our emails are bouncing" problems come down to one wrong or stale record. Here is what each type does, with realistic examples.

The examples use example.com and the documentation-only addresses 203.0.113.x and 2001:db8::.

How a lookup works, briefly

Your device asks a recursive resolver: your provider's, or a public one such as Cloudflare's 1.1.1.1 or Google's 8.8.8.8. If it doesn't have the answer cached, it asks the root servers, then the servers for the top-level domain (.com, .ae), then the domain's own authoritative nameservers. The answer is then cached for the record's TTL, which explains most confusion around DNS changes.

The common record types

A and AAAA are what browsers use to find a web server. A name can have several of each, and devices with IPv6 often prefer AAAA.

CNAME says "look up this other name instead". A common Microsoft 365 example is autodiscover.example.com pointing to autodiscover.outlook.com. A name with a CNAME can't hold any other records, so you can't put an ordinary CNAME on the bare domain (the apex), which also needs NS, SOA and usually MX. Some DNS hosts offer a workaround; Cloudflare calls theirs CNAME flattening.

MX records have a priority number: lower is preferred; higher numbers are backups. An MX must point to a hostname, never to an IP address, and it should not point to a CNAME.

TXT records mostly handle email authentication (below) or prove ownership to a service, such as MS=ms12345678 for Microsoft 365 or google-site-verification=... for Google.

NS records, set at your registrar, decide which provider's zone is live. The SOA record's last value sets how long "name doesn't exist" answers are cached.

You will also meet CAA (which certificate authorities may issue certificates, such as 0 issue "letsencrypt.org"), PTR (reverse lookup from IP to name, set by whoever owns the IP block) and SRV (host and port for a specific service).

TTL and the "propagation" myth

TTL (time to live) is in seconds: 300 is five minutes, 3600 is an hour, 86400 is a day. DNS changes don't travel outward across the internet. Your DNS host updates its authoritative servers almost immediately; what takes time is caching. Any resolver that already fetched the old answer keeps serving it until its TTL expires, so a record with a TTL of 3600 is updated everywhere within about an hour.

The "allow 24 to 48 hours" warning mainly applies to nameserver changes, because the NS records held by the top-level domain are often cached for a day or two.

Before a planned migration:

1. Lower the TTL of the records you will change to 300.
2. Wait at least as long as the old TTL, so caches pick up the short value.
3. Make the change. Most users switch within five minutes.
4. Raise the TTL again once everything is confirmed working.

Your own computer caches too. On Windows run ipconfig /flushdns; on macOS run sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. Browsers also keep a short cache of their own.

Email records: SPF, DKIM and DMARC

All three are TXT records, although DKIM is sometimes a CNAME pointing to your provider's TXT record.

SPF lists the servers allowed to send mail for your domain. The record Microsoft 365 publishes in its DNS reference is v=spf1 include:spf.protection.outlook.com -all. Two rules from RFC 7208 catch people out: a name may have only one SPF record (two gives a permanent error), and evaluation may trigger at most 10 DNS lookups (each include, a, mx, ptr, exists and redirect counts). To add a sender, merge it in; during a move from Google Workspace to Microsoft 365, for example: v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all.

DKIM signs each message with a key, published at selector._domainkey.example.com as v=DKIM1; k=rsa; p=MIIBIjANBg.... Microsoft 365 instead uses two CNAMEs, selector1 and selector2, pointing to keys Microsoft hosts; you then switch DKIM signing on in its security portal.

DMARC tells receivers what to do with mail that shows your domain in the From address but doesn't pass SPF or DKIM for that domain, and where to send reports. It sits at _dmarc.example.com, for example v=DMARC1; p=none; rua=mailto:[email protected]. Start with p=none, read the reports for a few weeks, then move to quarantine and reject. DMARC was updated in May 2026 as RFC 9989, which replaces RFC 7489 and drops the pct tag, so don't rely on pct for a gradual rollout.

Troubleshooting two common problems

Website not loading after moving host

1. Look up both A and AAAA. A classic fault is a new A record with an old AAAA still pointing at the previous server, so IPv6 users land on the old site.
2. Check the NS records. If they point to Cloudflare but you edited the zone at your registrar, nothing you changed is live.
3. Check www separately; it is often its own record and gets forgotten.
4. Compare dig @1.1.1.1 example.com A +short with dig @8.8.8.8 example.com A +short. Different answers usually mean one is still caching the old value.

Email not arriving

1. Check that the MX records point only to your current provider. An old MX with a lower number sends mail to the old system.
2. Make sure there is exactly one TXT record starting v=spf1, and count its lookups.
3. If DMARC is at p=reject, mail from a new service (newsletter, CRM, website form) that isn't in SPF and doesn't sign with DKIM will be rejected.
4. If you run your own mail server, ask whoever provides its IP to set a matching PTR record.

On Windows, nslookup -type=mx example.com or Resolve-DnsName example.com -Type MX does the same job as dig example.com MX +short.

Look up records with our DNS Lookup

The DNS Lookup queries A, AAAA, CNAME, MX, NS, TXT and SOA records through Cloudflare's DNS-over-HTTPS service and shows the TTL for each answer. Choose "All common records" to see everything at once. You can paste a full link and it picks out the domain; Arabic and other international domain names work too.

Because it asks Cloudflare's public resolver, you see what that resolver currently holds, cached answers included. Right after a change, ask your authoritative server directly: dig @ns1.your-dns-host.com example.com A. The tool doesn't look up PTR, CAA or SRV records.

Frequently asked questions

How long does a DNS change take?

For normal records, up to the old TTL, often an hour or less. Nameserver changes can take a day or two.

Can I have two SPF records?

No. Two records make SPF fail with a permanent error. Merge every sender into one v=spf1 record.

Why does my site work on Wi-Fi but not on mobile data?

The two connections use different resolvers and caches, and mobile networks often use IPv6. Check the AAAA record as well as the A record.

Does a small business need DMARC?

Yes. Gmail and other big mailbox providers expect it from bulk senders, and it helps stop others sending mail in your name.