DNS Record Types at a Glance
A DNS record is one line in a domain’s zone that tells the internet where a name should go or who is allowed to use it. The record types you will meet most are these.
- A: Points a name at an IPv4 address.
- AAAA: Points a name at an IPv6 address.
- CNAME: Makes one name an alias of another name.
- MX: Says which servers receive the domain’s mail.
- TXT: Holds text, including SPF, DKIM, and DMARC.
- NS: Names the servers that answer for the domain.
- SRV, CAA, PTR: Service locations, certificate authority limits, and reverse lookups.
What Each Record Type Actually Does
You opened the DNS editor because something is broken. Mail stopped arriving, or the new site is live everywhere except your own laptop, or a certificate refuses to issue and the error mentions a record you have never heard of. A DNS zone is a small file. Most are under thirty lines. Almost every outage that touches one comes from the same short list of mistakes, made in the same few record types.
This is a working guide to the records you will actually meet, what each one does, and the specific way each one fails. It assumes you can open your DNS editor and that nobody has ever explained why the fields are shaped the way they are. For the wider picture of how domains, nameservers, and mail authentication fit together, that is the domain and DNS side of the stack.
A and AAAA point a name at a machine
An A record maps a hostname to an IPv4 address. AAAA does the same for IPv6. That is the whole job. Everything else in the zone exists to route around the fact that addresses change and people cannot remember them.
A single name can carry several A records. Resolvers hand back the whole set and the client picks one, which gives you crude load sharing and no health checking at all. If one of those addresses is dead, roughly half your visitors see a dead site and the other half see nothing wrong. That is the shape of the whole system. DNS answers the question it was asked. It does not check whether the answer still works.
AAAA has a failure mode worth knowing about. Publish an AAAA record for a host whose IPv6 stack is not actually serving traffic, and clients with working IPv6 will try it first, fail, and only some of them will fall back to IPv4 quickly. The site is up. It is up intermittently, for a subset of people, in a pattern nobody can reproduce on demand. If you are not deliberately running IPv6, do not publish the record.
CNAME is an alias, and it has one hard rule
A CNAME points one name at another name rather than at an address. It is how you point www at a platform hostname, or a subdomain at a hosting platform that hands you a hostname rather than an address, and then let that provider change addresses underneath you without telling you.
The hard rule is old and it is absolute. A name that carries a CNAME cannot carry any other record. Not an MX, not a TXT, not an A. Resolvers treat the CNAME as the final word and stop looking.
This is why you cannot put a CNAME on the apex, meaning the bare domain with nothing in front of it. The apex has to carry the zone SOA and NS records by definition, and those are not optional, so a CNAME there conflicts with records that have to exist. Most managed DNS providers sell a workaround under a name like CNAME flattening, ALIAS, or ANAME. The provider resolves the target on your behalf and serves the resulting address as an ordinary A record, so the outside world never sees a CNAME at the apex at all.
The practical consequence catches people during email setup. If your apex sits on a real CNAME rather than a flattened one, adding MX records will either be refused by the editor or accepted and then ignored. Mail looks configured. It is not.
MX Decides Where Mail Lands
An MX record has two parts, a preference number and a hostname. Lower numbers win. A domain with MX 10 at one provider and MX 20 at another sends everything to the first, and only falls back to the second when the first stops answering.
Two rules here are not negotiable. An MX must point at a hostname and never at an IP address. And the hostname it points at has to resolve to an address directly, which makes an MX aimed at a CNAME wrong even in the cases where it appears to work.
The most common mail fault on a handover is not a missing record. It is an extra one. The old host MX is still sitting in the zone at a lower preference than the new provider, so mail keeps arriving in a mailbox nobody has opened since the migration, and everyone assumes the sender is at fault. If you are moving business mailboxes to a new provider, delete the old MX in the same edit that adds the new one rather than tidying up afterward.
TXT Carries Almost Everything Else
TXT was meant for free-form notes and became the place the internet puts anything that needs publishing against a domain name. Ownership verification for a dozen vendors, SPF, DKIM, DMARC, and a long tail of one-off tokens all live in TXT records.
One detail explains a whole category of silent failure. A single TXT string is limited to 255 characters. Longer values are published as several quoted strings that the resolver joins back together on the way out. Good DNS editors split a long value for you. Some do not, and truncate instead, which is why a 2048-bit DKIM public key pasted in as one long line sometimes validates in the vendor dashboard and fails everywhere else.
The three that matter for mail sit at specific names. SPF is a TXT record at the domain itself, and there must be exactly one of them; the detail on why a second one silently breaks the first is in the walkthrough of how an SPF record is parsed. DKIM lives at selector._domainkey.example.com, where the selector is chosen by whoever signs the mail, so a domain sending through four platforms carries four of them. DMARC lives at _dmarc.example.com. Getting these wrong rarely bounces anything. It sends mail to spam instead, which is slower to notice and much harder to prove, and it is the usual reason application mail that has to arrive stops arriving.
NS Records Decide Who Answers at All
NS records name the servers that are authoritative for the zone. There are two copies of that information and they are not the same thing. The set held at your registrar lives in the parent zone and is what the rest of the internet actually follows. The set inside your own zone is what your nameservers report when somebody asks them directly.
When the two disagree you get a fault that looks like haunting. Some resolvers follow the delegation and see the new zone, others hold the in-zone set and see the old one, and nothing is broken cleanly enough to produce an error. If you have just moved DNS providers and the answers are inconsistent, compare the delegation at the registrar against the NS records in the zone before touching anything else. This is also the layer where domain registration and renewals stop being the same account as DNS hosting, which is a distinction worth understanding before you need it at two in the morning.
SRV, CAA, and PTR, the ones you meet once
SRV records advertise a service on a host and a port. The name is structured, in the form _service._proto.example.com, and the value carries priority, weight, port, and target. Voice and chat platforms use them. You will paste one from a vendor setup page and never think about it again.
CAA records name which certificate authorities are permitted to issue for the domain. They are worth having and they are also a trap. Add a CAA record listing one authority, move a year later to a host that issues through a different one, and renewal fails with an error that does not mention DNS anywhere in it. If a certificate suddenly will not renew on a domain that has been fine for years, check for a CAA record before you check anything else.
PTR is the reverse of an A record, mapping an address back to a name. You cannot set it in your own zone. It lives in the reverse zone controlled by whoever owns the IP address, so you request it from your hosting or network provider and wait. It matters almost entirely for mail, because receiving servers check that the sending address has a PTR record and that it matches the name the sending server introduced itself with. That is one of several reasons sending outbound mail from your own infrastructure is harder than the setup guides suggest.
Where DNS Changes Go Wrong
Knowing what each record does is the easy half. The failures below are barely about record types at all. They are about caching, about editing in the wrong place, and about doing things in an order that only makes sense afterward.
TTL is a promise you made in the past
Every record carries a time to live, in seconds, telling resolvers how long they may cache the answer. When you change a record, nothing propagates. There is no wave moving across the internet. The old answer simply sits in caches until it expires, and the length of that wait was decided by the TTL that was already published before you made the change.
Which is why lowering the TTL after making a change does nothing at all for that change. If a record was sitting at 86400, some resolvers will hold the old value for a full day whatever you do next. The step that helps has to come first. Drop the TTL to 300 seconds at least one full old-TTL period before the switch, make the change, then put it back up once things have settled.
One honest caveat. Some large public resolvers enforce their own minimum and will not honor a very short TTL, and plenty of consumer routers cache more aggressively than the record asks for. Lowering the TTL narrows the window. It does not close it, and anyone who tells you a cutover will be instant is describing the best case.
The Failed Lookup Gets Cached Too
Negative answers are cached as well as positive ones, on a timer taken from the zone SOA record. If you check whether a hostname resolves before you have created it, you have just taught your resolver that the name does not exist, and it will keep saying so for the length of that negative cache even after the record is live and correct.
The practical version is short. Create the record, then check it, in that order. If you have already checked early and are now staring at a record that exists in the editor and nowhere else, query a resolver you have not already asked, or wait it out. It is almost never the record.
A Proxy Changes What the World Sees
If your DNS sits on Cloudflare and a record is proxied, the address returned to the public is Cloudflare, not you. Your A record is correct. A lookup disagrees with it. Both of those are true at the same time and neither is a fault.
It matters in three specific places. Firewall rules that expect to see your origin address will never see it, so an allow list built from a lookup is built from the wrong address. Certificate validation that reaches for the origin can fail while the site itself loads perfectly. And mail hostnames must never be proxied, because the proxy only carries HTTP and HTTPS, so proxying the host your MX points at stops mail dead. If you are deliberately routing mail through Cloudflare, that is a different arrangement with its own records and it is worth setting up on purpose rather than by trial.
Two Records Quietly Fighting Over One Name
DNS editors will happily let you add a second A record beside an existing one, or leave a CNAME sitting next to an A that somebody added later. Nothing warns you. The zone is now internally inconsistent, and the symptom is a service that works for some people, some of the time, from some networks, which is the hardest kind of fault to get anyone to believe in.
Before adding any record, list what already exists at that exact name, including whatever your editor collapses behind a tab or a filter. Most zone damage is additive. Somebody added the right record without removing the wrong one, and the wrong one is still winning half the time.
Migration Order, and the Window Nobody Plans For
A site move has a sequence and the downtime comes from skipping steps in it. Lower the TTLs on the records you are about to change. Stand the new host up and get the site fully working there while it is still not live, testing through a hosts file entry or the provider preview hostname. Only then switch the A or CNAME. Then leave the old host running for at least one old TTL, because a share of your traffic is still arriving there and will keep arriving for a while.
Two things belong outside that window. Do not move mail in the same change as the website unless you have no choice, because when something breaks you will not know which half caused it. And put the old site behind a proper holding screen rather than deleting its content, so that anyone still resolving to the old address gets an explanation instead of a broken page. If somebody else is doing the build, agree who owns the DNS cutover before the day itself, because it is the one task on a migration plan with no obvious owner.
Three Logins, Three Companies, One Zone
The registrar holds the domain and the delegation. The DNS host serves the zone. The web host serves the site. These are frequently three different companies with three different control panels, and every one of them has a screen that looks like a DNS editor.
A good share of the calls that begin with the words DNS is broken turn out to be a correct edit made in the wrong panel. The record was right. It went into a zone that nothing is delegated to, so nobody will ever read it. Before editing anything, confirm which nameservers the domain registration record currently points at, and edit only there.
When this is worth handing over, and when it is not
If your zone holds six records, one website, and one mail provider, and it changes twice a year, keep doing it yourself. A managed service is not worth paying for at that size and anybody who tells you otherwise is selling. Read the TTL section again, write down which company holds your delegation, and you have covered most of the real risk.
It becomes worth handing over at a different point. When there are enough hostnames that nobody can list them from memory. When mail authentication has to keep working while a marketing platform, a helpdesk, and an application all send on your behalf. When a change needs to happen on a Friday afternoon and nobody in the room wants to be the person who makes it. That is the point where handing the zone to a team that answers for it starts to pay, and the part that matters is not the records. It is that changes are unlimited and included, so nobody puts off a fifteen-minute edit because it might arrive with an invoice attached.
