DNS record types explained: A, AAAA, CNAME, MX, TXT and more, with examples

Short answer: the DNS record types you meet most are A (a name’s IPv4 address), AAAA (its IPv6 address), CNAME (an alias for another name), MX (the domain’s mail servers), TXT (text such as SPF, DKIM and DMARC), NS (the zone’s nameservers) and SOA (the zone’s settings). PTR, SRV, CAA and HTTPS cover reverse DNS, service ports, certificate issuers and HTTP/3.

The examples use the documentation addresses 203.0.113.0/24 and 2001:db8::/32 and the reserved name example.com. Record syntax follows RFC 1035 and the RFC that defines each newer type (CAA in RFC 8659, HTTPS and SVCB in RFC 9460). For how these records fit into a lookup, start with what is DNS; this guide is the reference for the records themselves.

How to read a record

Every record line in a zone file has the same five parts:

www.example.com.   3600   IN   A   203.0.113.10
NAME               TTL    CLASS TYPE DATA

• Name: the owner name. @ means the zone itself (the apex, example.com), and a name without a trailing dot is relative, so www inside the example.com zone means www.example.com.
• TTL: how many seconds resolvers may cache the answer. Left out, the zone’s $TTL default applies.
• Class: always IN (internet) in practice.
• Type and data: the record type and its value, whose format depends on the type.

A DNS provider’s web panel shows the same fields under other labels: Name or Host, Type, Value or Points to, TTL. Most panels append the zone name for you, so you type www or mail, not the full name.

A record example (and AAAA)

The A record is the one that points a domain at a server. A typical web server needs the apex and www, plus the same pair as AAAA records if the server has IPv6:

@     3600  IN  A     203.0.113.10
www   3600  IN  A     203.0.113.10
@     3600  IN  AAAA  2001:db8::10
www   3600  IN  AAAA  2001:db8::10

example.com.		3600	IN	A	203.0.113.10

Several A records on the same name are allowed; resolvers return all of them and clients pick one, which spreads load in a crude way but does not check whether a server is up. An A record always holds an IP address, never a name. The full sequence for a new server (records, waiting for caches, then HTTPS) is in how to point a domain to a VPS.

CNAME: aliases and their two rules

A CNAME says “this name is another name”: a resolver that finds www IN CNAME example.com. restarts the lookup at example.com. That is why a plain lookup of www shows both steps:

example.com.
203.0.113.10

• No other records next to a CNAME. A name that has a CNAME may have nothing else (RFC 1034, section 3.6.2). BIND refuses to load such a zone with CNAME and other data, and most web panels refuse to save it.
• No CNAME at the apex. The apex always carries NS and SOA records, so by the first rule it cannot be a CNAME. Providers work around this with ALIAS, ANAME or “CNAME flattening”: they resolve the target themselves and answer with plain A and AAAA records. It works, but it is a feature of that provider, not a record you can move to another one.

What is an MX record?

MX stands for mail exchanger. An MX record tells other mail servers where to deliver mail for a domain. Each one has a priority number, and senders try the lowest number first and move to the next only if it fails:

@      3600  IN  MX  10 mail.example.com.
@      3600  IN  MX  20 backup-mx.example.net.
mail   3600  IN  A   203.0.113.25

• The target is a host name with its own A or AAAA record. Not an IP address (the field holds a domain name), and not a CNAME (RFC 2181, section 10.3).
• Equal numbers share the load: two MX records at priority 10 get mail in roughly equal parts.
• No MX at all does not mean “no mail”: senders fall back to the domain’s A or AAAA record (RFC 5321, section 5.1). A domain that should never receive mail publishes a null MX (RFC 7505): @ IN MX 0 .

A mail server also needs a matching reverse DNS entry for its IP, covered in reverse DNS and PTR records, and the TXT records below.

TXT: SPF, DKIM, DMARC and verification

@                 IN  TXT  "v=spf1 mx ip4:203.0.113.25 -all"
s1._domainkey     IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
_dmarc            IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
@                 IN  TXT  "site-verification=3f9a1c..."

• SPF lives on the domain itself and lists who may send its mail. A domain may have only one v=spf1 record; two make SPF fail with a permanent error, and the record may trigger at most ten further DNS lookups (RFC 7208).
• DKIM keys live under SELECTOR._domainkey; the selector comes from your mail software.
• DMARC lives under _dmarc and tells receivers what to do when SPF and DKIM fail.
• Long values: one string in a TXT record holds at most 255 characters. A 2048-bit DKIM key is longer, so zone files split it into several quoted strings in one record, which receivers join back together. Many panels do that for you.

The SPF record generator builds a valid v=spf1 line from the servers that send your mail.

NS and SOA: who answers for the zone

NS records at the apex list the zone’s authoritative servers. The copy that matters for the world sits one level up, in the parent zone, where your registrar puts it; an NS record lower down (dev IN NS ns1.other-provider.net.) hands a subdomain to different servers. Registrar side, glue records and changing providers are covered in what are nameservers.

@  IN  SOA  ns1.example.net. hostmaster.example.com. (
           2026102101  ; serial: raise it on every change (YYYYMMDDnn)
           7200        ; refresh: how often secondaries check the serial
           3600        ; retry: after a failed refresh
           1209600     ; expire: secondaries stop answering after this
           3600 )      ; negative-caching TTL for "name does not exist"

The second field is the admin mailbox with the @ written as a dot, so hostmaster.example.com. means hostmaster@example.com. The last field, or the SOA record’s own TTL if that is lower, decides how long a resolver remembers that a name did not exist (RFC 2308), which is why a record you create minutes after someone looked it up can stay invisible for a while.

PTR, SRV and CAA

PTR

A PTR record maps an address back to a name. It lives in a special zone under in-addr.arpa (IPv4, octets reversed) or ip6.arpa (IPv6, nibbles reversed), which belongs to whoever owns the IP range: your hosting provider, not your domain. On a VMHeaven server you set it in the panel; the details are in the PTR record guide.

SRV

An SRV record publishes the host and port of a service under _service._protocol.name, so users can type a plain name and the client finds the port. The data is priority, weight, port, target (RFC 2782). Minecraft Java Edition is the familiar case: _minecraft._tcp.mc IN SRV 0 5 25566 server1.example.com. lets players join mc.example.com although the game runs on port 25566 of server1.example.com, and the target needs its own A record. Only clients written to look for SRV records use them; browsers do not.

CAA

CAA lists the certificate authorities allowed to issue for the domain: issue for normal certificates, issuewild for wildcards and iodef for a report address. Public CAs must check it before issuing. With no CAA record any CA may issue; with one, a CA that is not listed refuses, which is the usual reason a certificate request suddenly fails after someone added CAA for a different CA.

ALIAS, HTTPS and SVCB, DNSSEC records

• ALIAS / ANAME: described under CNAME above. Never a type on the wire; a resolver only ever sees A and AAAA.
• HTTPS and SVCB (RFC 9460, November 2023): a record that tells a browser before it connects which protocols the site speaks (alpn="h3,h2"announces HTTP/3), which addresses to use and, where a site uses it, the key for Encrypted Client Hello. In AliasMode (priority 0) it can also alias the apex to another name, the job ALIAS does in proprietary form. Some CDNs publish it automatically; on your own server it is optional.
• DS and DNSKEY: with DNSSEC, the zone publishes its public keys as DNSKEY and signs every record set (RRSIG records). The DS record sits in the parent zone, set through your registrar, and links the two. A DS that no longer matches the keys, typically after a move to a new DNS provider, makes validating resolvers answer SERVFAIL for the whole domain.

How to look up each record type

$ dig example.com MX +short
10 mail.example.com.
20 backup-mx.example.net.

$ dig example.com TXT +short
"v=spf1 mx ip4:203.0.113.25 -all"

Add @SERVER to ask one server directly: one of the domain’s own nameservers shows what the zone really says, a public resolver shows what visitors get from its cache. Drop +short, or use +noall +answer, to see TTLs. Do not rely on ANY to list every record; many servers answer it with a minimal reply, as the nslookup guide explains along with the rest of nslookup’s output. The nslookup column above is for the BIND version on Linux and macOS; Windows nslookup handles the classic types, and dig is the safer tool for CAA, HTTPS and DNSSEC records.

Without a terminal, the DNS lookup tool shows a name’s records with their TTLs in the browser.

Common DNS record mistakes

• A CNAME next to other records, or at the apex. Use A and AAAA at the apex, or the provider’s ALIAS feature.
• The missing trailing dot. In a zone file, MX 10 mail.example.com without the final dot is relative and becomes mail.example.com.example.com. In a web panel it happens the other way round: typing www.example.com into a Name field that appends the zone itself gives www.example.com.example.com. Check with dig after saving.
• A long TTL during a migration. Lower the TTL of the records you will change to 300 seconds at least one old TTL ahead of the move, switch, then raise it again. Otherwise caches keep sending visitors to the old server for hours.
• A stale AAAA record. You moved the A record to the new server and forgot the AAAA, so visitors with IPv6 still reach the old one. Update both, or remove the AAAA if the new server has no IPv6 configured.
• Two SPF records instead of one combined v=spf1 line, and MX records that point at an IP address or a CNAME.
• Editing records at the wrong provider. Only the provider your nameservers point to is asked; records in any other panel are never served.

Frequently asked