Last year, a teammate pushed a DNS change on Friday afternoon — moved the production CNAME to a new load balancer. Except they created a CNAME on the apex domain, which conflicted with the existing MX records. Email stopped working for the entire company over the weekend. Nobody noticed until Monday morning when the CEO couldn’t receive board meeting invitations.
DNS seems simple until it breaks. And when it breaks, the symptoms are bizarre: websites work for some people but not others, emails vanish silently, or SSL certificates suddenly fail validation. Understanding how DNS records work prevents these disasters and makes troubleshooting faster when they do happen.
How DNS Resolution Actually Works
When you type example.com in your browser, here’s what happens in about 50 milliseconds:
1. Browser checks its cache → miss
2. OS checks its cache → miss
3. Query goes to your configured resolver (ISP or 8.8.8.8)
4. Resolver asks root nameserver: "Who handles .com?"
5. Root says: "Ask the .com TLD nameserver"
6. .com TLD nameserver says: "example.com uses ns1.hosting.com"
7. Resolver asks ns1.hosting.com: "What's the A record for example.com?"
8. ns1.hosting.com responds: "93.184.216.34, TTL 3600"
9. Resolver caches the result and returns it to your browserEach of these responses includes a TTL (Time To Live) — the number of seconds the result can be cached. This is why DNS changes don’t take effect instantly. Old records remain in caches worldwide until their TTL expires.
Quick DNS checks: Our DNS Lookup tool queries A, AAAA, MX, CNAME, TXT, and NS records using DNS over HTTPS — private and instant, no terminal required.
The DNS Record Types That Matter
A Record (Address)
Maps a domain name to an IPv4 address. This is the most fundamental record type.
example.com. A 93.184.216.34
www.example.com. A 93.184.216.34You can have multiple A records for the same domain (round-robin DNS). The resolver returns all of them, and the client picks one — a basic form of load balancing.
api.example.com. A 10.0.1.1
api.example.com. A 10.0.1.2
api.example.com. A 10.0.1.3AAAA Record (IPv6 Address)
Same as an A record, but for IPv6 addresses. The name “quad-A” comes from the fact that IPv6 addresses are four times longer than IPv4.
example.com. AAAA 2606:2800:220:1:248:1893:25c8:1946If you’re deploying a new service, set up both A and AAAA records. IPv6 adoption is above 40% globally, and some mobile networks are IPv6-only.
CNAME Record (Canonical Name)
Creates an alias that points to another domain name. When the resolver encounters a CNAME, it follows the chain to find the actual IP address.
www.example.com. CNAME example.com.
blog.example.com. CNAME mysite.netlify.app.The golden rule of CNAMEs: never put a CNAME on the apex domain (also called “zone apex” or “naked domain”). The DNS specification says a CNAME cannot coexist with other records at the same name, and the apex domain always has at least an SOA and NS record.
# WRONG — breaks MX records and NS records
example.com. CNAME something.cdn.com.
# CORRECT — use A record on apex, CNAME on subdomains
example.com. A 93.184.216.34
www.example.com. CNAME example.com.Some DNS providers (Cloudflare, AWS Route 53) offer “ALIAS” or “ANAME” records that act like CNAMEs at the apex by resolving the target at query time. These are non-standard but widely supported.
MX Record (Mail Exchange)
Specifies which mail servers handle email for the domain. Each MX record has a priority value — lower numbers mean higher priority.
example.com. MX 10 mail1.example.com.
example.com. MX 20 mail2.example.com.
example.com. MX 30 mail3.example.com.Mail is delivered to the lowest-priority server first. If it’s unavailable, the sender tries the next priority. This is how email achieves built-in redundancy.
Common MX setups:
# Google Workspace
example.com. MX 1 aspmx.l.google.com.
example.com. MX 5 alt1.aspmx.l.google.com.
example.com. MX 5 alt2.aspmx.l.google.com.
# Microsoft 365
example.com. MX 0 example-com.mail.protection.outlook.com.TXT Record (Text)
Holds arbitrary text data. Originally designed for human-readable notes, TXT records have become the Swiss Army knife of DNS — used for email authentication, domain verification, and security policies.
SPF (Sender Policy Framework):
example.com. TXT "v=spf1 include:_spf.google.com ~all"Tells email servers which IP addresses are authorized to send email on behalf of your domain. Without SPF, anyone can forge emails that appear to come from your domain.
DKIM (DomainKeys Identified Mail):
google._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS..."Provides a public key that receiving servers use to verify email signatures. DKIM proves the email wasn’t tampered with in transit.
DMARC (Domain-based Message Authentication):
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"Tells receiving servers what to do when SPF or DKIM checks fail — none (monitor), quarantine (spam folder), or reject (bounce).
Domain verification:
example.com. TXT "google-site-verification=abc123..."
example.com. TXT "v=spf1 include:_spf.google.com ~all"Services like Google Search Console, Let’s Encrypt, and Stripe use TXT records to verify domain ownership.
NS Record (Nameserver)
Identifies the authoritative nameservers for a domain. These records are set at your domain registrar and delegate control to your DNS provider.
example.com. NS ns1.cloudflare.com.
example.com. NS ns2.cloudflare.com.Changing NS records is one of the most impactful DNS changes you can make — you’re literally moving the source of truth for all your domain’s records to a different provider.
TTL: The Cache Timer
Every DNS record has a TTL (Time To Live) in seconds. When a resolver caches a record, it won’t query the authoritative server again until the TTL expires.
| TTL | Duration | Use Case |
|---|---|---|
| 60 | 1 minute | During migrations or failover |
| 300 | 5 minutes | Dynamic or frequently changing records |
| 3600 | 1 hour | Standard for most records |
| 86400 | 24 hours | Stable records (NS, MX) |
Pro tip for migrations: Lower the TTL to 60 seconds at least 24–48 hours before making the actual change. This ensures all caches have the short TTL, so when you update the record, propagation happens in minutes, not hours.
# 48 hours before migration
example.com. A 93.184.216.34 TTL 60
# During migration — change takes effect quickly
example.com. A 104.21.89.100 TTL 60
# After migration is stable — raise TTL back
example.com. A 104.21.89.100 TTL 3600I’ve seen teams forget this step and then wonder why “DNS propagation” takes 24 hours. It’s not propagation that’s slow — it’s the old TTL still being honored by caches.
Troubleshooting DNS Issues
”My Site Isn’t Resolving”
# Check what your machine resolves
dig example.com A +short
# Query a specific resolver (bypasses local cache)
dig @8.8.8.8 example.com A +short
# Check all record types
dig example.com ANYIf dig @8.8.8.8 returns the right answer but your local query doesn’t, it’s a caching issue. Wait for the TTL to expire, or flush your local DNS cache:
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Windows
ipconfig /flushdns
# Linux (systemd)
sudo systemd-resolve --flush-caches“Emails Aren’t Being Delivered”
Email delivery problems are almost always DNS-related. Check these in order:
- MX records exist —
dig example.com MX - SPF record is valid —
dig example.com TXT | grep spf - No CNAME on apex — a CNAME on the apex domain breaks MX resolution
- DMARC policy isn’t too strict for a new domain — start with
p=noneand monitor
”DNS Propagation Is Taking Forever”
It’s rarely actually slow. What’s usually happening:
- Old TTL was 24 hours — caches won’t refresh until the old TTL expires
- You’re checking from the same machine — your OS and browser have their own caches
- The change was made to the wrong zone — double-check you’re editing the right DNS provider
- NS records haven’t updated — if you’re moving DNS providers, the registrar’s NS records must be updated first
”SSL Certificate Validation Fails After DNS Change”
Let’s Encrypt and other CAs validate domain ownership through DNS or HTTP challenges. If you change DNS providers without recreating the validation records, certificate renewal will fail silently until the cert expires.
DNS Security: DNSSEC in 60 Seconds
DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records, preventing man-in-the-middle attacks where a malicious actor returns fake DNS responses.
Without DNSSEC:
You → "Where is bank.com?" → Resolver → Authoritative server
← "It's at 93.184.216.34" ← (could be intercepted and altered)With DNSSEC:
You → "Where is bank.com?" → Resolver → Authoritative server
← "It's at 93.184.216.34, signed with key XYZ" ← (tamper-evident)DNSSEC isn’t universally deployed yet, but if your registrar supports it, enabling it adds an important layer of trust.
Quick DNS Checklist for New Domains
When setting up a new domain, make sure you have:
- A/AAAA records pointing to your server or load balancer
- CNAME for www — either redirect www to apex or vice versa
- MX records — if you’re using email
- SPF record — to prevent email spoofing
- DKIM record — your email provider will give you this
- DMARC record — start with
p=none; rua=mailto:you@example.comto monitor - CAA record — specifies which CAs can issue certificates for your domain
- Reasonable TTLs — 3600 for stable records, 300 for records that change often
Further Reading
Need to check DNS records for a domain? Our DNS Lookup tool queries all record types using DNS over HTTPS — completely private and works right in your browser. If you’re also verifying SSL configuration, the SSL Certificate Checker helps you understand certificate fields and catch common misconfigurations.