The DNS records a domain needs, and what each one actually does

A domain's DNS mostly comes down to five kinds of record. TXT holds SPF, DKIM and verification strings. MX routes mail. CNAME aliases one name to another, everywhere except the zone's own root. CAA says which certificate authorities may issue for the domain, and having none published is itself a choice, just not a restrictive one. NS and SOA are the pair every zone carries, handling delegation and the timers a secondary nameserver runs on. Underneath all of them, a record's TTL decides how long a resolver can keep answering with an old value after you change anything.

Cloudflare's and Wikipedia's own glossary pages already define each of these types well, and this guide does not try to out-write them as plain definitions. What follows pairs each explanation with a live tool: a checker that reads a domain's actual records, or a generator that writes the exact values a mail or hosting provider documents today. Read the explanation, then check it against a real domain.

What is a TXT record, and why does it carry SPF, DKIM, domain verification and more?Copy Anchor Link

A TXT record is a slot for free-form text. RFC 1035 §3.3 defines it as one or more character-strings concatenated together, and DNS itself does not interpret what is inside - that is entirely up to whatever program goes looking for it.

That lack of built-in meaning is exactly why TXT ended up carrying so much. SPF needed somewhere to publish which servers may send mail for a domain. DKIM needed somewhere to publish a public signing key. Domain-verification schemes - a hosting platform, a search console, an analytics tool - each needed somewhere to publish a one-time token proving control of the domain. None of these needed a new record type invented for it; each just published a TXT value starting with its own prefix (v=spf1, v=DKIM1, or a provider's own string) so a reader can tell at a glance which scheme a given TXT value belongs to.

The one hard limit on a TXT record is RFC 1035 §3.3's character-string length: at most 255 bytes per string, with the record allowed to carry several strings concatenated together for anything longer. A 2048-bit DKIM key or a long SPF record with several includes routinely runs past 255 bytes, which is why it has to be split into more than one string to be published at all - and why splitting on characters instead of bytes, or forgetting to escape a literal quote, is the most common way to publish one wrong.

• DNS record type explainer - plain-word definitions for all nine everyday record types, each with a live lookup for any domain you type in.
• TXT record splitter - paste a long SPF or DKIM value and get it split into properly quoted, correctly escaped 255-byte strings.

If your TXT records specifically are SPF, DKIM and DMARC for cold email or mailbox licensing, our email authentication report reads all three for a domain in one pass.

What is an MX record, and what has to go with it?Copy Anchor Link

An MX record names which server accepts mail for a domain, and in what order. RFC 1035 pairs a hostname with a numeric priority, and a sending server tries the lowest number first, moving to the next only if that host refuses the connection. A domain with no MX record published is not meant to receive mail by SMTP at all.

MX alone gets mail routed; it does not get it authenticated. Every mailbox provider below documents a fixed SPF value that has to sit alongside MX, and some add more:

Two things worth noticing in that table. First, Zoho's three MX records are not a backup to add later - all three are how it routes around a busy or unreachable primary server, so a domain missing the second and third loses that fallback from the start. Second, every provider warns against publishing a second SPF TXT record: a domain is allowed only one, and a new provider's include has to be merged into the existing record as another term, not published alongside it.

• Google Workspace DNS generator, Microsoft 365 DNS generator, Zoho Mail DNS generator, Fastmail DNS generator - the fixed records above, ready to copy, for the domain you're setting up.

If you're deciding which suite to resell rather than which records to publish, Google Workspace vs Microsoft 365 for resellers compares the two programmes directly.

What is a CNAME record, and why can't it sit at a domain's own root?Copy Anchor Link

A CNAME record makes one name an alias for another. RFC 1035 has a resolver treat a query for the alias as a query for whatever it points at instead, following the chain until it lands on a name with a real record to answer - a CDN, a hosted app platform, or any host someone else runs, without you having to track that host's own address every time it changes.

The one rule that trips people up is the apex rule: a CNAME cannot sit at a zone's own root. RFC 1034 §3.6.2 says a name carrying a CNAME record can carry no other record at that same name, and a zone's apex already needs an SOA record and at least one NS record there - so a CNAME at the root would have to coexist with records the protocol requires, which it cannot. Most DNS hosts simply refuse to save one. This is the entire reason www.example.com is routinely set up as a CNAME while example.com itself never is.

It is also the entire reason every website platform below hands you an A record for the bare domain and a CNAME for www, rather than a CNAME for both - and why some offer an ALIAS or ANAME record as a panel-level workaround: a feature the provider built on top of a real A record, that behaves like a CNAME from the outside while technically publishing an address underneath it.

A chain is also a cost, not just a convenience. Each hop a CNAME points through is one more lookup a resolver has to make before it gets an answer, and a chain that ends in a name with no record at all - a dangling CNAME - resolves to nothing rather than failing loudly at the point where it actually breaks.

• CNAME chain follower - follows a CNAME through every hop to where it finally resolves, so a long or broken chain is visible rather than inferred.
• Apex CNAME checker - checks whether a domain's own root is trying to do something a CNAME there cannot.
• Shopify DNS generator, GitHub Pages DNS generator, Squarespace DNS generator, Netlify DNS generator - the exact apex and www records each platform documents, for the domain you're connecting.

What is a CAA record, and what does having none actually permit?Copy Anchor Link

A CAA record names which certificate authorities are allowed to issue a certificate for a domain at all. RFC 8659 defines three tags: issue for ordinary certificates, issuewild for wildcards, and iodef for where a CA should report a request it had to refuse. Every public certificate authority checks for a CAA record before issuing anything, which makes this the one record that decides who is allowed to get a certificate for a domain, not just who happens to have one today.

The detail that catches people out is what "no CAA record" means. It is not an error state and it is not "nothing has been decided yet." Per RFC 8659 and Let's Encrypt's own CAA documentation, a domain that publishes no CAA record at all has made no restriction - any publicly trusted certificate authority may issue for it, which is simply the default the web has run on since before CAA existed. Publishing a CAA record is what narrows that down, and the record that actually causes trouble is a narrow one: naming only the CA in use today, so that a later move to a different host or CDN - which often means a different CA issuing the renewal - gets refused outright rather than slowly, because the new CA was never named.

• CAA checker - reads a domain's CAA records (climbing to the nearest parent that has one, per RFC 8659 §3, when the domain itself has none) and tells you plainly whether that is a restriction or the open default.
• CAA generator - builds a correctly formatted CAA record for the certificate authorities you actually use.

What are NS and SOA records, and what do the SOA's timers actually control?Copy Anchor Link

An NS record names one of the nameservers authoritative for a zone. RFC 9499 calls the mechanism delegation: a parent zone publishes NS records pointing at a child zone's nameservers, and the child repeats the same names at its own apex. Resolving any other record for a domain starts here - a resolver follows a name's NS records first to find out which servers to even ask about everything else. RFC 2182 covers the operational side: why a zone should run more than one nameserver, and where those servers should sit relative to each other, so that one outage does not take the whole zone offline.

An SOA record marks a zone's own apex and carries a primary nameserver, an admin mailbox, a serial number, and four timers most people never read. Those four timers are what a secondary nameserver uses to decide when to recheck the primary and how long to keep answering if it cannot:

RFC 1035 §3.3.13 defines all seven SOA fields, but not all of them still mean what it says: minimum's own entry there described it as a floor under every record's TTL in the zone, a meaning RFC 2308 §4 deprecated outright and redefined to the negative-caching TTL in the table above - the other three timers kept their original RFC 1035 meaning. The serial number that precedes them is not just a version counter to glance at - RFC 1982 defines the arithmetic a secondary uses to tell whether a new serial is actually newer, since the number wraps around rather than counting forever, and a secondary compares serials with that wraparound in mind rather than by simple greater-than.

A zone that nobody has touched in years usually has nothing wrong with any of these timers; they just sit unread until a migration or an edit makes them matter. Editing a zone without the serial actually changing afterwards is the most common way they bite: a secondary that already cached the old serial has no reason to recheck until its own refresh timer forces it, which can be hours away.

• Nameserver and DNS host checker - compares what the registry has on file against what the zone itself answers for NS, and flags a delegation that is only half finished.
• SOA record checker - reads a zone's SOA record as seven plain-English values and flags a timer that will cause real trouble, like a retry longer than its own refresh.

What does a TTL actually control?Copy Anchor Link

A TTL - time to live - is the number of seconds a resolver is allowed to keep answering with a record's current value before it has to ask again. It sits on every record, not just one type, and it is set by whoever manages the zone.

This is why "did my DNS change take effect?" is almost always the wrong question. The record was very likely saved correctly the moment you clicked save. What takes time is every resolver that had already cached the old value letting that cache expire on its own TTL, which is counted from when each resolver fetched the record, not from when you changed it. A resolver with a one-hour TTL cached five minutes before your change can correctly keep serving the old value for most of the next hour - that is caching working exactly as designed, not a failure to propagate. The real question is "has the old TTL expired yet," and the answer to that is visible, not something to guess at by refreshing a page.

• DNS change verifier - enter the value you just set, and get a plain pass, partial, or fail from two public resolvers compared against that exact value.
• DNS propagation checker - see any record type and its TTL from two resolvers side by side, so a change that has reached one but not the other is something you can see rather than something you have to guess at.

Where this leaves a domain's DNSCopy Anchor Link

Five record types cover almost everything a domain needs to publish: TXT for anything machine-readable that doesn't need its own type, MX to route mail, CNAME for anything aliased except the root, CAA to say who may issue certificates, and the NS/SOA pair underneath all of it. TTL decides how quickly any change to any of them actually shows up everywhere. Every claim above has a checker next to it for a reason - a domain's own records are the only authority on what that domain is actually publishing right now, not a glossary page, including this one.