DNS Record Types Explained: A, AAAA, CNAME, MX, TXT, CAA, SRV, NS, and SOA, and Why Your Bare Domain Can't Be a CNAME

Connect a new domain to a website builder such as Shopify or Squarespace, and the setup page asks for two different kinds of record. The www (short for World Wide Web) version of your address gets a CNAME (canonical name) record that points at a name belonging to the builder, while the bare domain, the version with nothing in front of it, gets an A (address) record holding a fixed numeric address. Try to give the bare domain a CNAME as well, and many DNS (Domain Name System) providers refuse outright. The reason traces back to a rule written in 1987, and it makes sense once you know what each common record type does and what real ones look like.

DNS is the internet's directory. Computers find each other by IP (Internet Protocol) address, numbers like 104.20.23.154, and DNS lets people use names like example.com instead. Each domain's information lives in a zone, a small database of entries called records, held on the domain's authoritative nameservers, the servers with the final say about that domain. When you type a name into a browser, your device asks a resolver, a server that looks names up on your behalf. Your internet provider usually runs one, public services such as Cloudflare's 1.1.1.1 and Google's 8.8.8.8 offer others, and some people run their own at home, as our guide to home lab IP addressing describes. The resolver asks the authoritative nameservers, remembers the answer for a while, and hands it back. DNS dates to 1983, when it was designed to replace a single text file that one office in California maintained and everyone else downloaded, and its basic shape has changed remarkably little since.

Every record has the same four parts: a name, a type, a TTL (time to live), and a value. A command called dig (short for domain information groper), built into macOS and Linux, prints them on one line, and here are the two address records for example.com, a domain set aside for use in examples, as its authoritative nameserver returned them to IPCraft's server in Ashburn, Virginia.

The anatomy of a DNS record

example.com.     300     IN      A       104.20.23.154
example.com.     300     IN      A       172.66.147.243
name             TTL     class   type    value

The name ends in a period because DNS names technically end at the root, the unnamed top of the whole system, and tools print that final dot even though people never type it. IN stands for internet, the only class anyone uses today. The type says what kind of information the record holds, the value is the information itself, and a name can hold several records of the same type, as example.com does here with two addresses, so visitors can reach either one. Windows users can run the same lookups with the built-in nslookup command, and our free DNS lookup tool does it in a browser, asking Cloudflare, Google, and Quad9 at once and showing whether their answers agree.

The TTL is the number of seconds a resolver may remember the record before asking again, so example.com's 300 means five minutes. Asking several resolvers at the same moment shows the countdown at work. Within a few seconds of each other, Google's resolver answered with a TTL of 300, Quad9's with 144, Cloudflare's with 84, and the resolver run by IPCraft's hosting company with 21, each reporting the seconds left on its own cached copy, and Google's full 300 suggests it had just fetched a fresh one. That countdown is what people call DNS propagation: each resolver keeps serving its remembered copy until the TTL runs out and then fetches the new one, so a change to a record with a one-day TTL can take a full day to reach everyone. Our playbook for renumbering a network without downtime explains how to lower TTLs a week before a planned change, our free DNS propagation tool shows what several public resolvers currently hold, and our guide to anycast explains why even the sites of a single public resolver can disagree for a few minutes.

The A record is the one most people mean when they talk about DNS. It connects a name to an IPv4 (Internet Protocol version 4) address, the familiar four numbers separated by dots, and it's what sends your browser to the right server. The AAAA record, pronounced “quad-A,” does the same for IPv6 (Internet Protocol version 6) addresses, which are four times as long, hence the four A's. The example.com zone publishes two of each, including 2606:4700:10::ac42:93f3, and a device with a working IPv6 connection generally tries the AAAA answers first. Both types hold only addresses, never names, and when one points somewhere wrong, the website stops loading and someone notices within minutes, which is why, as our guide to keeping DNS in sync with your IP inventory points out, address records tend to stay accurate while other records quietly drift. Our guide to IPv6 address planning explains where those long addresses come from.

A CNAME record makes one name an alias for another. Its value is a different name, the canonical, or official, one, and a resolver that finds a CNAME starts over with the new name, repeating until it reaches actual addresses. Large companies sometimes chain several aliases together, and asking for www.microsoft.com from IPCraft's server returned two hops before reaching an address.

Following a CNAME chain (TTLs trimmed)

www.microsoft.com.                    CNAME   www.microsoft.com-c-3.edgekey.net.
www.microsoft.com-c-3.edgekey.net.    CNAME   e13678.dscb.akamaiedge.net.
e13678.dscb.akamaiedge.net.           A       23.35.30.73

Both edgekey.net and akamaiedge.net belong to Akamai, a CDN (content delivery network, a company that keeps copies of websites on servers around the world), so the alias hands the choice of server to Akamai, which can change the final address from minute to minute and city to city without Microsoft touching its own records. That flexibility is the main appeal of a CNAME: the owner of the target can move things around and every alias follows automatically, which is why website builders, email marketing services, and cloud platforms ask customers to create CNAMEs pointing at names the platform controls. Our DNS lookup tool shows each hop of a chain like this one, and the address at the end is what your browser actually connects to. CNAMEs also come with one strict rule, which explains the website-builder puzzle and gets its own discussion near the end of this guide.

An MX (mail exchanger) record says which servers accept email for a domain. Each MX record holds a priority number and a server name, and sending servers try the lowest number first, falling back to higher numbers when the first choice doesn't respond. Gmail publishes five of them.

Gmail's mail servers, in the order senders try them

gmail.com.    MX     5   gmail-smtp-in.l.google.com.
gmail.com.    MX    10   alt1.gmail-smtp-in.l.google.com.
gmail.com.    MX    20   alt2.gmail-smtp-in.l.google.com.
gmail.com.    MX    30   alt3.gmail-smtp-in.l.google.com.
gmail.com.    MX    40   alt4.gmail-smtp-in.l.google.com.
name          type  priority  mail server

An MX record must name a server rather than give an address, and that server name needs A or AAAA records of its own. The rules also forbid pointing an MX record at a CNAME, although some mail software tolerates it. A domain that should never receive mail can say so with a null MX, a single record with priority 0 and a lone period where the server name would go, which is exactly what example.com publishes, so a sending server gives up at once instead of retrying for days. MX records steer only incoming mail, and the records that protect a domain's outgoing mail from forgers live in a different type, covered next.

A TXT (text) record holds free-form text, and over the decades it became the place to publish anything that lacked a record type of its own. Most TXT records today fall into two groups. The first is email security: an SPF (Sender Policy Framework) record lists the servers allowed to send mail for a domain, a DKIM (DomainKeys Identified Mail) record publishes the key that lets receivers check a message's digital signature, and a DMARC (Domain-based Message Authentication, Reporting, and Conformance) record tells receivers what to do with mail that fails those checks. The second is proof of ownership, since services such as Google, Microsoft, and certificate companies confirm that you control a domain by asking you to add a TXT record containing a random string and then checking for it.

example.com's text records

example.com.          TXT   "v=spf1 -all"
example.com.          TXT   "_k2n1y4vw3qtb4skdx9e7dxt97qrmmq9"
_dmarc.example.com.   TXT   "v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s"

The example.com records show both groups. Its SPF record, v=spf1 -all, lists no permitted senders and ends with -all, which means “reject everything,” the random-looking string has the shape of a typical verification code, and its DMARC record tells receivers to reject any message that fails the checks. Together with the null MX, those records announce that example.com neither sends nor receives email, which tells receiving servers to throw away any message forged in its name. DMARC and DKIM records sit on names that begin with an underscore, such as _dmarc.example.com, or a DKIM name like selector._domainkey.example.com, and because hostnames can't contain underscores, as our guide to naming conventions notes, these special names can never collide with a real machine. Our free SPF checker and DMARC checker read and grade these records for any domain.

A CAA (Certification Authority Authorization) record controls who may issue security certificates for a domain. Certificates put the padlock beside a web address and make HTTPS (Hypertext Transfer Protocol Secure), the encrypted version of the web, possible, and the companies that issue them are called certificate authorities, or CAs. Since September 2017, every publicly trusted CA has had to check a domain's CAA records before issuing a certificate and refuse if the domain doesn't list it. Google's record names only Google's own certificate authority, and GitHub's lists several.

Two companies' certificate rules

google.com.   CAA   0 issue "pki.goog"

github.com.   CAA   0 issue "digicert.com"
github.com.   CAA   0 issue "globalsign.com"
github.com.   CAA   0 issue "letsencrypt.org"
github.com.   CAA   0 issue "sectigo.com"
github.com.   CAA   0 issuewild "digicert.com"
github.com.   CAA   0 issuewild "letsencrypt.org"
github.com.   CAA   0 issuewild "sectigo.com"

The leading 0 is a flags field that almost everyone leaves at zero. The issue tag lists the CAs allowed to issue ordinary certificates, and issuewild lists those allowed to issue wildcard certificates, which cover every name under a domain at once. A domain with no CAA records at all, like example.com when we checked, lets any CA issue a certificate for it, so adding a record that names the CA you actually use is a cheap way to make a mistaken or fraudulent certificate harder to obtain. Our free SSL checker (SSL, or Secure Sockets Layer, is the older name for the encryption behind HTTPS) shows which CA issued a site's current certificate, a good starting point for writing the record.

An SRV (service) record tells software where to find a particular service, including the port, the numbered door on a server that a service listens behind. Its name follows a fixed pattern of the service, then the protocol it runs over, each with a leading underscore, then the domain. Its value holds four parts: a priority, a weight for sharing traffic among servers of equal priority, the port, and the server's name. Gmail publishes one that tells email apps where to collect messages.

A service record

_imaps._tcp.gmail.com.    SRV    5          0        993     imap.gmail.com.
service.protocol.domain          priority   weight   port    server

That record says that secure IMAP (Internet Message Access Protocol), the standard way email apps download messages, runs over TCP (Transmission Control Protocol) on imap.gmail.com at port 993, which lets an email app configure itself from nothing more than an email address. Internet phone systems, chat services, Minecraft game servers, and Microsoft's Active Directory (the system many offices use to manage logins) all rely on SRV records. Kubernetes, a popular system for running applications across many machines, creates them automatically for the services it runs, and our guide to IP planning for Kubernetes covers the addresses behind those services. Web browsers ignore SRV records, though, so they can't send website visitors to an unusual port.

NS (name server) records say which servers are authoritative for a zone, and they're how the whole system finds anything at all. The servers for .com, a TLD (top-level domain), hold NS records saying which nameservers answer for example.com, and resolvers follow that pointer, a handoff called delegation. Those NS records, and the matching ones in the example.com zone itself, name two servers run by Cloudflare.

example.com's nameservers

example.com.     86400     NS     elliott.ns.cloudflare.com.
example.com.     86400     NS     hera.ns.cloudflare.com.

NS records live in two places: in the parent zone, where you set them through your registrar, the company you bought the domain from, and in your own zone, and the two sets should match. Changing them moves your entire DNS to a different provider, and their TTL of 86,400 seconds, a full day, is one reason such a move takes a while to settle. Registries generally require at least two nameservers per domain so the domain keeps working when one fails, and our free whois tool shows the nameservers listed for any domain at its registry.

Every zone has exactly one SOA (start of authority) record, at its top, and it holds administrative settings for the zone itself. The one for example.com packs seven values into one line, shown here one value per row.

example.com's SOA record, decoded

example.com.   1800   SOA
  elliott.ns.cloudflare.com.   primary nameserver
  dns.cloudflare.com.          contact email, read as [email protected]
  2418004112                   serial number, raised on every change
  10000                        refresh: secondaries check for changes every 10,000 seconds
  2400                         retry: after a failed check, try again in 2,400 seconds
  604800                       expire: secondaries stop answering after 7 days out of touch
  1800                         negative TTL: remember "no such name" for 30 minutes

The contact field swaps the @ in an email address for a period, so dns.cloudflare.com means [email protected]. The serial number goes up whenever the zone changes, and many administrators write it as a date with a counter, such as 2026102901, though Cloudflare uses its own scheme. The refresh, retry, and expire values tell secondary nameservers, the backup servers that copy the zone from the primary, how often to check for updates and how long to keep answering if they lose contact. The last value matters most day to day, because it sets how long resolvers remember that a name doesn't exist. Look up a name before you create it, and your resolver may keep insisting it doesn't exist for up to that long after you add it, half an hour in example.com's case.

One more type deserves a mention, because it runs DNS in the opposite direction. A PTR (pointer) record turns an address back into a name, and it lives in a special zone where the address is written backward, so the reverse record for 8.8.4.4, one of Google's public resolver addresses, sits at 4.4.8.8.in-addr.arpa and says dns.google (arpa is a top-level domain reserved for internet infrastructure). The holder of an address block controls its reverse zone, which for most home connections means the internet provider, a chain our guide to who hands out IP addresses traces from the top. Mail servers often check PTR records before trusting a sender, and our free reverse DNS tool looks one up for any public address.

Back to the website builder. The apex of a zone, also called the root or bare domain, is the name with nothing in front of it, like example.com as opposed to www.example.com. The apex must hold the zone's SOA record and its NS records, and it usually holds MX and TXT records as well, because email addresses and their security records use the bare domain. CNAMEs, meanwhile, carry the strict rule promised earlier, written into the DNS standards in 1987: a name that has a CNAME record can have no other records at all. The rule follows from what a CNAME means. It declares that this name is really that other name, so a resolver asking for any type of record, whether an address, a mail server, or a line of text, follows the alias and takes whatever the target has.

Put those two facts together and the conflict is plain. A CNAME at the apex would have to sit beside the SOA and NS records that the apex can't do without, which the rule forbids, and if a DNS provider allowed it anyway, resolvers would follow the alias for everything. Mail for [email protected] would go wherever the website builder's mail records point, your SPF and DMARC records would disappear behind the builder's text records, and the domain could fail in ways that are hard to trace. Most DNS providers simply refuse to create the record, and the few that allow it invite exactly those failures. The www name has no such neighbors, which is why the builder can safely ask for a CNAME there.

Four common workarounds exist. The first is the one website builders choose: they give you fixed addresses for the bare domain, to enter as A records, and promise to keep those addresses working, while www gets the flexible CNAME. The second is a feature many DNS providers offer under names such as ALIAS, ANAME, CNAME flattening (Cloudflare's name for it), or alias records (the name used by Route 53, the DNS service of AWS, or Amazon Web Services). You enter the target name as though it were a CNAME, the provider looks up the target's addresses itself, and visitors receive plain A and AAAA records, so the outside world never sees a CNAME at the apex. The cost is that the provider performs the lookup from its own servers, so a CDN that picks a server based on who is asking may see the DNS provider's location instead of the visitor's.

The third workaround is to make the bare domain a simple redirect that sends visitors to www, where the CNAME lives; the redirect service still needs an A record of its own, but its address rarely changes. The fourth is newer. A record type called HTTPS, standardized in 2023, includes an alias mode designed for exactly this situation, but browser support remains incomplete, so for now it supplements the other three without replacing them. Whichever you choose, check the result with a lookup of the bare domain, which should show plain address records and your untouched MX and TXT records side by side.

The ten record types in this guide fit in a single table. Keep it handy the next time a provider's setup page asks for something unfamiliar.

Inside a company's own network, the same record types name every server, printer, and camera, and keeping them accurate is a bookkeeping job as much as a DNS one. In IPCraft, an IPAM (IP address management) system, each address carries a hostname and a reverse DNS (PTR) name beside the address itself, so the records you publish can be checked against one list of what each address is for, and our concepts guide covers the address fields. Some companies also give different answers inside and outside their network, a setup called split-horizon DNS that means keeping two versions of some records, and our guide to merging networks after an acquisition explains why it's easy to get wrong.

On the website builder's setup page, the two instructions now make sense. The CNAME on www lets the builder move your site whenever it likes, the A record on the bare domain respects the rule that keeps your SOA, NS, MX, and TXT records visible, and if your DNS provider offers flattening, you can point the bare domain at the builder's name as well. Every record type in this guide except CAA and SRV can be checked in seconds with our DNS lookup tool, the quickest way to see what a domain is actually telling the world.