Tutorial

DNS Records Explained: A Complete Guide to A, AAAA, CNAME, MX, TXT, and More

March 23, 2026

Back to Blog

The Domain Name System (DNS) is the invisible backbone of the internet. Every time you type a URL into your browser, send an email, or connect to an API, DNS translates human-readable names into machine-readable IP addresses. Understanding DNS records is fundamental for anyone who manages websites, servers, or online services.

Think of DNS as the internet's phone book. When you call someone, you do not dial a random sequence of numbers — you look up their name and get the number. DNS does exactly this: you ask for example.com, and DNS returns 203.0.113.50.

This guide explains every common DNS record type with practical examples, real dig output, and guidance on when to use each one.

The DNS Resolution Process

Before diving into record types, let us understand how a DNS query travels from your browser to the answer:

Browser
asks for
example.com
Local DNS
Resolver
(ISP/1.1.1.1)
Root
Nameserver
(.)
TLD
Nameserver
(.com)
Authoritative
Nameserver
(ns1.example.com)
Answer
203.0.113.50

This entire process typically completes in under 50 milliseconds, and the result is cached at multiple levels to speed up subsequent queries.

A Record — The Foundation

The A record (Address record) is the most fundamental DNS record. It maps a domain name to an IPv4 address. When someone visits your website, the A record tells their browser which server to connect to.

$ dig example.com A +short
203.0.113.50

$ dig example.com A
;; ANSWER SECTION:
example.com. 300 IN A 203.0.113.50

;; Query time: 12 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)

Key facts about A records:

  • You can have multiple A records for the same domain (round-robin DNS)
  • The @ symbol represents the root domain (e.g., example.com)
  • Subdomains need their own A records (e.g., blog.example.com)
  • TTL (Time to Live) determines how long the record is cached

AAAA Record — IPv6 Address

The AAAA record (pronounced "quad-A") is the IPv6 equivalent of the A record. As IPv4 addresses become scarce, IPv6 adoption continues to grow — Google reports over 45% of traffic now uses IPv6.

$ dig example.com AAAA +short
2001:db8::1

$ dig google.com AAAA +short
2a00:1450:4009:81f::200e
Should You Add AAAA Records?
If your server has an IPv6 address (most modern VPS providers include one), add AAAA records. It improves connectivity for IPv6-only networks, mobile carriers, and future-proofs your setup. If your server only has IPv4, skip it — there is no benefit.

CNAME Record — The Alias

A CNAME record (Canonical Name) creates an alias from one domain name to another. Instead of pointing to an IP address, it points to another domain name. The DNS resolver follows the chain until it reaches an A record.

$ dig www.example.com CNAME +short
example.com.

# The resolver then looks up example.com's A record
$ dig www.example.com A +short
203.0.113.50

Common CNAME use cases:

CNAMEPoints ToUse Case
www.example.comexample.comwww to root redirect
blog.example.commysite.wordpress.comHosted blog platform
shop.example.comshops.myshopify.comE-commerce platform
mail.example.comghs.google.comGoogle Workspace
cdn.example.comd1234.cloudfront.netCDN distribution
CNAME Restrictions
  • A CNAME cannot coexist with other record types at the same name. You cannot have a CNAME and an MX record on example.com.
  • The root domain (example.com) should not use a CNAME — use an A record instead, or use your DNS provider's ALIAS/ANAME flattening feature.
  • CNAME adds an extra DNS lookup step, slightly increasing latency.

MX Record — Email Routing

The MX record (Mail Exchanger) tells the world which server handles email for your domain. When someone sends an email to [email protected], their mail server looks up the MX record for example.com to find where to deliver it.

$ dig example.com MX +short
10 mail.example.com.
20 mail2.example.com.

$ dig gmail.com MX +short
5 gmail-smtp-in.l.google.com.
10 alt1.gmail-smtp-in.l.google.com.
20 alt2.gmail-smtp-in.l.google.com.
30 alt3.gmail-smtp-in.l.google.com.
40 alt4.gmail-smtp-in.l.google.com.

The number before each server is the priority (lower = higher priority). In the example above, mail servers try mail.example.com first (priority 10). If it is unavailable, they fall back to mail2.example.com (priority 20).

Email ProviderMX Records to AddPriority
Google Workspaceaspmx.l.google.com1
Microsoft 365*.mail.protection.outlook.com0
Self-hosted (Postfix)mail.yourdomain.com10
Zoho Mailmx.zoho.com10

TXT Record — The Swiss Army Knife

The TXT record stores arbitrary text data associated with a domain. It has become the most versatile record type, used for email authentication, domain verification, and security policies.

SPF (Sender Policy Framework)

SPF tells receiving mail servers which IP addresses are authorized to send email on behalf of your domain. This prevents spammers from spoofing your domain:

$ dig example.com TXT +short | grep spf
"v=spf1 ip4:203.0.113.50 include:_spf.google.com -all"
SPF MechanismMeaningExample
ip4:Allow this IPv4 addressip4:203.0.113.50
ip6:Allow this IPv6 addressip6:2001:db8::1
include:Include another domain's SPFinclude:_spf.google.com
aAllow the domain's A record IPa
mxAllow the domain's MX server IPsmx
-allReject all others (hard fail)Recommended
~allSoft fail all othersLess strict

DKIM (DomainKeys Identified Mail)

DKIM adds a digital signature to outgoing emails, allowing receiving servers to verify the email was not tampered with in transit:

$ dig default._domainkey.example.com TXT +short
"v=DKIM1; h=sha256; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

DMARC (Domain-based Message Authentication)

DMARC builds on SPF and DKIM to tell receiving servers what to do when authentication fails:

$ dig _dmarc.example.com TXT +short
"v=DMARC1; p=quarantine; rua=mailto:[email protected]; fo=1"
DMARC PolicyActionRecommendation
p=noneMonitor only, no actionStart here
p=quarantineSend failing emails to spamRecommended
p=rejectBlock failing emails entirelyStrictest

Domain Verification TXT Records

Many services use TXT records to verify domain ownership:

# Google Search Console
google-site-verification=abc123def456...

# Facebook domain verification
facebook-domain-verification=xyz789...

# Microsoft 365
MS=ms12345678

NS Record — Nameserver Delegation

The NS record (Nameserver) specifies which DNS servers are authoritative for a domain. When you register a domain and set nameservers at your registrar, you are defining NS records:

$ dig example.com NS +short
ns1.example.com.
ns2.example.com.

$ dig cloudflare.com NS +short
ns3.cloudflare.com.
ns4.cloudflare.com.
ns5.cloudflare.com.
ns6.cloudflare.com.
ns7.cloudflare.com.

SRV Record — Service Discovery

The SRV record (Service) specifies the host and port for specific services. It is commonly used for VoIP, XMPP (chat), LDAP, and Microsoft Active Directory:

# Format: _service._protocol.name TTL IN SRV priority weight port target
$ dig _sip._tcp.example.com SRV +short
10 60 5060 sip.example.com.

# Microsoft Teams autodiscover
$ dig _sipfederationtls._tcp.example.com SRV +short
100 1 5061 sipfed.online.lync.com.

CAA Record — Certificate Authority Authorization

The CAA record specifies which Certificate Authorities (CAs) are allowed to issue SSL certificates for your domain. This prevents unauthorized CAs from issuing certificates, adding an extra layer of security:

$ dig example.com CAA +short
0 issue "letsencrypt.org"
0 issuewild "letsencrypt.org"
0 iodef "mailto:[email protected]"
CAA TagPurposeExample
issueAuthorize CA for regular certs0 issue "letsencrypt.org"
issuewildAuthorize CA for wildcard certs0 issuewild "letsencrypt.org"
iodefReport unauthorized attempts0 iodef "mailto:[email protected]"

PTR Record — Reverse DNS

The PTR record (Pointer) is the reverse of an A record — it maps an IP address back to a domain name. PTR records are primarily used for email deliverability and security verification:

$ dig -x 203.0.113.50 +short
mail.example.com.

# The -x flag tells dig to do a reverse lookup
# Internally, this queries: 50.113.0.203.in-addr.arpa PTR
PTR Records for Email
If you run your own mail server, a PTR record is essential. Gmail, Outlook, and other major providers will reject or spam your emails if the sending IP does not have a matching PTR record. PTR records are set by your hosting provider (the owner of the IP block), not in your domain's DNS zone.

TTL — Time to Live

Every DNS record has a TTL value measured in seconds. This tells DNS resolvers how long to cache the record before checking for updates:

TTL ValueDurationUse CaseTrade-off
3005 minutesFrequently changing records, failoverMore DNS queries, faster propagation
36001 hourStandard websitesGood balance
8640024 hoursStable records (MX, NS)Fewer queries, slow changes
Pro Tip: Pre-Migration TTL Reduction
Before migrating a website to a new server, lower the TTL to 300 seconds (5 minutes) 24-48 hours in advance. This ensures that when you change the A record to the new IP, the change propagates quickly. After migration is complete, raise the TTL back to 3600 or higher.

Complete DNS Record Reference

RecordPurposeExample ValueCommon Use
ADomain to IPv4203.0.113.50Website hosting
AAAADomain to IPv62001:db8::1IPv6 connectivity
CNAMEAlias to another domainexample.comwww redirect, SaaS
MXEmail server10 mail.example.comEmail delivery
TXTText datav=spf1 ... -allSPF, DKIM, verification
NSNameserver delegationns1.example.comDNS authority
SRVService location10 60 5060 sip.example.comVoIP, XMPP, LDAP
CAACA authorization0 issue "letsencrypt.org"SSL security
PTRIP to domain (reverse)mail.example.comEmail, security
SOAZone authority infoSerial, refresh, retry, expireZone management

Checking DNS Propagation

After changing DNS records, propagation can take anywhere from a few minutes to 48 hours depending on TTL values and resolver caching. Here is how to check propagation status:

# Query specific DNS servers to check propagation
$ dig @1.1.1.1 example.com A +short # Cloudflare DNS
203.0.113.50

$ dig @8.8.8.8 example.com A +short # Google DNS
203.0.113.50

$ dig @9.9.9.9 example.com A +short # Quad9 DNS
203.0.113.50

# Check from authoritative nameserver (always current)
$ dig @ns1.example.com example.com A +short
203.0.113.50

# Online tools: whatsmydns.net, dnschecker.org

DNS Management with Panelica

Panelica includes a built-in BIND DNS server that manages all record types directly from the web panel. Combined with Cloudflare integration, you get a comprehensive DNS management solution:

  • Full record management — Create, edit, and delete A, AAAA, CNAME, MX, TXT, SRV, CAA, NS, and PTR records
  • Automatic zone generation — When you add a domain, Panelica creates the DNS zone with sensible defaults
  • Cloudflare integration — Manage Cloudflare DNS from Panelica with drift detection (detects when records change outside the panel)
  • Email DNS automation — SPF, DKIM, and DMARC records are generated automatically when you enable email for a domain
  • Subdomain management — Create subdomains with their own DNS records and web server configurations
  • Zone import/export — Import existing BIND zone files or export for backup
DNS + Email + SSL in One Panel
Instead of managing DNS at your registrar, email records in your mail provider, and SSL at your server, Panelica centralizes everything. Add a domain, enable email, and all the required DNS records — A, MX, SPF, DKIM, DMARC, and SSL certificate — are created automatically.
Share: