DNS Record Types Explained: A, AAAA, CNAME, MX, and More

Every time you type a domain name into a browser, a complex chain of lookups happens in milliseconds to translate that human-readable name into an IP address a computer can route to. Behind that process is the Domain Name System — and it relies on a variety of record types, each serving a different purpose.

This guide walks through every major DNS record type, explains what it does, and shows you how to query them yourself.

How DNS Works

DNS is often called the phonebook of the internet, but it's more like a distributed, hierarchical database. When your browser needs to resolve example.com, here's what happens:

1. Stub resolver — Your operating system checks its local cache. If it already resolved example.com recently, it returns the cached IP immediately.
2. Recursive resolver — If there's no cache hit, the query goes to a recursive resolver (typically run by your ISP or a public provider like Cloudflare at 1.1.1.1 or Google at 8.8.8.8). This server does the heavy lifting.
3. Root nameservers — The recursive resolver asks one of the 13 root nameserver clusters, "Who handles .com?" The root responds with the address of the .com TLD nameservers.
4. TLD nameservers — The resolver then asks the .com nameserver, "Who handles example.com?" It responds with the authoritative nameservers for that domain.
5. Authoritative nameserver — Finally, the resolver queries the authoritative nameserver, which holds the actual DNS records for example.com. It returns the A record (or whichever record was requested).

The recursive resolver caches the result according to the record's TTL (Time To Live), so subsequent queries skip most of these steps.

A and AAAA Records

These are the most fundamental DNS record types. They map a domain name directly to an IP address.

A Records (IPv4)

An A record maps a domain to a 32-bit IPv4 address. This is the record your browser ultimately needs to establish a TCP connection.

example.com.    300    IN    A    93.184.216.34

You can have multiple A records for the same domain. This is called round-robin DNS and provides basic load balancing — resolvers rotate through the addresses, distributing traffic across multiple servers.

app.example.com.    300    IN    A    203.0.113.10
app.example.com.    300    IN    A    203.0.113.11
app.example.com.    300    IN    A    203.0.113.12

AAAA Records (IPv6)

An AAAA record (pronounced "quad-A") maps a domain to a 128-bit IPv6 address. As IPv4 address space runs out, AAAA records are becoming increasingly important.

example.com.    300    IN    AAAA    2606:2800:220:1:248:1893:25c8:1946

Most domains should have both A and AAAA records. When a client supports IPv6, it will prefer the AAAA record. This dual-stack setup ensures compatibility with both protocols.

CNAME Records

A CNAME (Canonical Name) record creates an alias from one domain name to another. Instead of pointing to an IP address, it points to a different domain name, which is then resolved in turn.

www.example.com.    3600    IN    CNAME    example.com.
blog.example.com.   3600    IN    CNAME    mysite.hosting.com.

When a resolver encounters a CNAME, it follows the chain: it resolves the target domain to get the final IP address. CNAME records can chain — a.example.com could CNAME to b.example.com, which CNAMEs to c.example.com, which finally has an A record — but long chains add latency and are generally discouraged.

When to Use CNAME vs A Records

• Use CNAME when pointing to a service that might change its IP address (CDNs, cloud platforms, SaaS providers). If Cloudflare or AWS changes their edge IPs, your CNAME still works.
• Use A records when you know the exact IP and control the server, or when you need the best possible resolution speed (one fewer lookup step).

MX Records

MX (Mail Exchanger) records tell the world which mail servers accept email for your domain. When someone sends an email to user@example.com, the sending mail server looks up the MX records for example.com to find where to deliver it.

example.com.    3600    IN    MX    10 mail1.example.com.
example.com.    3600    IN    MX    20 mail2.example.com.
example.com.    3600    IN    MX    30 mail3.backup-mx.com.

The number before the hostname is the priority (also called preference). Lower numbers have higher priority. In the example above, mail servers will try mail1.example.com first. If it's unavailable, they fall back to mail2.example.com, and then to mail3.backup-mx.com.

If two MX records share the same priority, sending servers will distribute mail between them randomly, providing a form of load balancing.

TXT Records

TXT records store arbitrary text data associated with a domain. Originally intended for human-readable notes, they've become essential infrastructure for email authentication, domain verification, and more.

SPF (Sender Policy Framework)

SPF records declare which IP addresses and servers are authorised to send email on behalf of your domain. Receiving mail servers check the sender's IP against your SPF record to detect spoofing.

example.com.    3600    IN    TXT    "v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.0/24 -all"

The -all at the end means "reject anything not explicitly listed." Use ~all (soft fail) during testing, and -all (hard fail) in production.

DKIM (DomainKeys Identified Mail)

DKIM uses public-key cryptography to sign outgoing emails. The public key is published as a TXT record, and receiving servers use it to verify the signature.

selector1._domainkey.example.com.    3600    IN    TXT    "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA..."

DMARC (Domain-based Message Authentication)

DMARC ties SPF and DKIM together with a policy that tells receivers what to do when authentication fails (report, quarantine, or reject).

_dmarc.example.com.    3600    IN    TXT    "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100"

Domain Verification

Services like Google Search Console, Microsoft 365, and various SaaS platforms ask you to prove domain ownership by adding a specific TXT record:

example.com.    3600    IN    TXT    "google-site-verification=abc123..."
example.com.    3600    IN    TXT    "ms=ms12345678"

A domain can have multiple TXT records, and this is perfectly normal — you'll often see SPF, DKIM, DMARC, and several verification tokens all coexisting.

NS Records

NS (Name Server) records specify which DNS servers are authoritative for a domain. They are the backbone of DNS delegation — the mechanism by which the global DNS hierarchy works.

example.com.    86400    IN    NS    ns1.cloudflare.com.
example.com.    86400    IN    NS    ns2.cloudflare.com.

When you register a domain and point it to Cloudflare (or any DNS provider), you're setting NS records at the registrar level. These tell the .com TLD servers, "For example.com, go ask Cloudflare."

You can also use NS records to delegate subdomains to different nameservers. For example, if your dev.example.com subdomain is managed by a different team with their own DNS provider:

dev.example.com.    3600    IN    NS    ns1.dev-dns-provider.com.
dev.example.com.    3600    IN    NS    ns2.dev-dns-provider.com.

Every domain must have at least two NS records for redundancy. If one nameserver is unreachable, resolvers will try the next one.

SOA Records

The SOA (Start of Authority) record is the first record in every DNS zone. It contains administrative information about the zone and controls how secondary DNS servers synchronise with the primary.

example.com.    86400    IN    SOA    ns1.cloudflare.com. dns.cloudflare.com. (
                                        2026032601  ; Serial number
                                        10000       ; Refresh (seconds)
                                        2400        ; Retry (seconds)
                                        604800      ; Expire (seconds)
                                        3600        ; Minimum TTL (seconds)
                                    )

Here's what each field means:

Field	Description
ns1.cloudflare.com.	Primary nameserver for the zone
dns.cloudflare.com.	Admin email (the first dot replaces the @ sign, so this is dns@cloudflare.com)
2026032601	Serial number — incremented on every zone change (often in YYYYMMDDNN format)
10000	Refresh — how often secondaries check for updates
2400	Retry — how long to wait before retrying a failed refresh
604800	Expire — how long secondaries serve data without a successful refresh (7 days here)
3600	Minimum TTL — the default TTL for negative responses (NXDOMAIN)

The serial number is critical for zone transfers. Secondary nameservers compare it against their cached version — if the primary's serial is higher, they pull a fresh copy of the zone.

SRV Records

SRV (Service) records enable service discovery by advertising the location of specific services. Unlike A records which just map a name to an IP, SRV records include the port number and support priority and weight for load balancing.

The format is:

_service._protocol.name.    TTL    IN    SRV    priority weight port target

For example, a SIP (VoIP) service and an XMPP (chat) service:

_sip._tcp.example.com.     3600  IN  SRV  10 60 5060 sip1.example.com.
_sip._tcp.example.com.     3600  IN  SRV  10 40 5060 sip2.example.com.
_sip._tcp.example.com.     3600  IN  SRV  20  0 5060 sip-backup.example.com.

_xmpp-client._tcp.example.com.  3600  IN  SRV  5 0 5222 chat.example.com.

In this example, priority works like MX — lower values are tried first. Within the same priority level, weight controls the distribution: 60% of traffic goes to sip1 and 40% to sip2. If both are down, sip-backup (priority 20) takes over.

SRV records are widely used by LDAP, XMPP, SIP, CalDAV, CardDAV, and Microsoft Active Directory (e.g., _ldap._tcp.dc._msdcs.example.com).

PTR Records

PTR (Pointer) records are the reverse of A records. Instead of mapping a domain to an IP, they map an IP address back to a domain name. This is called reverse DNS (rDNS).

PTR records live in a special zone under in-addr.arpa (for IPv4) or ip6.arpa (for IPv6). The IP address is written in reverse order:

# Forward: example.com → 93.184.216.34
example.com.    300    IN    A    93.184.216.34

# Reverse: 93.184.216.34 → example.com
34.216.184.93.in-addr.arpa.    3600    IN    PTR    example.com.

Reverse DNS matters most for email. Many mail servers reject or flag messages from IPs without a valid PTR record, because spammers rarely set up rDNS. If you run your own mail server, a matching PTR record is essential for deliverability.

DNS-over-HTTPS (DoH)

Traditional DNS queries are sent in plaintext over UDP port 53. Anyone on the network path — your ISP, a coffee shop's Wi-Fi, or a man-in-the-middle attacker — can see exactly which domains you're looking up. DNS-over-HTTPS (DoH) solves this by wrapping DNS queries inside encrypted HTTPS connections.

How DoH Works

Instead of sending a raw UDP packet to a DNS resolver, your client sends an HTTPS request (typically a GET or POST) to a DoH endpoint. The DNS query and response are encoded in the standard DNS wire format but transported over TLS-encrypted HTTP/2. To the network, it looks like ordinary HTTPS traffic.

Public DoH Endpoints

Provider	Endpoint
Cloudflare	https://cloudflare-dns.com/dns-query
Google	https://dns.google/dns-query
Quad9	https://dns.quad9.net/dns-query

You can query a DoH endpoint directly with curl:

# Query Cloudflare DoH for A records of example.com
curl -s -H "accept: application/dns-json" \
  "https://cloudflare-dns.com/dns-query?name=example.com&type=A" | jq

# Query Google DoH
curl -s "https://dns.google/resolve?name=example.com&type=A" | jq

DoH is supported natively in all major browsers (Firefox, Chrome, Safari, Edge) and in iOS, macOS, Android, and Windows. BoltKit's DNSLookup tool uses DoH under the hood to perform record lookups directly from your device without exposing your queries to the local network.

Practical: Looking Up DNS Records

Here are the essential command-line tools for querying DNS records. These are invaluable for debugging domain configuration, verifying propagation, and understanding how your DNS is set up.

dig

dig (Domain Information Groper) is the most powerful and detailed DNS query tool. It's the go-to for sysadmins and network engineers.

# Query A records
dig example.com A

# Query MX records
dig example.com MX

# Query any specific record type
dig example.com AAAA
dig example.com TXT
dig example.com NS
dig example.com SOA

# Use a specific DNS server (Cloudflare)
dig @1.1.1.1 example.com A

# Short output (just the answer)
dig +short example.com A

# Trace the full resolution path
dig +trace example.com A

# Query for all record types
dig example.com ANY

nslookup

nslookup is simpler and available on virtually every operating system, including Windows.

# Basic lookup
nslookup example.com

# Query specific record type
nslookup -type=MX example.com
nslookup -type=TXT example.com
nslookup -type=CNAME www.example.com

# Use a specific DNS server
nslookup example.com 1.1.1.1

# Reverse DNS lookup
nslookup 93.184.216.34

host

host gives the cleanest, most concise output — ideal for quick checks and scripting.

# Basic lookup
host example.com

# Query specific record type
host -t MX example.com
host -t TXT example.com
host -t NS example.com

# Reverse DNS
host 93.184.216.34

# Verbose output
host -v example.com