DNS Records Explained: A, AAAA, CNAME, MX and TXT
Nine record types cover everything you will ever need, and four of them cover almost all of it. Here is what each one does, the mistakes that break sites and mail, and why deleting the wrong line fails silently.
September 9, 20266 min readDNS · MX records · TTL
The short answer.
Apoints a name at a server.MXpoints mail somewhere else entirely.CNAMEpoints a name at another name.TXTholds proof that you own things. Those four cover most of what you will ever touch.
Your domain is a pointer, and DNS records are what it points at. Every time a site goes down after a migration, or email stops arriving while the website is fine, the cause is one line in this list.
The records you will actually use
| Record | Points at | Typical use |
|---|---|---|
A | An IPv4 address | Your website |
AAAA | An IPv6 address | Your website, modern networks |
CNAME | Another domain name | Subdomains, hosted services |
MX | A mail server, with a priority | Receiving email |
TXT | Arbitrary text | Verification, SPF, DKIM, DMARC |
NS | A nameserver | Delegating a zone |
SRV | A host and port | Chat, VoIP, some enterprise tools |
CAA | A certificate authority | Restricting who may issue TLS certs |
PTR | A name, from an IP | Reverse lookups, mail server reputation |
A and AAAA
The simplest records. A maps a name to an IPv4 address, AAAA maps it to IPv6. The name AAAA exists because an IPv6 address is four times the size of an IPv4 one.
Your host gives you the address. You paste it in.
You can have both, and you should. Publishing an
AAAAalongside yourAmeans IPv6-only clients can reach you. Publishing anAAAAthat points somewhere broken is worse than not having one, because clients that prefer IPv6 will try it first and fail.
CNAME, and its one hard rule
A CNAME points a name at another name rather than an address. Useful when a provider's IP address might change and you would rather not track it.
shop.example.com CNAME mystore.shopify.com
The rule that catches everyone: a name with a
CNAMEcannot have any other record. NoMX, noTXT, nothing. This is a protocol-level constraint, not a provider limitation.
The practical consequence is that you cannot put a CNAME on your root domain, because the root must carry NS and usually MX records. Attempting it breaks your email in a way that is genuinely confusing to debug.
Providers work around this with non-standard record types, variously called ALIAS, ANAME or "CNAME flattening". They behave like a CNAME at the root while resolving to an address behind the scenes. If your provider offers one, that is the correct tool for pointing a bare domain at a hosted platform.
MX, the one that fails silently
MX records say which servers receive mail for your domain. Each carries a priority number, and lower numbers are tried first.
| Priority | Host |
|---|---|
| 10 | mail1.provider.com |
| 20 | mail2.provider.com |
The second is a fallback used when the first is unreachable.
Three things to know:
They are completely independent of your website. Your site can be on one provider and your mail on another. Neither knows the other exists. This is why deleting the wrong record takes down your email while the homepage keeps working perfectly.
Leftovers cause the worst failures. If you switch providers and leave the old MX records in place, mail splits unpredictably between two systems. Some messages arrive, some land in an inbox nobody opens, and nothing produces an error. Delete the old records before adding the new ones.
Mail failures are silent. A broken site generates complaints within minutes. Broken mail generates nothing, because the people trying to reach you assume you are ignoring them. Setting this up properly is worth the twenty minutes.
TXT, and the three that decide whether mail arrives
TXT records hold arbitrary text, and the internet has standardised several uses.
Domain verification. A provider gives you a string, you publish it, they confirm you control the domain.
SPF lists which servers may send mail as your domain.
A domain may have exactly one
SPFrecord. Every service that sends on your behalf goes inside that single record. Publishing a second one breaks both, and it is the most common email misconfiguration there is.
DKIM publishes the public key used to sign your outgoing mail, so receivers can verify it really came from you.
DMARC tells receivers what to do when SPF or DKIM fails. Start at p=none and read the reports before tightening to quarantine or reject, or you will bounce legitimate mail from a sender you had forgotten about.
NS, the one that outranks everything
NS records delegate a zone to a set of nameservers. The ones that matter are set at your registrar, not in your zone file, because they are what the registry publishes.
Nameservers are the master switch. Change them and every other record on this page becomes irrelevant, because a completely different provider is now answering for your domain. This is why an unexpected nameserver change is the single most serious event on a domain, and why it is worth alerting on immediately. Anyone who controls your nameservers controls your website and receives your email, without ever touching your registration.
The ones you will meet occasionally
SRV advertises a service on a host and port, used by chat, VoIP and some enterprise tooling. You will paste these in when a provider asks.
CAA restricts which certificate authorities may issue TLS certificates for your domain. A genuinely useful hardening step that takes one line, and it limits the damage an attacker can do with a hijacked domain.
PTR maps an IP address back to a name. You set this at whoever owns the IP, not at your registrar. It matters mainly if you run your own mail server, where a missing PTR gets your mail rejected.
TTL, and why "propagation" is a myth
Every record carries a TTL, a time to live in seconds, saying how long resolvers may cache the answer.
When you change a record and someone tells you to wait for propagation, essentially nothing is propagating. Your nameservers updated instantly. What you are waiting for is every cached copy elsewhere to expire.
| TTL | Cached for | Use when |
|---|---|---|
| 300 | 5 minutes | Planning a change |
| 3600 | 1 hour | Reasonable default |
| 86400 | 24 hours | Stable records, fewer queries |
The migration trick. Lower the TTL to 300 at least a day before a planned change. The old TTL has to expire before the new short one takes effect, so doing it at the last minute achieves nothing. Once the move is settled, raise it again.
Nameserver changes are the exception. Those are delegated at the registry and genuinely can take longer to settle everywhere.
The five mistakes that cause real outages
1. A CNAME on the root domain. Breaks mail. Use ALIAS or ANAME instead.
2. Old MX records left in place. Mail splits between two systems with no error.
3. Two SPF records. Both fail. Merge them into one.
4. Transferring a domain without exporting the zone. DNS records do not travel with a registration. The new registrar applies its own defaults and your zone is gone. Copy everything first.
5. Editing at the wrong provider. If your nameservers point at Cloudflare, editing records at your registrar changes nothing at all. Whoever the NS records name is the only place edits take effect.
A checklist before you change anything
- Screenshot the current zone. All of it.
- Lower the TTL a day ahead if the change is planned.
- Confirm which provider is authoritative by checking the nameservers.
- Change one thing at a time.
- Test mail in both directions, not just the website.
- Raise the TTL again once it is settled.
And for anything you cannot afford to have change without your knowledge, watch the records themselves. A DNS change made by someone else looks exactly like a DNS change made by you, right up until you see what the value changed from.
Put the research to work.
Check your shortlist across the extensions that matter, then save the strongest names to a project.
Check a domain