Every DNS Record Type Explained: A, AAAA, CNAME, MX, TXT, NS and More

DNS (Domain Name System) is the internet's phone book — it translates human-readable domain names like example.com into IP addresses that computers use to route traffic. The system relies on multiple types of DNS records, each serving a distinct purpose. This guide covers every major DNS record type you need to know: what it does, when to use it, real-world examples, and common mistakes to avoid.

What Are DNS Records and How Do They Work?

A DNS record is an entry stored in a DNS zone file on an authoritative name server. When someone types a domain name into a browser, DNS resolvers query these records to find the correct IP address or other configuration data. Each record has a type, a name, a value, and a TTL (Time To Live) that controls how long resolvers cache the result before re-querying.

DNS records are managed through your domain registrar's DNS panel, a third-party DNS provider such as Cloudflare, or hosting control panels like cPanel and DirectAdmin. Changes propagate globally based on the TTL — lower TTL means faster propagation but more DNS queries.

A Record — The Most Essential DNS Record

An A record (Address record) maps a hostname to an IPv4 address. It is the most fundamental record type and the first one you will configure for any website.

A Record Examples

example.com.      3600  IN  A  203.0.113.1
www.example.com.  3600  IN  A  203.0.113.1
api.example.com.  3600  IN  A  203.0.113.5

When to Use A Records

• Pointing the root domain (@) to your web server's IP address
• Pointing subdomains like www, mail, or api to specific IPs
• Setting up DirectAdmin or cPanel hosting (pointing the domain at the server IP)
• Any scenario where the target IP is static and known

AAAA Record — IPv6 Address Mapping

The AAAA record (Quad-A) works exactly like an A record but maps a hostname to an IPv6 address. As IPv4 address space depletes, IPv6 becomes increasingly important for modern infrastructure.

AAAA Record Example

example.com.  3600  IN  AAAA  2001:db8:85a3::8a2e:370:7334

CNAME Record — Hostname Alias

A CNAME record (Canonical Name) creates an alias from one hostname to another. Instead of pointing to an IP, it points to another hostname, letting DNS resolve the final destination. This is useful when a service's IP address may change but its hostname stays constant.

CNAME Record Examples

www.example.com.   3600  IN  CNAME  example.com.
shop.example.com.  3600  IN  CNAME  myshop.shopify.com.
blog.example.com.  3600  IN  CNAME  myblog.wordpress.com.

Key Restrictions of CNAME Records

• CNAME cannot be used at the root/apex domain (@ or example.com) per RFC 1034
• CNAME cannot coexist with other record types at the same name
• MX records cannot point to a CNAME — they must point to a hostname with an A record
• Chains of CNAMEs add latency; keep them to one hop where possible

MX Record — Email Routing

An MX record (Mail Exchanger) tells DNS which mail server should receive email sent to your domain. MX records include a priority value — the lower the number, the higher the priority. Multiple MX records provide failover.

MX Record Examples

; Generic setup with primary/backup
example.com.  3600  IN  MX  10  mail1.example.com.
example.com.  3600  IN  MX  20  mail2.example.com.

; Google Workspace
example.com.  3600  IN  MX  1   aspmx.l.google.com.
example.com.  3600  IN  MX  5   alt1.aspmx.l.google.com.
example.com.  3600  IN  MX  5   alt2.aspmx.l.google.com.

Important Rules for MX Records

• MX targets must be A records — never point an MX at a CNAME
• Lower priority number = higher preference (1 is preferred over 10)
• Always add corresponding A records for your MX hostnames

TXT Record — Verification and Email Authentication

A TXT record stores arbitrary text data associated with a domain. It is most commonly used for domain ownership verification and the email authentication standards SPF, DKIM, and DMARC that protect against spoofing and phishing.

TXT Record Examples

; SPF — authorize Google to send email for your domain
example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com ~all"

; DMARC — quarantine failing messages and report to admin
_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

; DKIM public key (selector: google)
google._domainkey.example.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0G..."

; Google Search Console verification
example.com.  3600  IN  TXT  "google-site-verification=abc123xyz..."

NS Record — Name Server Delegation

An NS record (Name Server) specifies which DNS servers are authoritative for your domain. When you switch your domain's DNS to Cloudflare or any other provider, you update NS records at your registrar to point to the new name servers.

NS Record Example

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

NS records typically have a long TTL (86400 seconds = 24 hours) because they rarely change. Changing name servers takes 24–48 hours to propagate globally through the DNS hierarchy.

SOA Record — Zone Authority Information

The SOA record (Start of Authority) is a mandatory record that every DNS zone must have. It identifies the primary name server for the zone, the administrator's email address, the serial number used to synchronize zone transfers between servers, and timing parameters.

SOA Record Example

example.com.  86400  IN  SOA  ns1.example.com.  hostmaster.example.com. (
    2026110101  ; Serial (YYYYMMDDNN format)
    3600        ; Refresh interval
    900         ; Retry interval
    604800      ; Expire time
    300         ; Minimum TTL / negative caching TTL
)

SOA records are managed automatically by your DNS provider. You rarely need to edit them manually — the serial number increments automatically when you make zone changes.

PTR Record — Reverse DNS Lookup

A PTR record (Pointer) is the reverse of an A record: it maps an IP address back to a hostname. PTR records live in the special in-addr.arpa zone (for IPv4), which is controlled by the IP address owner — typically your ISP or hosting provider, not the domain holder.

Use Cases for PTR Records

• Mail servers: Receiving mail servers often perform reverse DNS lookups to verify that the sending IP resolves to a credible hostname, reducing spam scores
• Network diagnostics: Tools like traceroute and nslookup display PTR hostnames for each network hop
• Security logging: Log management systems resolve IPs to hostnames for readability

SRV Record — Service Location

An SRV record (Service) specifies the hostname and port of a particular service. The record name follows the format _service._protocol.domain. SRV records are commonly required by VoIP systems, Microsoft Teams, game servers, and XMPP messaging.

SRV Record Examples

; Microsoft Teams / Skype for Business
_sip._tls.example.com.  3600  IN  SRV  100 1 443 sipdir.online.lync.com.
_sipfederationtls._tcp.example.com.  3600  IN  SRV  100 1 5061 sipfed.online.lync.com.

; Minecraft game server
_minecraft._tcp.example.com.  3600  IN  SRV  0 5 25565 mc.example.com.

SRV Record Fields

• Priority: Lower value = higher preference
• Weight: Used for load balancing among equal-priority records
• Port: The TCP/UDP port number for the service
• Target: The hostname of the server providing the service

CAA Record — SSL Certificate Authority Control

A CAA record (Certification Authority Authorization) specifies which Certificate Authorities are permitted to issue SSL/TLS certificates for your domain. This prevents unauthorized certificate issuance — a critical security control.

CAA Record Examples

; Allow only Let's Encrypt and DigiCert
example.com.  3600  IN  CAA  0 issue "letsencrypt.org"
example.com.  3600  IN  CAA  0 issue "digicert.com"
; Allow wildcard certs from DigiCert only
example.com.  3600  IN  CAA  0 issuewild "digicert.com"
; Report unauthorized issuance attempts
example.com.  3600  IN  CAA  0 iodef "mailto:[email protected]"

DNS Record Type Comparison Table

Common DNS Configuration Mistakes

1. Placing CNAME at the Root Domain

RFC 1034 forbids CNAME records at the apex domain because they cannot coexist with mandatory NS and SOA records. Use an A record or employ CNAME Flattening via Cloudflare if you need to alias the root domain to a hostname.

2. Pointing MX to a CNAME

MX targets must always point to a hostname that has an A record — never to a CNAME. Mail servers strictly check this per RFC. Incorrect MX configuration causes email delivery failures.

3. High TTL Before a Planned Change

Lower your TTL to 300 seconds at least 24 hours before any planned DNS change. This ensures that cached records expire quickly once you make the switch, reducing propagation delay.

4. Multiple SPF Records

Having more than one SPF TXT record for a domain causes authentication failures. Merge all sending sources into a single SPF record using include: directives.

5. Missing Trailing Dot in Zone Files

In raw zone file format, fully qualified domain names require a trailing dot (e.g., mail.example.com.). Without it, the DNS server appends the zone name, creating an unintended hostname.