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:
asks for
example.com
Resolver
(ISP/1.1.1.1)
Nameserver
(.)
Nameserver
(.com)
Nameserver
(ns1.example.com)
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.
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.
2001:db8::1
$ dig google.com AAAA +short
2a00:1450:4009:81f::200e
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.
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:
| CNAME | Points To | Use Case |
|---|---|---|
www.example.com | example.com | www to root redirect |
blog.example.com | mysite.wordpress.com | Hosted blog platform |
shop.example.com | shops.myshopify.com | E-commerce platform |
mail.example.com | ghs.google.com | Google Workspace |
cdn.example.com | d1234.cloudfront.net | CDN distribution |
- 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.
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 Provider | MX Records to Add | Priority |
|---|---|---|
| Google Workspace | aspmx.l.google.com | 1 |
| Microsoft 365 | *.mail.protection.outlook.com | 0 |
| Self-hosted (Postfix) | mail.yourdomain.com | 10 |
| Zoho Mail | mx.zoho.com | 10 |
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:
"v=spf1 ip4:203.0.113.50 include:_spf.google.com -all"
| SPF Mechanism | Meaning | Example |
|---|---|---|
ip4: | Allow this IPv4 address | ip4:203.0.113.50 |
ip6: | Allow this IPv6 address | ip6:2001:db8::1 |
include: | Include another domain's SPF | include:_spf.google.com |
a | Allow the domain's A record IP | a |
mx | Allow the domain's MX server IPs | mx |
-all | Reject all others (hard fail) | Recommended |
~all | Soft fail all others | Less 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:
"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:
| DMARC Policy | Action | Recommendation |
|---|---|---|
p=none | Monitor only, no action | Start here |
p=quarantine | Send failing emails to spam | Recommended |
p=reject | Block failing emails entirely | Strictest |
Domain Verification TXT Records
Many services use TXT records to verify domain ownership:
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:
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:
$ 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:
0 issue "letsencrypt.org"
0 issuewild "letsencrypt.org"
0 iodef "mailto:[email protected]"
| CAA Tag | Purpose | Example |
|---|---|---|
issue | Authorize CA for regular certs | 0 issue "letsencrypt.org" |
issuewild | Authorize CA for wildcard certs | 0 issuewild "letsencrypt.org" |
iodef | Report unauthorized attempts | 0 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:
mail.example.com.
# The -x flag tells dig to do a reverse lookup
# Internally, this queries: 50.113.0.203.in-addr.arpa PTR
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 Value | Duration | Use Case | Trade-off |
|---|---|---|---|
| 300 | 5 minutes | Frequently changing records, failover | More DNS queries, faster propagation |
| 3600 | 1 hour | Standard websites | Good balance |
| 86400 | 24 hours | Stable records (MX, NS) | Fewer queries, slow changes |
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
| Record | Purpose | Example Value | Common Use |
|---|---|---|---|
| A | Domain to IPv4 | 203.0.113.50 | Website hosting |
| AAAA | Domain to IPv6 | 2001:db8::1 | IPv6 connectivity |
| CNAME | Alias to another domain | example.com | www redirect, SaaS |
| MX | Email server | 10 mail.example.com | Email delivery |
| TXT | Text data | v=spf1 ... -all | SPF, DKIM, verification |
| NS | Nameserver delegation | ns1.example.com | DNS authority |
| SRV | Service location | 10 60 5060 sip.example.com | VoIP, XMPP, LDAP |
| CAA | CA authorization | 0 issue "letsencrypt.org" | SSL security |
| PTR | IP to domain (reverse) | mail.example.com | Email, security |
| SOA | Zone authority info | Serial, refresh, retry, expire | Zone 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:
$ 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
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.