DNS Record Types: A Complete Reference (A, AAAA, MX, TXT, CNAME, NS, SOA, CAA)

DNS has dozens of defined record types, but in practice you’ll work with about ten of them on a regular basis. This is a complete, practical reference for the ones that actually matter, with the gotchas you only learn by misconfiguring them once.

For background on how DNS lookups themselves work, see How DNS Lookup Works. This post is the reference companion — the encyclopedia of records you’ll meet.

A Record (IPv4 address)

The bread-and-butter record. Maps a hostname to an IPv4 address.

ip2geo.dev.       A    104.18.27.89
www.ip2geo.dev.   A    104.18.27.89

What it’s for: Resolving any name to an IPv4 address.

Gotchas:

• A hostname can have multiple A records. Clients pick one (round-robin or via load-balancing logic).
• The TTL controls how long the answer is cached. Lower TTLs = changes propagate faster but DNS query load goes up.
• A and CNAME records cannot coexist on the same name.

AAAA Record (IPv6 address)

The IPv6 equivalent of an A record.

ip2geo.dev.       AAAA    2606:4700:20::ac43:4a8a

What it’s for: Resolving names to IPv6 addresses.

Gotchas:

• AAAA stands for “quad-A” (four times the size of A — IPv6 is 128-bit vs IPv4’s 32-bit).
• Most modern domains have both A and AAAA records. Clients prefer IPv6 if available (“Happy Eyeballs”).
• An AAAA without a corresponding A is fine for IPv6-only services, but most clients can’t reach them without IPv6 connectivity. See IPv4 vs IPv6.

CNAME Record (canonical name / alias)

Aliases one hostname to another.

www.ip2geo.dev.    CNAME    ip2geo.dev.

When a client looks up www.ip2geo.dev, the DNS resolver sees the CNAME, follows it to ip2geo.dev, and returns whatever A/AAAA records ip2geo.dev has.

What it’s for: Making www.example.com and example.com resolve to the same target, or pointing a custom domain at a SaaS provider’s hostname (app.yoursite.com → yoursite.someservice.com).

Gotchas:

• A CNAME cannot coexist with any other record type at the same name. So you can’t have a CNAME on example.com if you also need MX records (you’ll have to set the apex to A records and use ALIAS / ANAME / virtual CNAMEs as a workaround — see below).
• CNAME chains shouldn’t be more than a few hops deep. Resolvers may follow them, but each hop adds latency.
• Some DNS providers offer “ALIAS” or “ANAME” records — a CNAME-like feature that can coexist with other records at the apex. These aren’t standard DNS; the provider transparently resolves them to A records before serving.

MX Record (mail exchange)

Tells SMTP servers where to deliver mail for a domain.

example.com.    MX    10    mail1.example.com.
example.com.    MX    20    mail2.example.com.

The number (priority) is how senders pick between multiple mail servers — lower is preferred. If priority 10 is unreachable, senders fall back to priority 20.

What it’s for: Email routing. Without an MX record, mail to your domain bounces.

Gotchas:

• The MX target must be a hostname, not an IP. The target then needs its own A/AAAA records.
• If you have no MX record, some mail servers fall back to the A record of the domain — but don’t rely on this.
• MX records don’t include port numbers — SMTP uses port 25 by convention (or 587/465 for submission).
• Using a hosted email provider (Google Workspace, Fastmail, Microsoft 365) means setting their MX records and removing your old ones. Forgetting to remove old ones causes mail loss.

TXT Record (free-form text)

Originally for arbitrary notes. Now used for dozens of layered protocols.

example.com.    TXT    "v=spf1 include:_spf.google.com ~all"
example.com.    TXT    "google-site-verification=abc123..."

Common uses:

• SPF (Sender Policy Framework) — lists which servers are authorized to send email for your domain.
• DKIM — public key for verifying email signatures.
• DMARC — policy for what to do with unauthenticated mail.
• Domain verification — proving you own a domain for SaaS services (Google, Microsoft, Slack, etc.).
• MTA-STS — TLS policy for inbound email.

Gotchas:

• TXT records have a 255-character limit per string, but you can have multiple strings concatenated.
• The order of TXT records is not guaranteed; if multiple protocols use TXT, they must each have unique syntax.
• Removing the wrong TXT record can silently break email or verification with a service you forgot about.

NS Record (nameserver delegation)

Identifies the authoritative nameservers for a zone.

example.com.    NS    ns1.example-dns.com.
example.com.    NS    ns2.example-dns.com.

What it’s for: Telling the world which servers to ask for records in this domain. The TLD nameservers (e.g., the .com registry) hold NS records pointing to your authoritative nameservers; your authoritative nameservers hold all your other records.

Gotchas:

• Changing NS records (migrating between DNS providers) means TLD propagation, which respects the parent zone’s TTL. Plan for 24+ hours of mixed state.
• NS records also exist within a zone for delegating subdomains to different nameservers (subdomain.example.com. NS ns1.subdomain-provider.com.).
• Glue records — A records for nameservers that fall within their own zone — are required when the NS is inside the zone it delegates (e.g., ns1.example.com for example.com).

SOA Record (start of authority)

Zone-level metadata. One SOA per zone.

example.com.    SOA    ns1.example.com.    admin.example.com. (
                       2026051701    ; serial
                       3600          ; refresh
                       600           ; retry
                       604800        ; expire
                       3600 )        ; minimum

Fields:

• Primary nameserver — the authoritative master.
• Admin email — but written with . instead of @ (i.e., admin.example.com. not [email protected]).
• Serial — a version number for the zone. Conventionally YYYYMMDDNN (date + revision).
• Refresh — how often secondary nameservers re-check the master.
• Retry — retry interval if the master is unreachable.
• Expire — how long secondaries serve stale data if the master is unreachable.
• Minimum — minimum TTL for negative responses (NXDOMAIN caching).

Gotchas:

• The serial must increase on every change. Some providers do this automatically; some don’t. Stale serials cause secondary nameservers to not pick up changes.
• The “admin email” trips everyone up the first time. It’s dot-form, not at-form.

CAA Record (Certificate Authority Authorization)

Tells certificate authorities which of them are allowed to issue TLS certs for your domain.

example.com.    CAA    0 issue "letsencrypt.org"
example.com.    CAA    0 issuewild "letsencrypt.org"
example.com.    CAA    0 iodef "mailto:[email protected]"

What it’s for: Security. Without a CAA record, any publicly-trusted CA can issue a certificate for your domain. With one, only the listed CAs can.

Common values:

• issue "letsencrypt.org" — allow Let’s Encrypt to issue normal certs.
• issuewild "letsencrypt.org" — allow wildcard certs.
• issue ";" — explicitly forbid all CAs (use carefully).
• iodef "mailto:..." — where to send reports of unauthorized issuance attempts.

Gotchas:

• CAA records apply to the domain and all subdomains unless overridden.
• If you change CA providers, you must update CAA records first or new cert issuance will fail.
• Many small domains don’t set CAA records at all and rely on certificate transparency logs for monitoring instead. Setting CAA is cheap insurance.

PTR Record (reverse DNS)

The reverse of an A record. Maps an IP back to a name.

89.27.18.104.in-addr.arpa.    PTR    something.cloudflare.com.

Note the awkward format — IPs are reversed and placed in the in-addr.arpa. (IPv4) or ip6.arpa. (IPv6) special domain.

What it’s for: Mail server reputation, abuse tracking, occasionally identifying anonymous IPs.

Gotchas:

• PTR records are managed by whoever owns the IP block (typically your ISP or hosting provider), not by you as the domain owner.
• Mail servers often check that the PTR record matches a forward A record (“forward-confirmed reverse DNS”). Mismatched or missing PTRs reduce email deliverability.
• CDN-hosted IPs usually don’t have meaningful PTRs.
• See Reverse DNS Lookups Explained for the full discussion.

SRV Record (service location)

Specifies the location of services for a domain. Often used with SIP, XMPP, Matrix, Minecraft, and various other protocols.

_xmpp-server._tcp.example.com.    SRV    10 0 5269 xmpp.example.com.

Format: _service._protocol.name TTL class SRV priority weight port target.

What it’s for: Telling clients which host and port to connect to for a specific service.

Gotchas:

• HTTPS doesn’t use SRV records (it uses HTTPS/SVCB records — see below).
• Many clients don’t honor SRV records correctly. Don’t rely on them unless the protocol specifically requires them.

HTTPS / SVCB Records (modern web service discovery)

Newer record types for HTTPS, allowing additional service metadata.

example.com.    HTTPS    1 . alpn=h3,h2 ipv4hint=104.18.27.89 ipv6hint=2606:4700:20::ac43:4a8a

What it’s for: Letting clients learn about HTTP/3 support, ALPN, and alternate addresses without needing A/AAAA lookups first.

Gotchas:

• Still being deployed in 2026 — modern browsers support it, but adoption is gradual.
• Provides a meaningful performance improvement for modern protocols (HTTP/3 over QUIC).

DNSKEY, DS, RRSIG, NSEC, NSEC3 (DNSSEC records)

Records used for DNS Security Extensions — cryptographic signing of DNS zones.

example.com.    DNSKEY    257 3 13 ...
example.com.    DS        12345 13 2 abc...

What it’s for: Preventing DNS spoofing by cryptographically signing records.

Gotchas:

• DNSSEC is operationally complex. Misconfiguration breaks the entire domain.
• Adoption has been slow because the operational risk often outweighs the security benefit for typical domains.
• Most TLS already protects against the attacks DNSSEC was designed to prevent.
• If you’re not running DNSSEC, you’re in good company. If you are, automate the key rotation.

DKIM Selectors (TXT records, special structure)

DKIM (DomainKeys Identified Mail) uses TXT records at well-known names:

default._domainkey.example.com.    TXT    "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG..."

What it’s for: Public key for verifying DKIM-signed email.

Gotchas:

• The “selector” (default in this example) is chosen by you — but mail providers often specify one.
• Multiple selectors per domain are common (for different mail providers or for key rotation).
• The TXT content can be very long; some providers split into multiple strings.

Less Common but Worth Knowing

NAPTR

Used by SIP and ENUM (mapping E.164 phone numbers to URIs). Not relevant for most web stacks.

LOC

Encodes geographic coordinates. Almost never used in practice.

TLSA

For DANE — letting domains specify which TLS certs are valid. Used in some email contexts.

URI

Specifies URIs associated with a name. Some protocols use it; web infrastructure mostly doesn’t.

OPENPGPKEY

For publishing PGP keys via DNS. Niche.

You’ll meet these occasionally but only if you’re working on the specific protocols that use them.

A Mental Model: What Lives Where

For a typical domain:

• NS records at the apex: who hosts your DNS.
• SOA record at the apex: zone metadata.
• A/AAAA records at the apex and www: where the web server is.
• MX records: where mail goes.
• TXT records: SPF, DKIM, DMARC, plus whatever verifications you’ve collected.
• CAA records: which CAs are authorized.
• CNAMEs on subdomains: pointing customer-facing names to SaaS providers (status.example.com → cname.statuspage.io).

When you go to set up a new domain, this is the rough checklist of records you’ll touch.

Looking Up Records Yourself

dig is the easiest tool:

dig example.com A
dig example.com MX
dig example.com TXT
dig example.com CAA
dig example.com ANY      # Returns everything (some resolvers refuse)

Or use the Ip2Geo DNS lookup tool in a browser — A, AAAA, MX, NS, TXT, CNAME, SOA, and CAA for any domain in one query.

TL;DR

• A/AAAA = IP addresses. Most fundamental.
• CNAME = alias. Don’t put one at the apex if you also need MX/TXT/etc.
• MX = mail routing. Priority matters.
• TXT = anything text. Mostly email auth (SPF, DKIM, DMARC) and verifications.
• NS = delegation. What nameserver to ask.
• SOA = zone metadata. Serial, refresh, expire.
• CAA = which CAs can issue certs. Cheap insurance.
• PTR = reverse lookup. Owned by the IP holder, not the domain holder.
• DNSSEC records exist but operational complexity scares most teams away.
• HTTPS/SVCB records are new and useful for HTTP/3 era.

If you’re touching DNS in 2026, you’ll hit these records constantly. Bookmark this; the gotchas alone will save hours.