Curated. ~60 record types. Filterable. Real-world notes.

DNS Record Types Reference

Quick searchable reference for the ~60 DNS record types working IT pros actually encounter — with what each type is used for, when you’d add one, and the gotchas no one mentions in the RFC. Better than memorization, friendlier than IANA. Built by Datastrive, a Chicago managed IT and infrastructure provider.

  • Search by type or purpose
  • Categorized by use case
  • Practical notes, not just RFC text
Type Name Status & Notes

What you actually need to know about DNS records

Beyond just memorizing what each type does, there are five concepts that matter every single time you touch DNS — the things that turn a simple “add an A record” task into an outage if you get them wrong.

  1. TTL controls how long records are cached Each record has a TTL (time-to-live) in seconds that tells resolvers how long they can cache it. Common defaults: 300 (5 min), 3600 (1 hour), 86400 (1 day). Before any planned DNS change, lower the TTL on the affected record at least 2× the current TTL in advance — otherwise resolvers worldwide keep serving the old value while you wait for the cache to expire.
  2. “Propagation” isn’t really a thing — caching is People say “DNS propagation takes 24-48 hours” but that’s misleading. Authoritative servers update instantly. What takes time is recursive resolvers around the world expiring their cached copies of the old record. Lower TTL ahead of time, and “propagation” becomes minutes, not hours.
  3. CNAMEs can’t coexist with most other records on the same name If you have a CNAME on www.example.com, you cannot also have an MX, TXT, or A record on www.example.com. The CNAME has to be the only record. This is why you can’t put CNAMEs on the apex (example.com itself) on most DNS providers — the SOA and NS records are required there. Use ALIAS, ANAME, or flattening (Cloudflare’s CNAME flattening) if you need apex CNAME-like behavior.
  4. SPF, DKIM, and DMARC all live in TXT records They’re not separate record types — just specially-formatted TXT records on specific subdomains. SPF on the apex (example.com), DMARC on _dmarc.example.com, DKIM on selector._domainkey.example.com. There’s no SPF record type anymore (RFC 7208 deprecated it). The reference table below shows where each goes.
  5. Glue records are how DNS bootstraps itself If ns1.example.com is the nameserver for example.com, you have a chicken-and-egg problem — how do you find the nameserver without already being able to resolve it? Glue records are A/AAAA records placed at the parent zone (the registrar) for the nameservers themselves. You usually only touch these if you’re running your own nameservers within your domain.
  6. If a record isn’t returning, it might not be where you think Verify directly against the authoritative server, not via a recursive resolver: dig @ns1.example.com example.com TXT +short. If the authoritative server has the record but recursive resolvers don’t, it’s a TTL/cache issue. If the authoritative server doesn’t have it, your changes haven’t taken effect on the right server. Our DNS Lookup tool queries against Cloudflare’s resolver if you want a quick sanity check from outside your network.

Frequently asked questions

What’s the difference between A and AAAA records?

A records map a hostname to an IPv4 address (e.g. 192.0.2.1). AAAA (“quad-A”) records map a hostname to an IPv6 address (e.g. 2001:db8::1). Both are addressing records; the difference is just which IP version they point to.

If you only have IPv4, you only need A records. If you have both IPv4 and IPv6, you typically have both A and AAAA records on the same name — clients pick which to use based on their connectivity. Most public-facing services should publish both these days; about 40% of US internet traffic is now IPv6.

What’s a CNAME and when should I use one?

A CNAME (canonical name) record makes one hostname an alias for another. For example, www.example.com as a CNAME to example.com means anyone looking up www.example.com gets directed to whatever example.com resolves to.

Use CNAMEs when you want a hostname to follow another — if the target’s IP changes, the CNAME follows automatically. Common cases: pointing www at the apex, pointing custom subdomains at a CDN like yoursite.cloudflare.com, or pointing a vanity URL at a SaaS app.

Don’t use CNAMEs at the apex of your domain — most DNS providers don’t allow it (the apex needs SOA and NS records, which conflict with CNAME). Use ALIAS, ANAME, or CNAME flattening instead.

Where do SPF, DKIM, and DMARC records go?

All three are TXT records, but at different names:

SPF goes on your domain apex: example.com with content like v=spf1 include:_spf.google.com ~all. There can only be one SPF record per domain.

DKIM goes on a selector-specific subdomain: {selector}._domainkey.example.com. The selector is whatever your mail provider tells you to use (Google uses google, Microsoft uses selector1 and selector2, etc.). You can have multiple DKIM records, one per selector.

DMARC goes on a fixed subdomain: _dmarc.example.com with content like v=DMARC1; p=reject; rua=mailto:reports@example.com. There’s only one DMARC record per domain.

Want to verify yours are set up correctly? Use our Email Security Checker.

Do I need DNSSEC?

For most small business sites: no, not really. DNSSEC adds cryptographic signatures to DNS responses so resolvers can verify they haven’t been tampered with. It prevents DNS spoofing attacks, which are real but rare in modern networks where most traffic is also encrypted at higher layers (HTTPS, etc.).

DNSSEC is genuinely valuable if you operate at scale (many users depend on you), if you’re in a regulated industry where signed DNS is required, or if you serve resources that benefit from DANE/TLSA validation. Otherwise, the operational complexity (managing signing keys, rolling them, recovering from mistakes) usually outweighs the security benefit for typical SMB deployments.

If you do enable DNSSEC, your domain registrar must support it — check whether they let you publish DS records. And test with dnsviz.net after enabling.

What’s an SRV record for?

SRV records let clients find services by name rather than hardcoded host:port combinations. The format encodes the service name, protocol, port, target host, priority, and weight. For example, an SRV record for _sip._tcp.example.com tells SIP clients to connect to sipserver.example.com:5060.

Common uses: SIP/VoIP servers, XMPP/Jabber, Microsoft Active Directory (which heavily relies on SRV records for domain controller discovery), Minecraft servers, Mastodon. Modern HTTPS uses SVCB/HTTPS records (newer) for similar purposes.

What’s a CAA record and should I have one?

CAA (Certification Authority Authorization) records tell certificate authorities which CAs are allowed to issue SSL/TLS certs for your domain. Without a CAA record, any CA in the trust store can issue a cert for you (assuming they verify ownership). With a CAA record listing only Let’s Encrypt, for example, only Let’s Encrypt can issue.

It’s a defense-in-depth control against rogue or compromised CAs issuing fraudulent certs. CAB Forum requires CAs to check CAA before issuing, so it does work in practice. Adding one is a low-effort, low-risk security improvement — recommended for any domain you actively manage.

Example: example.com. CAA 0 issue "letsencrypt.org" — only Let’s Encrypt can issue certs for example.com.

Need help with the DNS itself?

Datastrive helps Chicago-area businesses configure DNS, fix email deliverability, set up SPF / DKIM / DMARC, and troubleshoot the “why isn’t this resolving?” calls. If DNS is one piece of a bigger infrastructure problem, that’s our job.

Talk to Datastrive →