Every time someone types a domain into a browser, sends an email or connects an app to an API, DNS answers the question "where does this actually go?". The answers live in DNS records: small, plain-text instructions attached to a domain. When they are right, nobody thinks about them. When one is wrong, the website vanishes, email stops arriving or visitors end up somewhere they should not be.
This guide explains what DNS records are, what each common record type does, and the handful of details (TTLs, propagation, apex restrictions) that cause most real-world problems.
What a DNS record actually is
The Domain Name System is a distributed directory that maps human-friendly names to machine-friendly destinations. A DNS record is one entry in that directory. Each record has four parts:
- Name: the domain or subdomain it applies to, such as
example.comorshop.example.com. - Type: what kind of answer this is (A, MX, TXT and so on).
- Value: the answer itself, an IP address, another hostname, or a block of text.
- TTL: time to live, how many seconds resolvers may cache the answer before asking again.
Records are published by whoever runs the domain's authoritative nameservers, usually the registrar, a DNS host like Cloudflare or Route 53, or the hosting company. Everyone else (your ISP, Google's 8.8.8.8, the resolver in your office router) just caches copies.
The record types you will actually meet
A and AAAA: the address records
An A record maps a name to an IPv4 address, for example example.com → 203.0.113.10. An AAAA record does the same for IPv6. These are the records that put a website on the map: when the A record points at the wrong server, the domain is up but the site is gone.
CNAME: the alias
A CNAME record says "this name is an alias for that name": www.example.com → example.com, or shop.example.com → shops.myplatform.com. The resolver then looks up the target instead. Two rules trip people up: a name with a CNAME cannot hold any other record type, and you cannot put a standard CNAME on the bare domain (the apex) because it must carry NS and SOA records. DNS providers work around the apex restriction with flattened records or ALIAS/ANAME types.
MX: where email is delivered
An MX record tells the world which mail servers accept email for the domain, with a priority number so senders know which to try first. Websites do not need MX records; businesses do. A deleted or mistyped MX record does not bounce mail loudly, it often just sends it into a void, which is why MX changes deserve close watching.
TXT: free text with serious jobs
A TXT record holds arbitrary text, and three of its jobs matter enormously:
- SPF lists which servers may send email as the domain.
- DKIM publishes the public key that lets receivers verify a message was really signed by the domain.
- DMARC tells receivers what to do when SPF or DKIM fail, and where to send reports.
Break any of these and email deliverability quietly degrades: messages still send, they just start landing in spam. You can check a domain's SPF, DKIM and DMARC setup in seconds with our free email deliverability checker. TXT records are also used for one-off domain verification by Google, Microsoft and most SaaS tools, which is why old domains accumulate a museum of them.
NS: who answers for this domain
An NS record names the authoritative nameservers for the domain. Change the NS records and you change who publishes every other record. This makes them both powerful and dangerous: an unexpected NS change is one of the strongest signals of a domain hijack, and a botched NS migration takes everything down at once, site, mail, the lot.
SOA: the domain's administrative header
The SOA record (start of authority) holds housekeeping data about the zone: the primary nameserver, an admin contact and a serial number that increments on every change. You will rarely edit it by hand, but its serial number is useful evidence when you need to prove that a zone changed and when.
CAA: who may issue certificates
A CAA record restricts which certificate authorities are allowed to issue SSL certificates for the domain. Good security hygiene, with one classic side effect: a CAA record left over from an old setup silently blocks Let's Encrypt renewals, and the first symptom is an expired certificate nobody can explain.
SRV and PTR: the specialists
An SRV record advertises the host and port for a specific service, still used by things like SIP/VoIP and some chat and directory systems. A PTR record is the reverse of an A record, mapping an IP address back to a name; it lives with whoever controls the IP block, and mail servers without a matching PTR record get treated with suspicion.
TTLs and propagation: why changes feel slow
When you edit a record, nothing pushes the change to the world's resolvers. They simply keep serving their cached copy until its TTL runs out, then fetch the new answer. That staggered expiry is what people call propagation. With a 3600-second TTL, some visitors see the new value immediately and others up to an hour later, and longer TTLs stretch that window further.
Practical rule: before a planned change, drop the TTL to 300 seconds a day in advance, make the change, confirm it, then raise the TTL again. If a change is mid-flight and you want to see what resolvers around the world currently answer, use our free DNS propagation checker.
The mistakes that cause real outages
- Editing the wrong record. Apex versus
www, or a stale duplicate record shadowing the one you changed. - Deleting a TXT record that looked like clutter and turned out to be the SPF record.
- Moving hosting without moving DNS knowledge. The new host's instructions say "point your A record here" and nobody carries over the MX and TXT records, so the site moves and email dies.
- Nameserver changes with incomplete zone copies. The new provider only gets the records someone remembered.
- Unnoticed third-party edits. A client's IT contractor, a hosting support agent or an automated integration edits a record and tells no one.
The common thread: DNS changes are silent, and the symptoms show up somewhere else entirely, a down site, missing email, a certificate that will not renew. That is why keeping a baseline of every record and alerting on changes, which is what DNS monitoring does, catches this whole class of problem at the cause instead of the symptom. If you look after client domains, DNS watching is layer three of the nine checks in our complete guide to monitoring client websites, and one more example of why an uptime check alone tells you so little.
