Understanding DNS Records: A, MX, TXT, CAA and More

A DNS zone is a list of records, and each record answers one kind of question about a name: which IP address it lives at, where its email goes, who may issue its certificates and so on. You do not need to memorize every type, but knowing the common ones, and a few rules about how they interact, makes it much easier to set up a domain correctly and to diagnose problems when something stops working.

Anatomy of a record

Every record has the same basic parts:

www.example.com.   3600   IN   A   192.0.2.10

• Name: the owner name the record belongs to, here www.example.com. The trailing dot marks it as fully qualified.
• TTL: how many seconds resolvers may cache it. See How DNS works.
• Class: almost always IN, for internet.
• Type: what kind of record it is.
• Data: the value, whose format depends on the type.

A single name can hold many records of different types, and several records of the same type. The zone apex, meaning the bare domain such as example.com, is the name where the SOA and NS records live.

The common types at a glance

Address records: A and AAAA

A records map a name to an IPv4 address and AAAA records to an IPv6 address. A name can have several of each, and resolvers return them all, which is one simple way to spread traffic across servers. If your server supports IPv6, publishing both types lets clients use whichever they prefer.

CNAME: aliases, and why not at the apex

A CNAME record says "this name is an alias; look up that other name instead." It is handy when a service provider gives you a hostname to point at, because the provider can change the underlying addresses without you editing your zone.

www.example.com.   3600   IN   CNAME   site.example.net.

The key rule, from RFC 1034, is that a name with a CNAME cannot have any other records (DNSSEC signature records aside). The alias replaces everything at that name. The zone apex must always have SOA and NS records, so a standard CNAME cannot exist at example.com itself. That is why you can alias www.example.com to a hosting provider but not the bare domain.

Many DNS providers offer a workaround, variously called ALIAS, ANAME or CNAME flattening. The provider resolves the target itself and publishes ordinary A and AAAA records at the apex. These are provider features rather than a standard record type, so they only work where your DNS host supports them.

MX: where email goes

MX records list the servers that accept mail for a domain. Each has a priority number, and lower numbers are tried first:

example.com.   3600   IN   MX   10 mail1.example.com.
example.com.   3600   IN   MX   20 mail2.example.net.

Two rules are easy to break. An MX must point to a hostname, not an IP address. And that hostname should have A or AAAA records, not a CNAME. A domain that should never receive mail can publish a "null MX" (priority 0 with a target of a single dot), as described in RFC 7505.

NS and SOA: the zone's own metadata

NS records list the authoritative nameservers for a zone. They appear both in the parent zone, as the delegation, and at your apex. The two sets should match. See Understanding nameservers.

The SOA (start of authority) record holds the zone's primary server name, a contact mailbox written with a dot in place of the @, a serial number, and timers that secondary servers use to stay in sync. Its last field also sets how long resolvers cache negative answers.

example.com.  3600  IN  SOA  ns1.example.net. hostmaster.example.com. 2026092401 7200 3600 1209600 3600

TXT: the multipurpose record

TXT records hold arbitrary text. They are now widely used for machine-readable policies and ownership checks:

• SPF policies (v=spf1 ...), covered in What SPF does;
• DMARC policies at _dmarc.example.com, covered in What DMARC does;
• DKIM public keys at selector._domainkey.example.com;
• domain verification tokens for various online services.

A single TXT string is limited to 255 characters, but one record can hold several strings, which are joined together when read. Long SPF records and DKIM keys rely on this.

CAA: limiting certificate issuance

CAA records, defined in RFC 8659, tell certificate authorities which of them may issue certificates for your domain. CAs are required to check CAA before issuing. Without any CAA records, any publicly trusted CA may issue.

example.com.   3600   IN   CAA   0 issue "ca.example.net"
example.com.   3600   IN   CAA   0 issuewild ";"
example.com.   3600   IN   CAA   0 iodef "mailto:[email protected]"

This example allows one CA to issue, forbids wildcard certificates entirely, and gives an address for reporting problems. CAA is checked by walking up the name tree, so a record at example.com also covers www.example.com unless the subdomain has its own.

SRV: services with ports

SRV records point clients to a server and port for a named service and protocol. The name has the form _service._proto.domain, and the data holds priority, weight, port and target:

_sip._tcp.example.com.   3600   IN   SRV   10 5 5060 sip.example.com.

They are used by protocols such as SIP, XMPP and some directory services. Web browsers do not use SRV to find websites.

PTR: reverse DNS

PTR records map IP addresses back to names. They live in special zones, in-addr.arpa for IPv4 and ip6.arpa for IPv6, which are controlled by whoever holds the IP address block, usually your hosting or network provider, not by your domain's DNS host.

10.2.0.192.in-addr.arpa.   3600   IN   PTR   mail.example.com.

Reverse DNS matters most for mail servers: many receiving systems expect a sending server's IP address to have a PTR record whose name resolves back to the same address.

Check it yourself

• DNS Lookup retrieves any of these record types for a name so you can confirm what is actually published.
• MX Checker examines a domain's mail servers, their priorities and whether their hostnames resolve correctly.
• CAA Checker shows which certificate authorities are permitted to issue for a domain, including records inherited from parent names.