Guides · DNS
DNS Records Explained
A practical, record-by-record reference for the DNS types you actually touch when running a domain — what each record is for, how it looks in a zone file, and what trips people up.
By Cody · 7 min read · Published
What a DNS record actually is
A DNS record is five things glued together: a name (like www.example.com), a type (A, MX, TXT, …), a class (almost always IN), a TTL in seconds, and the RDATA — the value the record carries.
Records live on authoritative servers that publish your zone. End-user devices talk to recursive resolvers, which walk the hierarchy on their behalf and cache answers for the TTL. When people say "the change hasn't propagated yet," they almost always mean "some resolver hasn't flushed its cache of the old answer yet."
A and AAAA — addresses
An A record maps a hostname to a single IPv4 address. AAAA is the IPv6 equivalent. A name can have multiple A or AAAA records, in which case resolvers typically return them in a rotating order — there is no "primary" address built into DNS.
Common pitfall: forgetting AAAA on an IPv6-only network. If a client only has IPv6 and your name has only an A record, the client cannot reach you.
CNAME — aliases
A CNAME says "this name is really another name; go ask there." A CNAME cannot coexist with any other record type at the same name, which is why you cannot put a CNAME at the apex (the apex always has SOA and NS).
Pitfall: long CNAME chains add resolver work and a small amount of latency. Resolvers cap how many redirects they follow, so deep chains can fail outright.
MX — mail routing
MX records say "deliver mail for this domain to these hostnames, in this preference order." Each MX has a priority — lower numbers are tried first. MX targets must be hostnames with A or AAAA records; an MX may not point to an IP address and per RFC may not point to a CNAME.
example.com. IN MX 1 aspmx.l.google.com. example.com. IN MX 5 alt1.aspmx.l.google.com.
TXT — verification and policy
TXT records hold arbitrary text. In practice they hold three things: domain ownership tokens for SaaS providers, and the SPF / DKIM / DMARC records that drive email authentication. A single TXT string is capped at 255 characters; longer values are split into multiple quoted strings inside one record.
Pitfall: pasting a TXT value into a control panel that strips quotes around the string boundary. Always re-query the record after publishing to confirm the value reads as one logical string.
NS and SOA — delegation and authority
NS records list the authoritative name servers for a zone. They appear both at the parent (the registrar / TLD) and inside the zone itself; the parent set is what drives delegation. SOA records carry the zone's serial number and timing knobs: refresh, retry, expire, and the negative-cache TTL (minimum).
The serial number matters because secondary servers use it to decide whether they need to pull a new copy of the zone. Bumping the serial without changing the zone has no effect for most modern setups.
CAA — who may issue certificates
CAA records pin which Certificate Authorities are allowed to issue TLS certs for a domain. 0 issue "letsencrypt.org" says "only Let's Encrypt may issue certs at this name." The iodef tag adds a contact for unauthorized-issuance reports.
No CAA record at all means no restriction. A wrong CAA, however, will block a CA from issuing even a renewal — a common cause of last-minute outages during certificate rotation.
SRV — service discovery
SRV records advertise "service X for this domain runs at host Y on port Z." The name follows _service._proto.name — for example_sip._tcp.example.com. Each record has a priority, a weight, a port, and a target hostname. SIP, XMPP, and Microsoft 365 Autodiscover are the most common consumers.
PTR — reverse DNS
PTR records map an IP address back to a hostname, published in thein-addr.arpa (IPv4) or ip6.arpa (IPv6) tree. They are controlled by whoever owns the IP block, which is normally the ISP or cloud provider, not the domain owner. Mail receivers care because a missing or mismatched PTR is a strong spam signal.
TTL strategy
TTL is your knob for "how fast can I change this?" If you know a record will move soon, drop its TTL to a few minutes a day or two ahead of the change so resolvers stop caching the old answer for long. After the dust settles, raise it back to something normal like 1 hour for records that change rarely. There is no benefit to permanently low TTLs except higher query load and a small DNS bill.
Example zone snippet
- Example input
example.com- Example result
example.com. 3600 IN A 93.184.216.34 example.com. 3600 IN AAAA 2606:2800:220:1:248:1893:25c8:1946 example.com. 3600 IN MX 1 aspmx.l.google.com. example.com. 3600 IN TXT "v=spf1 include:_spf.google.com -all" example.com. 3600 IN CAA 0 issue "letsencrypt.org"
A real zone has an A or AAAA for the apex, MX for mail, TXT for SPF, and CAA to limit cert issuance. The TTL column tells resolvers how long they may cache each answer.
Related tools
FAQ
Why can't I put a CNAME at the apex of my domain?
RFC 1034 forbids a CNAME at a name that also has other record types, and the apex of every zone has SOA and NS records by definition. Some DNS providers offer ALIAS or ANAME records that resolve a target to its A/AAAA records at query time so you can point the apex at a hostname, but that resolution happens on the authoritative side, not as a real CNAME.
Does the order of MX records matter?
MX records carry a numeric priority and senders try lower numbers first. The order they appear in your DNS zone file or control panel does not matter. Equal-priority MX records are typically load-balanced across attempts.
How long until DNS changes propagate?
A change is visible to a resolver as soon as the resolver's cached copy of the previous answer expires. That cache lifetime is the TTL on the old record, not the new one. To make a future change fast, lower the TTL on the existing record well in advance, then change it.
What's the difference between authoritative and recursive resolvers?
Authoritative servers publish the records for a zone. Recursive resolvers (your ISP's resolver, 1.1.1.1, 8.8.8.8) walk the DNS hierarchy on behalf of clients and cache the answers. End-user devices almost always talk to recursive resolvers.
Why does my TXT record look split into multiple strings?
A single TXT record is limited to 255 characters per string, but a record can contain multiple strings that the receiver concatenates. Long DKIM keys are the classic case. Most DNS UIs handle the splitting automatically.
Last reviewed: 2026-05-06.