DNS Record Types Explained

A Address Record

The A record is the most fundamental DNS record. It maps a domain name to an IPv4 address — the numeric address where your website or application actually lives. When someone types example.com into their browser, the A record tells the browser which server IP to connect to.

What it looks like:

example.com.    300    IN    A    93.184.216.34
www.example.com.  300   IN    A    93.184.216.34

• Name: the domain or subdomain (use @ for the root domain at most registrars)
• TTL: time-to-live in seconds — how long resolvers cache this record (300 = 5 minutes)
• Value: the IPv4 address

When you need it: Every domain that serves web traffic needs at least one A record. Most setups have an A record for the root domain (@) and a CNAME for www (or a second A record pointing to the same IP).

AAAA IPv6 Address Record

The AAAA record (pronounced "quad-A") is the IPv6 equivalent of the A record. It maps a domain to a 128-bit IPv6 address instead of the 32-bit IPv4 address. As the world gradually exhausts the IPv4 address space, AAAA records are becoming increasingly important.

What it looks like:

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

Key points:

• Modern browsers try IPv6 first, then fall back to IPv4 (Happy Eyeballs algorithm)
• If you only have an A record and no AAAA, IPv6-only clients need a transition mechanism (NAT64/DNS64)
• Most CDNs and cloud providers support both A and AAAA out of the box
• Adding an AAAA record alongside your A record is called dual-stack networking

CNAME Canonical Name Record

A CNAME record creates an alias — it points one domain name to another domain name. Instead of resolving to an IP address directly, the resolver looks up the target domain's A/AAAA records. CNAMEs are widely used for CDNs, hosted platforms, and simplifying DNS management.

What it looks like:

www.example.com.    300    IN    CNAME    example.com.
blog.example.com.   300    IN    CNAME    example.github.io.

• Name: the alias (subdomain you want to redirect)
• Value: the canonical (target) domain name — must end with a dot for absolute FQDN

Important rules:

• CNAMEs cannot coexist with other records at the same name — if www.example.com has a CNAME, it can't also have an A record or MX record
• The root domain (apex) cannot have a CNAME (violates RFC) — use an A record with a static IP or an ALIAS/ANAME record if your provider supports it
• CNAME chains (A → B → C) work but add resolution latency — keep chains short

MX Mail Exchanger Record

The MX record tells the world which servers handle incoming email for your domain. It includes a priority value — lower numbers are tried first. This is how services like Google Workspace, Microsoft 365, and ProtonMail receive mail on behalf of your domain.

What it looks like:

example.com.    300    IN    MX    10    mail.example.com.
example.com.    300    IN    MX    20    mail2.example.com.
; Google Workspace example:
example.com.    300    IN    MX    1     ASPMX.L.GOOGLE.COM.

• Priority: integer, lower = higher priority. Common values: 0 (primary only), 10/20 (primary + backup), 1/5/10 (Google Workspace default)
• Value: the hostname of the mail server — must resolve to an A/AAAA record (not a CNAME)

Common issues: Missing MX records mean no one can send you email. If MX points to a CNAME instead of an A record, some mail servers will reject delivery. Always verify with DNS Lookup after changing MX records.

TXT Text Record

TXT records store arbitrary text data associated with a domain. They're the Swiss Army knife of DNS — used for email authentication (SPF, DKIM, DMARC), domain ownership verification, and security policies.

What they look like:

; SPF — authorize mail servers
example.com.    300    IN    TXT    "v=spf1 include:_spf.google.com ~all"

; DKIM — email signing key
google._domainkey.example.com.  300  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0G..."

; DMARC — email authentication policy
_dmarc.example.com.  300  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

; Domain verification (Google, GitHub, Stripe, etc.)
example.com.    300    IN    TXT    "google-site-verification=abc123..."

Major use cases:

• SPF (Sender Policy Framework): lists servers authorized to send mail from your domain — critical for email deliverability
• DKIM (DomainKeys Identified Mail): cryptographic signature that proves email wasn't tampered with
• DMARC: tells receivers what to do with mail that fails SPF or DKIM checks
• Domain verification: prove ownership to Google Search Console, GitHub, Stripe, and other platforms
• BIMI: brand logo display in supported email clients

TXT records can be up to 255 characters per string, with multiple strings concatenated for longer values. Always test your SPF/DKIM/DMARC setup after making changes.

NS Nameserver Record

The NS record delegates authority for a domain (or subdomain) to a set of nameservers. These nameservers are the authoritative source for all other records in the zone. Every domain must have at least two NS records for redundancy.

What it looks like:

example.com.    86400    IN    NS    ns1.example.com.
example.com.    86400    IN    NS    ns2.example.com.
; Cloudflare:
example.com.    86400    IN    NS    alan.ns.cloudflare.com.
example.com.    86400    IN    NS    mary.ns.cloudflare.com.

How delegation works:

1. The parent zone (e.g., .com TLD) stores NS records pointing to your nameservers
2. Your nameservers hold the authoritative zone file with all A, MX, TXT, etc. records
3. If NS records at the parent and the zone itself don't match, you have a lame delegation

SOA Start of Authority Record

The SOA record is the administrative header of a DNS zone. It stores metadata about the zone itself — the primary nameserver, the admin's email, and timing values that control zone transfers and caching behavior.

What it looks like:

example.com.  3600  IN  SOA  ns1.example.com. admin.example.com. (
  2026061201  ; Serial (YYYYMMDDNN format)
  7200        ; Refresh (2 hours)
  3600        ; Retry (1 hour)
  1209600     ; Expire (14 days)
  86400       ; Minimum TTL (1 day)
)

• MNAME: primary master nameserver
• RNAME: admin email (the @ is replaced with a dot — admin.example.com means admin@example.com)
• Serial: version number — secondary nameservers check this to know when to pull updates
• Refresh: how often secondaries check for changes
• Retry: how long to wait after a failed refresh before retrying
• Expire: how long secondaries keep serving data if they can't reach the primary
• Minimum TTL: default TTL for negative caching (NXDOMAIN responses)

PTR Pointer Record

A PTR record does the opposite of an A record — it maps an IP address back to a domain name. This is called reverse DNS (rDNS). It lives in a special .arpa zone and is primarily used for email deliverability and server identification.

What it looks like (in the reverse zone):

34.216.184.93.in-addr.arpa.  300  IN  PTR  example.com.

• IPv4 PTRs live in in-addr.arpa (IP octets reversed)
• IPv6 PTRs live in ip6.arpa (each hex digit as a separate label, reversed)
• You typically can't set PTR records yourself — the owner of the IP block (your hosting provider or ISP) must configure them
• Many mail servers reject or flag email from IPs without valid PTR records

SRV Service Record

An SRV record specifies the hostname and port for specific services. Unlike MX records (which only handle mail), SRV is a generic mechanism for service discovery — used by VoIP, instant messaging, LDAP, and modern protocols.

What it looks like:

_sip._tcp.example.com.  300  IN  SRV  10 60 5060 sipserver.example.com.
_xmpp._tcp.example.com. 300  IN  SRV  5  0  5222 xmpp.example.com.
_ldap._tcp.example.com. 300  IN  SRV  0  0  389  ldap.example.com.

• Name format: _service._proto.domain (e.g., _sip._tcp, _xmpp._tcp)
• Priority: like MX, lower = preferred
• Weight: load-balancing among servers with the same priority
• Port: the TCP/UDP port number the service listens on
• Target: the hostname providing the service

CAA Certificate Authority Authorization

The CAA record specifies which Certificate Authorities (CAs) are allowed to issue SSL/TLS certificates for your domain. It's a DNS-level security control that prevents unauthorized certificate issuance — a defense against mis-issued certificates and MITM attacks.

What it looks like:

; Allow only Let's Encrypt
example.com.  300  IN  CAA  0 issue "letsencrypt.org"

; Allow only DigiCert
example.com.  300  IN  CAA  0 issue "digicert.com"

; Report policy violations
example.com.  300  IN  CAA  0 iodef "mailto:security@example.com"

• Flags: 0 (standard) or 1 (critical — CA must understand this tag)
• Tag: issue (authorize CA), issuewild (authorize wildcard certs), iodef (violation reporting URL/email)
• CAs must check CAA records before issuing certificates (mandated by CA/Browser Forum since 2017)
• An empty CAA record (issue ";") means no CA is allowed — useful for domains you never want to have HTTPS