# DNS records explained: A, AAAA, CNAME, MX, TXT and the rest
> A and AAAA map a name to an IP, CNAME aliases one name to another, MX routes email, TXT carries SPF, DKIM, DMARC and verification, NS delegates the zone. A CNAME cannot coexist with other records, which is why the apex needs an A record or a provider ALIAS.
Source: https://rankcert.com/blog/dns-records-explained
Published: 2026-08-29 ยท Updated: 2026-08-29
---
DNS is the layer that turns a name into an address, and the layer people touch once a year and then have to relearn from scratch. Here is every record type you will actually encounter.
## The record types
### A and AAAA
Map a hostname to an IP address. `A` for IPv4, `AAAA` for IPv6. These are the terminal records - everything else eventually resolves to one of them.
```
example.com. 300 IN A 93.184.215.14
example.com. 300 IN AAAA 2606:2800:21f:cb07:6820:80da:af6b:8b2c
```
### CNAME
An alias. It says "this name is really that name - go look that up instead". Used for pointing `www` at your apex, or a subdomain at a hosting provider's hostname.
Two rules people break constantly:
- **A CNAME cannot coexist with other records at the same name.** That is why you cannot put a CNAME at the apex: the apex must carry NS and SOA records, and a CNAME forbids siblings.
- **CNAMEs cost an extra lookup.** A chain of three CNAMEs is three round trips before the browser gets an address.
For the apex, use an A record, or your provider's ALIAS/ANAME record, which is a proprietary flattening that resolves the target and serves an A record in its place.
### MX
Where email for this domain goes. Multiple records with priority numbers; lower is preferred.
```
example.com. 3600 IN MX 10 inbound-a.mail-provider.com.
example.com. 3600 IN MX 20 inbound-b.mail-provider.com.
```
An MX record must point at a hostname, never an IP address, and never at a CNAME.
### TXT
Free-form text, which in practice means verification and email authentication:
- **SPF** - `v=spf1 include:_spf.provider.com ~all`. Lists who may send mail as you. Exactly one SPF record per domain; two is a permanent error that breaks delivery.
- **DKIM** - a public key at a selector subdomain, used to verify message signatures.
- **DMARC** - `v=DMARC1; p=none; rua=mailto:...` at `_dmarc.yourdomain.com`. Tells receivers what to do when SPF and DKIM fail.
- **Domain verification** - Google, Microsoft and most SaaS vendors verify ownership with a TXT record.
If your email lands in spam, these three are the first place to look, in that order.
### NS
Which nameservers are authoritative for the zone. Set at your registrar, and the reason a DNS change at the wrong provider does nothing - you edited a zone nobody is asking.
### SOA
Start of authority: the primary nameserver, the administrator's email, and the timers governing zone transfers. You will almost never edit it.
### CAA
Which certificate authorities may issue certificates for your domain. Optional, cheap, and a real defence against mis-issuance.
Free tool: [DNS Lookup](https://rankcert.com/tools/dns-lookup) - Query every common DNS record type for any domain at once, with TTLs, resolved through Cloudflare's public DNS-over-HTTPS resolver.
## TTL, and the only time it matters
TTL is how many seconds resolvers may cache a record. The value only matters around changes.
The pattern for any migration:
1. **A day before:** lower the TTL on the records you will change to 300.
2. **Wait for the old TTL to expire.** If it was 86400, that is a full day. This is the step people skip.
3. **Make the change.** Most resolvers pick it up within five minutes.
4. **A day after:** raise it back to 3600 or higher.
Skip step one and your change takes as long to propagate as the old TTL, with no way to speed it up. "DNS propagation" is not a mysterious global process - it is other people's caches expiring on the schedule you set.
## Debugging in order
When something does not resolve:
1. **Check the NS records at the registrar.** If they point at a provider you are not editing, nothing else matters.
2. **Query a public resolver directly** rather than trusting your machine's cache.
3. **Check for a conflicting CNAME.** A CNAME plus any other record at the same name is invalid, and providers handle the conflict differently.
4. **Check the TTL** of the old record to know how long you are waiting.
5. **Check for a trailing dot.** `example.com` and `example.com.` in a record value mean different things in most zone editors - without the dot, the zone name gets appended, producing `example.com.example.com`.
The most common DNS outage is not a wrong record. It is nameservers still pointing at an old provider after a migration, so every edit is being made to a zone nobody queries.