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

DNS translates domain names into addresses that machines can use. According to Verisign’s Domain Name Industry Brief (Q4 2025), over 359 million domain names are registered globally, and every single one relies on DNS records to function. Yet most developers only touch DNS when something breaks.

This guide covers every record type you’ll encounter in practice. Each section shows the real dig output, explains when you’d use the record, and flags the mistakes that cause outages. Bookmark this one. DNS problems always happen at 2 AM.

network tools collection

Look Up DNS Records for Any Domain

Query A, AAAA, MX, TXT, NS, and CNAME records for any domain instantly. No command line needed.

What Are DNS Records?

DNS records are instructions stored in authoritative nameservers that tell the internet how to handle requests for your domain. The Internet Systems Consortium (ISC) maintains BIND, which serves as the reference DNS implementation and handles roughly 10% of global DNS traffic according to ISC’s own reporting. Every DNS record has a type, a name, a value, and a TTL (time to live).

When someone types example.com into a browser, a recursive resolver queries authoritative nameservers for the relevant records. The resolver caches the response for the duration of the TTL. This is why DNS changes don’t propagate instantly.

Here’s what a basic DNS query looks like:

$ dig example.com

;; ANSWER SECTION:
example.com.        86400   IN  A   93.184.216.34

That response contains one A record. The 86400 is the TTL in seconds (24 hours). IN means the internet class. The A is the record type. And 93.184.216.34 is the IPv4 address.

understanding domain registration

What Is an A Record?

A records are the most fundamental DNS record type, mapping a domain name to an IPv4 address. According to Cloudflare Radar (2025), A record queries represent approximately 45% of all DNS queries processed globally. Without an A record, browsers can’t find your server.

How A records work

An A record contains exactly one IPv4 address. If you need redundancy or load balancing, you add multiple A records for the same domain. DNS resolvers will rotate through them (round-robin) or return different subsets to different clients.

$ dig example.com A

;; ANSWER SECTION:
example.com.        86400   IN  A   93.184.216.34

Large sites often return multiple A records:

$ dig google.com A

;; ANSWER SECTION:
google.com.         300     IN  A   142.250.80.46

Notice the TTL difference. example.com uses 86400 seconds (24 hours). Google uses 300 seconds (5 minutes). Shorter TTLs let you failover faster but increase DNS query volume.

When to use A records

Use A records when you need to point a domain or subdomain directly at an IP address. This is the default choice for your root domain (example.com), since CNAME records can’t be used at the zone apex. A common mistake: setting an A record and a CNAME on the same name. This violates RFC 1034 and causes unpredictable resolution behavior. Some resolvers silently drop the CNAME. Others drop the A record. Don’t mix them.

Common A record mistakes

• Setting a TTL that’s too long (86400+) before a migration, then waiting hours for propagation
• Pointing A records at an IP that belongs to a provider you’ve left
• Forgetting to update A records when your server’s IP changes (use CNAME for subdomains instead)

check your DNS records

What Is an AAAA Record?

AAAA records map domain names to IPv6 addresses. Google’s IPv6 Statistics (2025) show that over 43% of Google users connect via IPv6, up from 25% in 2019. If you’re not serving AAAA records, you’re potentially forcing a significant portion of users through IPv4 translation layers.

How AAAA records work

The name “AAAA” (quad-A) comes from the fact that IPv6 addresses are four times the size of IPv4 addresses (128 bits versus 32 bits). The record syntax is identical to an A record, just with an IPv6 address.

$ dig example.com AAAA

;; ANSWER SECTION:
example.com.        86400   IN  AAAA    2606:2800:21f:cb07:6820:80da:af6b:8b2c

When to use AAAA records

Add AAAA records alongside your A records. This is called dual-stack, and it’s the recommended approach. Modern browsers prefer IPv6 when available, using the “Happy Eyeballs” algorithm (RFC 8305) to race IPv4 and IPv6 connections and pick the faster one.

Should you worry about IPv6 if your hosting provider doesn’t support it? Not urgently. But major cloud providers (AWS, GCP, Cloudflare, Azure) all support IPv6 now. If yours doesn’t, that’s a reason to ask questions. Many developers skip AAAA records because “IPv6 isn’t mainstream yet.” In reality, mobile carriers like T-Mobile and Reliance Jio default to IPv6-only networks with NAT64 for IPv4 fallback. Skipping AAAA records means your site takes a slower path for a growing share of mobile users.

What Is a CNAME Record?

CNAME records create an alias from one domain name to another. Akamai’s State of the Internet report (2025) notes that CDN-heavy architectures rely heavily on CNAME chains for traffic routing across edge networks. When a resolver hits a CNAME, it restarts the query using the target domain.

How CNAME records work

A CNAME record says “this name is actually an alias for that other name.” The resolver follows the alias and looks up the target domain’s A or AAAA records instead.

$ dig www.example.com CNAME

;; ANSWER SECTION:
www.example.com.    86400   IN  CNAME   example.com.

This means www.example.com is an alias for example.com. The resolver will then query example.com for its A record to get the actual IP.

The zone apex restriction

Here’s the rule that trips up everyone: you cannot place a CNAME at the zone apex (the bare domain like example.com). RFC 1034 specifies that a CNAME cannot coexist with any other record type. Since the zone apex already has SOA and NS records, a CNAME there would violate the spec.

When to use CNAME records

CNAME records are ideal for subdomains that point to external services:

• blog.example.com → example.ghost.io (hosted blog)
• shop.example.com → shops.myshopify.com (ecommerce)
• status.example.com → abc123.statuspage.io (status page)

The tradeoff: CNAME records add one extra DNS lookup. For most use cases this is negligible. For latency-critical subdomains, consider using A records instead.

look up CNAME chains

What Is an MX Record?

MX records tell the internet where to deliver email for your domain. According to Google Workspace admin documentation (2025), incorrect MX records are the number one cause of email delivery failures during domain migrations. Get these wrong and your email silently vanishes.

How MX records work

MX records have a priority value (lower number equals higher priority) and point to a mail server hostname. When someone sends email to user@example.com, their mail server queries the MX records for example.com and tries the server with the lowest priority number first.

$ dig example.com MX

;; ANSWER SECTION:
example.com.        86400   IN  MX  0 .

That . (dot) is a null MX record, defined in RFC 7505. It means “this domain does not accept email.” Here’s what a real mail setup looks like:

$ dig google.com MX

;; ANSWER SECTION:
google.com.     300   IN  MX  10 smtp.google.com.
google.com.     300   IN  MX  20 smtp2.google.com.
google.com.     300   IN  MX  30 smtp3.google.com.
google.com.     300   IN  MX  40 smtp4.google.com.

Mail servers try smtp.google.com first (priority 10). If it’s unavailable, they try smtp2.google.com (priority 20), and so on.

Common MX record mistakes

• Pointing MX records at an IP address (they must point to a hostname)
• Pointing MX records at a CNAME (this technically violates RFC 2181, though some servers tolerate it)
• Forgetting to add MX records after moving to a new DNS provider
• Not testing with MX Lookup after making changes We’ve seen dozens of support tickets where email “stopped working” after a DNS migration. In nearly every case, the old MX records weren’t copied to the new provider. Always export your full DNS zone before switching nameservers.

What Is a TXT Record?

TXT records store arbitrary text data and have become the workhorse of email security and domain verification. A Valimail report (2025) found that domains with properly configured SPF, DKIM, and DMARC records, all stored as TXT records, see 99.5% fewer spoofing attempts compared to unprotected domains.

How TXT records work

TXT records hold free-form text strings up to 255 characters per string (multiple strings can be concatenated). They were originally designed for human-readable notes, but today they’re used almost exclusively for machine-readable policies.

$ dig example.com TXT

;; ANSWER SECTION:
example.com.        86400   IN  TXT "v=spf1 -all"

That SPF record says “no servers are authorized to send email for example.com.” Any email claiming to come from @example.com should be rejected.

SPF records

SPF (Sender Policy Framework) defines which servers can send email on behalf of your domain. It’s defined in RFC 7208.

"v=spf1 include:_spf.google.com ~all"

This says: “Servers listed in Google’s SPF record are authorized. Everything else gets a soft fail.” The ~all is a soft fail. Use -all for hard fail (recommended once you’ve confirmed your setup works).

DKIM records

DKIM (DomainKeys Identified Mail) uses public-key cryptography to sign outgoing emails. The public key is stored in a TXT record:

$ dig selector._domainkey.example.com TXT

;; ANSWER SECTION:
selector._domainkey.example.com. 300 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGS..."

The sending server signs each email with the private key. The receiving server retrieves the public key from DNS and verifies the signature. If it doesn’t match, the email was modified in transit or sent by someone without the private key.

DMARC records

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together and tells receivers what to do with messages that fail both checks:

$ dig _dmarc.example.com TXT

;; ANSWER SECTION:
_dmarc.example.com. 86400 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

The p=reject policy means “if SPF and DKIM both fail, reject the message entirely.” The rua tag specifies where to send aggregate reports so you can monitor authentication results.

Domain verification TXT records

Services like Google Search Console, Microsoft 365, and Let’s Encrypt use TXT records for domain ownership verification:

"google-site-verification=abc123def456"
"MS=ms12345678"

These are safe to leave in place after verification. They don’t affect anything except proving you control the domain.

What Is an NS Record?

NS records delegate authority for a DNS zone to specific nameservers. According to ICANN’s CZDS data (2025), the average .com domain uses 2.3 nameservers. Having at least two NS records is a requirement for most registrars and a best practice for redundancy.

How NS records work

NS records say “the authoritative answers for this zone live on these nameservers.” They appear at the zone apex and can also appear at subdomain boundaries to delegate sub-zones.

$ dig example.com NS

;; ANSWER SECTION:
example.com.        86400   IN  NS  a.iana-servers.net.
example.com.        86400   IN  NS  b.iana-servers.net.

Delegation vs. glue records

When a nameserver’s hostname lives within the zone it serves (e.g., ns1.example.com serves example.com), you have a circular dependency. Glue records, A records for the nameservers themselves, are added at the parent zone (the TLD registry) to break this loop.

If your nameservers are external (like ns1.cloudflare.com), glue records aren’t needed. The resolver can look up Cloudflare’s nameserver IPs through Cloudflare’s own parent zone.

check nameservers for any domain

What Is an SOA Record?

SOA records contain metadata about the DNS zone itself. Every zone must have exactly one SOA record. RFC 1035 defines it as mandatory, and zones without a valid SOA record will fail to load on compliant nameservers.

How SOA records work

$ dig example.com SOA

;; ANSWER SECTION:
example.com.        86400   IN  SOA sns.dns.icann.org. noc.dns.icann.org. (
                            2024120101  ; serial
                            7200        ; refresh (2 hours)
                            3600        ; retry (1 hour)
                            1209600     ; expire (14 days)
                            3600        ; minimum TTL (1 hour)
                            )

The fields, broken down:

• Primary nameserver (sns.dns.icann.org.): the master nameserver for the zone
• Admin email (noc.dns.icann.org.): replace the first dot with @ to get noc@dns.icann.org
• Serial: version number, incremented on every zone change (YYYYMMDDNN format is conventional)
• Refresh: how often secondary nameservers check for updates
• Retry: how long to wait before retrying a failed refresh
• Expire: how long secondaries serve data without contacting the primary
• Minimum TTL: the default negative caching TTL (how long to cache “this record doesn’t exist”)

Most DNS providers manage SOA records automatically. You rarely edit them directly unless you’re running your own nameservers.

What Is a PTR Record?

PTR records perform reverse DNS lookups, mapping an IP address back to a hostname. According to Spamhaus (2025), missing PTR records are one of the most common reasons mail servers reject incoming connections. If your server sends email, it needs a PTR record.

How PTR records work

PTR records live in special reverse DNS zones. For IPv4, the zone is in-addr.arpa. The IP octets are reversed:

$ dig -x 93.184.216.34

;; ANSWER SECTION:
34.216.184.93.in-addr.arpa. 86400 IN PTR example.com.

For IPv6, each nibble (hex digit) is reversed under ip6.arpa.

When PTR records matter

PTR records are critical for two things:

1. Email deliverability: Mail servers check that the sending IP has a PTR record matching the HELO hostname. No match, no delivery (or straight to spam).
2. Logging and diagnostics: Tools like traceroute and server logs use reverse DNS to show hostnames instead of raw IPs.

You typically can’t set PTR records through your domain registrar. They’re managed by whoever owns the IP address block, usually your hosting provider. Contact their support to set PTR records for your server IPs.

What Is an SRV Record?

SRV records locate services on specific hosts and ports. RFC 2782 defines them, and they’re used extensively by protocols like SIP (VoIP), XMPP (chat), LDAP (directory services), and Microsoft Active Directory.

How SRV records work

SRV records have a specific naming format: _service._protocol.domain. They include priority, weight, port, and target hostname.

$ dig _sip._tcp.example.com SRV

;; ANSWER SECTION:
_sip._tcp.example.com. 86400 IN SRV 10 60 5060 sip.example.com.
_sip._tcp.example.com. 86400 IN SRV 10 40 5060 sip2.example.com.

Breaking down 10 60 5060 sip.example.com:

• Priority: 10 (lower is preferred, like MX)
• Weight: 60 (for load distribution among same-priority records)
• Port: 5060 (the TCP/UDP port for the service)
• Target: sip.example.com (the server hosting the service)

Weight allows proportional load balancing. In the example above, 60% of traffic goes to sip.example.com and 40% to sip2.example.com when both have the same priority.

When to use SRV records

You’ll encounter SRV records when setting up:

• Microsoft 365 / Teams (autodiscover, SIP federation)
• VoIP/SIP services
• XMPP chat servers
• Minecraft servers (yes, really, _minecraft._tcp.example.com)
• CalDAV / CardDAV services

Most web applications don’t use SRV records. Browsers don’t support SRV lookups for HTTP. If you’re doing standard web hosting, you won’t need them.

What Is a CAA Record?

CAA records specify which Certificate Authorities are allowed to issue SSL/TLS certificates for your domain. Qualys SSL Labs (2025) reports that CAA record adoption has reached approximately 12.8% among the top 150,000 sites, up from 5% in 2020.

How CAA records work

$ dig example.com CAA

;; ANSWER SECTION:
example.com.        86400   IN  CAA 0 issue "letsencrypt.org"
example.com.        86400   IN  CAA 0 issuewild "letsencrypt.org"
example.com.        86400   IN  CAA 0 iodef "mailto:security@example.com"

The three tag types:

• issue: CAs authorized to issue standard certificates
• issuewild: CAs authorized to issue wildcard certificates
• iodef: Contact email/URL for policy violation reports

If a CA receives a certificate request for your domain and your CAA records don’t list that CA, they must refuse to issue it. This prevents unauthorized certificate issuance, whether from compromised CA accounts or social engineering attacks.

When to add CAA records

Add CAA records as soon as you know which CA you use. If you use Let’s Encrypt exclusively, your CAA records should only authorize letsencrypt.org. If you use multiple CAs (maybe one for your CDN and another for your origin), add entries for each. CAA records are checked in real-time during certificate issuance, not cached long-term by CAs. This means you can update your CAA records right before a migration and they’ll take effect immediately. Unlike most DNS changes, there’s no propagation delay to worry about from the CA’s perspective.

How Do You Choose the Right Record Type?

Picking the wrong record type is behind most DNS misconfigurations. According to a Catchpoint (2025) study, DNS misconfigurations account for 16% of all website downtime incidents. The decision tree is simpler than it looks.

Pointing a domain at a server? Use A (IPv4) and AAAA (IPv6) records together.

Creating a subdomain alias? Use CNAME. But never at the zone apex.

Setting up email? You need MX records for routing, plus TXT records for SPF, DKIM, and DMARC.

Delegating a subdomain to different nameservers? Use NS records.

Restricting SSL certificate issuance? Use CAA records.

Running a non-HTTP service on a custom port? Use SRV records.

When in doubt, query what similar services use. Run dig against a domain you know works correctly with the same provider. DNS is one of those areas where copying a known-good configuration beats designing from scratch. We’ve found that most DNS issues come from three sources: stale records from old providers, CNAME-at-apex violations, and missing email authentication records after migrations. A quarterly audit of your DNS zone takes 15 minutes and prevents hours of debugging later.

Frequently Asked Questions

What is the difference between an A record and a CNAME record?

An A record maps a domain directly to an IPv4 address (like 93.184.216.34). A CNAME maps a domain to another domain name as an alias. Use A records for root domains and CNAME records for subdomains that need to track another hostname. According to Cloudflare Radar (2025), A record queries outnumber CNAME queries by roughly 6 to 1 in global DNS traffic.

How long does it take for DNS changes to propagate?

DNS propagation depends on the TTL (Time to Live) of the old record. If your A record had a TTL of 86400 (24 hours), resolvers worldwide may serve the old value for up to 24 hours. In practice, most changes propagate within 1-4 hours according to DNSChecker analysis. Lower your TTL to 300 seconds before making changes, wait for the old TTL to expire, then make the change.

Do I need both A and AAAA records?

You should have both if your server supports IPv6. Google’s IPv6 statistics (2025) show 43% of users connecting over IPv6. Having both record types (dual-stack) ensures the fastest connection path for all users. If your hosting provider doesn’t support IPv6, an A record alone is fine for now.

What happens if MX records are missing?

Without MX records, sending servers fall back to the A record for the domain, attempting to deliver email directly to that IP on port 25. This almost never works because web servers don’t run mail software. The result: bounced emails or silent delivery failures. Always set MX records explicitly, even if you use a null MX (0 .) to indicate the domain doesn’t accept email.

Can I have multiple TXT records on the same domain?

Yes. Unlike CNAME records, multiple TXT records on the same name is perfectly valid and common. Most domains have at least three: one for SPF, one or more for domain verification, and one for DMARC (though DMARC lives at _dmarc.yourdomain.com). The only caveat: you should have only one SPF record per domain. If you need to authorize multiple sending sources, combine them into a single SPF string using include mechanisms.

look up any domain’s DNS records verify MX configuration check domain registration details