DNS Record Types Explained: A, AAAA, CNAME, MX, TXT, and Beyond

How DNS Records Work

The Domain Name System (DNS) is a distributed database that maps human-readable domain names to machine-readable addresses and configuration data. Each DNS record has a type that determines what kind of data it contains and how it is used.

Every DNS record shares the same basic structure:

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

NAME: The domain this record applies to (trailing dot = fully qualified)
TTL: Time-to-live in seconds — how long resolvers cache this record
CLASS: Almost always IN (Internet)
TYPE: The record type (A, AAAA, CNAME, etc.)
DATA: The record-specific payload

Address Records

A Record (IPv4)

The A record maps a hostname to an IPv4 address. It is the most fundamental DNS record.

# DNS zone file:
example.com.     3600  IN  A  203.0.113.10
www.example.com. 3600  IN  A  203.0.113.10

# Query:
dig A example.com
# ;; ANSWER SECTION:
# example.com. 3600 IN A 203.0.113.10

Round-robin DNS uses multiple A records for the same name to distribute load:

example.com. 60 IN A 203.0.113.10
example.com. 60 IN A 203.0.113.11
example.com. 60 IN A 203.0.113.12

Resolvers return all records and rotate their order. DNS round-robin is not true load balancing — it does not account for server health or current load. Use a proper load balancer or health-checked DNS (Route 53 health checks, Cloudflare load balancing) for production traffic distribution.

AAAA Record (IPv6)

AAAA records map hostnames to IPv6 addresses. The name comes from IPv6 being four times the length of IPv4 (128 bits vs 32 bits).

example.com. 3600 IN AAAA 2001:db8::1

# Query:
dig AAAA example.com

Modern stacks should publish both A and AAAA records. Clients with IPv6 connectivity prefer AAAA via the Happy Eyeballs algorithm (RFC 8305), which races IPv4 and IPv6 connections with a 250ms delay favoring IPv6.

Alias Records

CNAME Record (Canonical Name)

A CNAME creates an alias from one hostname to another. The resolver follows the chain until it finds an A or AAAA record:

www.example.com. 3600 IN CNAME example.com.
blog.example.com. 3600 IN CNAME myblog.ghost.io.

# Resolution chain:
# www.example.com → CNAME → example.com → A → 203.0.113.10

Critical CNAME restriction: You cannot use a CNAME at the zone apex (naked domain). This is invalid:

# INVALID — CNAME at zone apex is forbidden by RFC 1034:
example.com. IN CNAME other.example.com.

This restriction exists because the zone apex must contain NS and SOA records, which cannot coexist with a CNAME.

ALIAS / ANAME Records (Zone Apex Workaround)

Many DNS providers offer a proprietary ALIAS or ANAME record type that behaves like a CNAME but resolves to an IP address at query time, making it compatible with the zone apex:

# Cloudflare: Use A record with 'Proxied' mode (CNAME flattening)
# AWS Route 53: Use 'Alias' record type pointing to ELB/CloudFront
# DNSimple: ALIAS record
example.com. IN ALIAS myblog.ghost.io.

Cloudflare CNAME Flattening: Cloudflare automatically resolves CNAME chains at the zone apex and serves the resulting A/AAAA records. This is how example.com can CNAME to a CDN endpoint while remaining standards-compliant.

Email Records

MX Record (Mail Exchange)

MX records direct email delivery to the appropriate mail servers for a domain. Each MX record has a priority (lower = higher priority):

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

# Sending MTAs try priority 10 first; fail over to 20 if unavailable

# Query:
dig MX example.com

For Google Workspace:

example.com. IN MX 1  aspmx.l.google.com.
example.com. IN MX 5  alt1.aspmx.l.google.com.
example.com. IN MX 5  alt2.aspmx.l.google.com.
example.com. IN MX 10 alt3.aspmx.l.google.com.
example.com. IN MX 10 alt4.aspmx.l.google.com.

SPF via TXT Record

SPF (Sender Policy Framework) is published as a TXT record at the zone apex:

example.com. IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 ~all"

SPF has a 10-DNS-lookup limit. Each include: counts as one lookup. Exceed this and SPF evaluations return permerror, causing authentication failures.

DKIM via TXT (or CNAME)

DKIM public keys are published at <selector>._domainkey.<domain>:

# TXT record (traditional):
google._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ..."

# CNAME to ESP-managed key (modern ESPs):
sendgrid._domainkey.example.com. IN CNAME s1.domainkey.u12345.wl.sendgrid.net.

# Verify:
dig TXT google._domainkey.example.com

DMARC via TXT

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"

Service and Verification Records

SRV Record (Service Discovery)

SRV records define the location (hostname + port) of services. Used by SIP, XMPP, Kubernetes, and other service-discovery systems:

# Format: _service._proto.domain. TTL IN SRV priority weight port target
_sip._tcp.example.com. 3600 IN SRV 10 20 5060 sip1.example.com.
_sip._tcp.example.com. 3600 IN SRV 10 80 5060 sip2.example.com.
_xmpp-client._tcp.example.com. 3600 IN SRV 5 0 5222 jabber.example.com.

# Kubernetes external-dns uses SRV for headless service discovery

TXT Record (Multi-purpose)

TXT records are freeform text used for many verification purposes:

# Google Search Console verification:
example.com. IN TXT "google-site-verification=abc123xyz"

# GitHub verification:
example.com. IN TXT "github-pages-verification=abc123"

# Multiple TXT records are valid for the same name:
example.com. IN TXT "v=spf1 ..."
example.com. IN TXT "google-site-verification=..."
example.com. IN TXT "MS=ms12345678"  # Microsoft 365 verification

CAA Record (Certificate Authority Authorization)

CAA records restrict which certificate authorities (CAs) can issue SSL certificates for your domain. This prevents mis-issuance:

# Allow only Let's Encrypt and DigiCert:
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issue "digicert.com"
example.com. IN CAA 0 iodef "mailto:[email protected]"

# Verify:
dig CAA example.com

Advanced Records

NS Record (Name Server Delegation)

NS records delegate a domain or subdomain to specific name servers:

example.com.     IN NS ns1.nameserver.com.
example.com.     IN NS ns2.nameserver.com.

# Subdomain delegation to different DNS provider:
dev.example.com. IN NS ns1.route53.amazonaws.com.

SOA Record (Start of Authority)

Every DNS zone has exactly one SOA record that contains zone metadata:

example.com. IN SOA ns1.example.com. admin.example.com. (
    2026022601  ; Serial (YYYYMMDDnn)
    3600        ; Refresh (secondary NS poll interval)
    900         ; Retry
    604800      ; Expire
    300         ; Minimum TTL (negative caching)
)

PTR Record (Reverse DNS)

PTR records map IP addresses back to hostnames. Used by mail servers to verify sender identity and by logging systems:

# Reverse DNS is in the in-addr.arpa zone (IPv4 address reversed):
10.113.0.203.in-addr.arpa. IN PTR mail.example.com.

# Lookup:
dig -x 203.0.113.10
host 203.0.113.10

# PTR records are managed by the IP owner (your ISP or cloud provider),
# not your DNS provider. Set them via AWS EC2 console, Hetzner PTR settings, etc.

Common Mistakes

Mistake	Symptom	Fix
CNAME at zone apex	DNS validation error	Use ALIAS/ANAME or Cloudflare proxied A record
SPF > 10 lookups	SPF `permerror`, email rejected	Flatten `include:` entries, use SPF macros
TTL too high during migration	Changes take hours to propagate	Lower TTL to 300 a week before changing
Missing AAAA record	IPv6 users get errors	Add AAAA alongside every A record
PTR mismatch	Mail servers reject your IP	Set PTR to match your sending hostname

Summary

DNS record types each serve a specific purpose in the internet infrastructure. Master A/AAAA for addressing, CNAME for aliasing, MX for email routing, TXT for authentication and verification, and the advanced types (SRV, CAA, PTR) for security and service discovery. The most important operational habit is lowering TTL before any migration and raising it again once stable.