DNS Record Types Reference
What A, AAAA, MX, TXT, CNAME, NS, SOA, SRV, and CAA records do — and when you'd actually use each one.
The 9 DNS record types you'll actually use
DNS has dozens of record types in the wild — most are obscure or deprecated. These nine cover ~99% of real-world setups.
| Type | What it points to | Common use |
|---|---|---|
| A | IPv4 address | example.com → 192.0.2.1 |
| AAAA | IPv6 address | example.com → 2001:db8::1 |
| CNAME | Another hostname | www.example.com → example.com |
| MX | Mail server | Where email for this domain goes |
| TXT | Arbitrary text | SPF, DKIM, domain verification |
| NS | Name server | Which servers are authoritative for this zone |
| SOA | Zone metadata | One per zone, contains serial and refresh timing |
| SRV | Service location | SIP, XMPP, Microsoft AD service discovery |
| CAA | Cert authority authorization | Limits which CAs can issue certs for the domain |
A vs. AAAA
"A" is for IPv4, "AAAA" (four As, "quad-A") is for IPv6. The names predate IPv6 — the original record type was just A; quad-A reflects the four-times-larger address space. A domain can have both, and modern resolvers prefer AAAA when available.
CNAME — what it is and what it isn't
A CNAME makes one hostname an alias for another. Your DNS server returns the target's records when asked.
Critical limitation: CNAMEs cannot coexist with other records at the same name. So you can't have a CNAME at the apex (example.com itself) if you also have MX records there — and you usually do. That's why www.example.com can be a CNAME but example.com can't. Modern DNS providers offer "ALIAS" or "ANAME" records to work around this.
MX records and priority
MX records have a priority number. Lower = higher priority. A typical setup:
| Priority | Mail server |
|---|---|
| 10 | mx1.example.com |
| 20 | mx2.example.com |
| 30 | backup.example.com |
Senders try the lowest-priority server first. Multiple records at the same priority round-robin.
TXT records — the workhorse
The most-used record type after A. TXT records hold:
- SPF (Sender Policy Framework) — which servers are allowed to send email for this domain. Looks like
v=spf1 include:_spf.google.com ~all. - DKIM public keys — for cryptographic email signing.
- DMARC policy — what to do when SPF/DKIM fail.
- Domain ownership verification — Google, Microsoft, AWS, etc. all use TXT records for "prove you own this domain."
SOA and NS — the boring but important ones
Every DNS zone has exactly one SOA record. It contains:
- Serial number — incremented on every change. Slaves use this to detect when to re-sync.
- Refresh / retry / expire / minimum TTL — timing controls for how slaves and resolvers cache the zone.
NS records list the name servers authoritative for the zone. The parent zone (e.g., the .com servers) also publishes NS records pointing at the same hosts — this is called "delegation."
CAA — the one most people don't know about
CAA (Certification Authority Authorization) records tell certificate authorities whether they're allowed to issue TLS certs for your domain. If you only use Let's Encrypt, a record like:
example.com. CAA 0 issue "letsencrypt.org"
...prevents any other CA from issuing a cert for your domain. Useful defense against certain attack vectors.
Which DNS records I actually deal with in real work
DNS has dozens of record types defined over the years, but a working network administrator interacts regularly with maybe a dozen. Knowing what each does and when to reach for it makes DNS management much less mysterious than it seems.
Every DNS record has the same basic shape: a name, a type, a TTL, and a value. The name is what you look up (example.com, mail.example.com). The type is what kind of information you want (A for IPv4, MX for mail, etc.). The TTL is how long resolvers can cache the answer. The value is the actual data — an IP address for A records, a hostname for CNAME, a priority-plus-host for MX, and so on.
A and AAAA in real usage
A records map hostnames to IPv4 addresses. AAAA records do the same for IPv6. When your browser wants to reach example.com, it queries A (and probably AAAA) records to figure out which IP to connect to.
Multiple A records for the same name is "round-robin DNS" — resolvers return them in varying orders, and clients typically try the first, falling back to others if the first fails. This is a poor-man's load balancer that works for simple cases but isn't intelligent (doesn't consider server health, geographic proximity, or actual load).
Modern deployments often use AAAA records to enable IPv6 connectivity. Missing AAAA on a site that supports IPv6 makes it unreachable to IPv6-only clients (a small but growing minority). If you're running services that should work everywhere, make sure both A and AAAA are published.
CNAME and its pitfalls
CNAME (Canonical Name) makes one hostname an alias for another. When a resolver looks up a CNAME, it follows the alias and returns the target's records instead.
Common use: pointing customer-facing subdomains at CDN endpoints. www.example.com might CNAME to example-com.cdnprovider.net, so the CDN can change its underlying IPs without the customer having to update DNS.
Two gotchas:
- CNAME can't coexist with other records at the same name. If www.example.com has a CNAME, it can't also have A, MX, or TXT records. The CNAME says "look somewhere else for those records." This causes real problems when people try to CNAME the apex domain (example.com itself), because the apex must have SOA and NS records which CNAME wouldn't allow. Most DNS providers offer "ALIAS" or "ANAME" records as a workaround.
- CNAME chains add latency. Each hop requires another DNS query. Deeply nested CNAMEs (three or more hops) can noticeably slow down first-time lookups.
MX records and mail flow
MX records tell the world where to send email for a domain. Each MX record has a priority and a hostname. Lower priority means "try this one first." Common setup: a primary MX with priority 10 and a backup with priority 20.
The hostname pointed at by MX must resolve to actual IPs (A or AAAA records). CNAMEs are not allowed as MX targets per RFC 5321, though some tolerant senders accept them anyway.
Missing MX means the domain can't receive mail. Wrong MX means mail goes to the wrong destination. Every domain that receives mail should have MX records; every domain that doesn't receive mail should either publish "null MX" (a single MX record pointing to "." with priority 0) or an SPF record indicating no mail is sent.
TXT records: the free-form field
TXT records hold arbitrary text. Because they're flexible, they've become the mechanism for many purposes:
- SPF: an SPF record is a TXT record starting with "v=spf1"
- DKIM: DKIM public keys are TXT records at specific selector names
- DMARC: DMARC policies are TXT records at _dmarc.example.com
- Domain verification: services like Google Workspace, Microsoft 365, GitHub, AWS have you add a specific TXT record to prove you control the domain
- MTA-STS: TXT record at _mta-sts.example.com
- DNS-based CAA: no, CAA is a separate record type, not TXT
A typical medium-sized domain might have a dozen TXT records for various purposes. When auditing, sorting through which is which reveals what services are integrated with the domain.
SOA and NS
SOA (Start of Authority) is the "root" record of a DNS zone. It contains administrative info: the primary nameserver, the admin contact, serial number for zone tracking, and various timers. There's exactly one SOA per zone.
NS records identify the authoritative nameservers for the zone. Every domain must have NS records at the top level, and typically has at least two nameservers for redundancy.
These records rarely need touching manually. Your DNS provider sets them when you delegate the domain to them. If you're moving DNS providers, you update the NS records at your registrar to point at the new provider, and after propagation, everything else follows automatically.
CAA — the underused security record
Certificate Authority Authorization records specify which CAs are allowed to issue certificates for the domain. If example.com has a CAA record saying "only Let's Encrypt can issue certificates for me," then when any other CA receives a certificate request for example.com, they're required by the CA/Browser Forum baseline requirements to reject it.
This is a real security improvement. Without CAA, any of the ~100 publicly-trusted CAs could theoretically issue a certificate for your domain (some CAs have been compromised historically and issued fraudulent certificates). With CAA, you constrain issuance to only the CAs you actually use.
Most domains don't have CAA records. Adding one is a small effort that reduces attack surface. If you use Let's Encrypt, the CAA record is example.com CAA 0 issue "letsencrypt.org".
PTR and reverse DNS
PTR records map IP addresses back to hostnames. They live in the special reverse zones (in-addr.arpa for IPv4, ip6.arpa for IPv6) delegated based on IP allocation. See the Reverse DNS tool for lookups.
PTR records matter most for mail. Mail servers with missing or generic PTR records have deliverability problems. Setting a proper PTR record for your mail server's IP (usually requires the IP owner's cooperation) meaningfully improves inbox placement.
SRV records
SRV records identify which host and port to contact for a specific service. Used heavily by Active Directory (_ldap._tcp.example.com points at domain controllers), Matrix, XMPP, and some VoIP configurations. Format is priority, weight, port, and target hostname.
Ordinary web services rarely use SRV. If you're setting up Kerberos, AD, or federated protocols, you'll see them.
Less-common types worth knowing about
DNSKEY, DS, RRSIG, NSEC, NSEC3
DNSSEC records. Add cryptographic verification to DNS responses. Deployment is common at the TLD level and increasingly at large services, but many domains still don't use it.
TLSA
DANE records that pin specific TLS certificates or public keys to DNS. Sees limited use in mail (MTA-STS is more common) and even less in general web.
HTTPS and SVCB
Newer record types (RFC 9460) that let clients discover HTTPS endpoints, ALPN support, and connection parameters before making a connection. Adopted by Cloudflare, Google, and other major CDN operators. Useful for optimizing initial connection latency.
Related tools
For querying a domain's DNS records across multiple resolvers, use the DNS Lookup tool. For checking DNS propagation of a change, use the DNS Propagation Checker. For a comprehensive view of a domain's infrastructure (DNS plus IP ownership), use the Domain Infrastructure tool. For email-specific DNS validation (MX, SPF, DKIM, DMARC), use the Email Health Check.