DNS Record Types Explained: Complete Reference Guide
Complete reference for every DNS record type — what each one does, when to use it, example values, and common configuration mistakes.
DNS Record Types Explained: Complete Reference Guide
DNS records are the instructions that tell the internet how to reach your domain. Each record type serves a specific purpose. Understanding them is essential for anyone managing domains, hosting, or email.
A Record — IPv4 Address
What it does: Maps a hostname to an IPv4 address. This is the most fundamental DNS record — it tells browsers and other clients where your website lives.
Example: example.com → A → 203.0.113.10 www.example.com → A → 203.0.113.10
When to use it: For any hostname that needs to point to an IPv4 address. Your website's root domain and www subdomain both typically need A records.
Common mistake: Setting an A record at a subdomain that should be a CNAME. If the IP needs to change, you have to update multiple A records instead of one.
AAAA Record — IPv6 Address
What it does: Same as an A record but for IPv6 addresses.
Example: example.com → AAAA → 2001:db8::1
When to use it: When your server has an IPv6 address and you want clients with IPv6 connectivity to use it. Modern servers typically have both A and AAAA records.
MX Record — Mail Exchanger
What it does: Specifies which mail servers handle email for your domain. Includes a priority number (lower = higher priority).
Example: example.com → MX 10 → mail.example.com example.com → MX 20 → mail2.example.com
When to use it: Required for any domain that receives email. Multiple MX records provide redundancy.
Critical rule: MX records must point to A record hostnames, never to CNAMEs. This is prohibited by RFC 2181 and causes delivery failures with many mail servers.
TXT Record — Text
What it does: Stores arbitrary text data. Used for many purposes including email authentication, domain verification, and service configuration.
Common TXT record uses:
SPF (email authorization): example.com → TXT → "v=spf1 include:_spf.google.com ~all"
DKIM (email signing key): selector._domainkey.example.com → TXT → "v=DKIM1; k=rsa; p=MIGf..."
DMARC (email policy): _dmarc.example.com → TXT → "v=DMARC1; p=reject; rua=mailto:[email protected]"
Domain verification: example.com → TXT → "google-site-verification=abc123..."
CNAME Record — Canonical Name (Alias)
What it does: Creates an alias from one hostname to another. When a resolver looks up a CNAME, it follows the alias chain to get the final A/AAAA record.
Example: www.example.com → CNAME → example.com shop.example.com → CNAME → mystore.myshopify.com
When to use it: For subdomains that should point to another hostname. Common for www, CDN subdomains, and third-party service integrations.
Critical limitation: A CNAME cannot be placed at the zone apex (the root domain itself — example.com). This is prohibited by RFC 1034. You cannot have example.com → CNAME → something.com. For this use case, many DNS providers offer CNAME flattening (ALIAS or ANAME records).
CNAME chains: A CNAME pointing to another CNAME is technically valid but increases lookup latency. Keep chains to one hop if possible.
NS Record — Nameserver
What it does: Specifies the authoritative nameservers for a domain. These are the servers that hold the definitive copy of all DNS records for the domain.
Example: example.com → NS → ns1.cloudflare.com example.com → NS → ns2.cloudflare.com
When to use it: Set by your registrar when you delegate DNS to a provider. You typically update NS records when migrating to a new DNS provider. NS changes can take 24-48 hours to propagate.
Important: Always have at least two NS records pointing to different physical servers. Single-NS delegation creates a single point of failure.
SOA Record — Start of Authority
What it does: The first record in a DNS zone. Contains essential zone metadata including the primary nameserver, admin email, and timing parameters.
Key SOA fields:
- Serial number — incremented on every zone change; secondary servers use this to detect updates
- Refresh — how often secondary servers check for updates (seconds)
- Retry — how long a secondary waits before retrying after a failed refresh
- Expire — how long a secondary continues serving data if it cannot reach the primary
- Minimum TTL — floor for negative caching (NXDOMAIN responses)
When to use it: Created automatically by your DNS provider. You rarely edit it directly, though some providers let you set the minimum TTL.
CAA Record — Certification Authority Authorization
What it does: Specifies which Certificate Authorities are allowed to issue SSL certificates for your domain. Any CA that receives a certificate request must check CAA records before issuing.
Example: example.com → CAA → 0 issue "letsencrypt.org" example.com → CAA → 0 issuewild "sectigo.com"
Flags:
- "issue" — authorizes the CA to issue single-name certificates
- "issuewild" — authorizes the CA to issue wildcard certificates
- "iodef" — email address to report policy violations
When to use it: Adds a layer of protection against unauthorized certificate issuance. If a CAA record exists and a CA not listed attempts to issue a certificate, Certificate Transparency logs will flag it.
SRV Record — Service Locator
What it does: Specifies hostname and port for specific services. Used by protocols that need to discover service endpoints via DNS.
Format: _service._protocol.name → priority weight port hostname
Example: _sip._tcp.example.com → SRV → 10 20 5060 sipserver.example.com
When to use it: Required for some services like SIP (VoIP), XMPP (chat), Microsoft Teams, and some email client autodiscovery configurations. Most web services don't need SRV records.
PTR Record — Pointer (Reverse DNS)
What it does: Maps an IP address back to a hostname. The reverse of an A record — used for reverse DNS lookups.
Where it lives: In the special in-addr.arpa zone, managed by whoever owns the IP address block (usually your hosting provider or ISP).
Example: 10.113.0.203.in-addr.arpa → PTR → mail.example.com
When it matters: Mail servers often check PTR records to verify that the sending IP's reverse DNS matches the hostname the server presents. A missing or mismatched PTR record can cause email delivery problems. Request PTR record setup from your hosting provider.
Quick Reference Table
| Type | Purpose | At Root Domain? |
|---|---|---|
| A | IPv4 address | Yes |
| AAAA | IPv6 address | Yes |
| MX | Email routing | Yes |
| TXT | Text/authentication | Yes |
| CNAME | Alias to hostname | No (subdomains only) |
| NS | Nameserver delegation | Yes |
| SOA | Zone authority | Yes (auto-created) |
| CAA | CA authorization | Yes |
| SRV | Service discovery | Subdomains only |
| PTR | Reverse DNS | Managed by IP owner |