🔍 How to Read DNS Records Like a Pro (2026 Guide)
DNS records look cryptic. But once you know what to look for, they tell you everything about a domain — hosting, email, security, and infrastructure. This guide teaches you to read them in 5 minutes.
Try It Now: Embedded DNS Lookup
Opens in new tab with full results and domain health CTA.
The Anatomy of a DNS Lookup
When you type a domain into our DNS lookup tool, you get back a list of records. Each line looks like TYPE: VALUE. The type tells you what kind of record it is. The value is what it points to. Here's how to read each one.
🅰️ A Records — "Where does the website live?"
A records are the most fundamental: they map a domain to an IPv4 address.
A: 93.184.216.34→ example.com's web server lives at 93.184.216.34
How to read it: This is the IP address of the web server. If you see multiple A records, the domain uses round-robin DNS for load balancing. If the IP starts with 10., 172.16-31., or 192.168., it's a private/internal address — you won't reach it from the public internet.
📧 MX Records — "Who handles email?"
MX (Mail Exchange) records tell the world which servers receive email for the domain. Each has a priority number — lower = tried first.
MX: 1: aspmx.l.google.comMX: 5: alt1.aspmx.l.google.com→ Email goes first to aspmx.l.google.com (priority 1). If that fails, try alt1 (priority 5).
How to read it: The hostname after the priority tells you the email provider. google.com = Google Workspace, outlook.com = Microsoft 365, protonmail.ch = ProtonMail. No MX records? Email won't be delivered — period.
📝 TXT Records — "Policies, keys, and verification"
TXT records are freeform text. They store email security policies (SPF, DKIM, DMARC), domain verification tokens, and arbitrary data.
TXT: v=spf1 include:_spf.google.com ~allTXT: v=DMARC1; p=reject; rua=mailto:dmarc@example.com→ SPF allows Google's servers to send mail. DMARC says reject any mail that fails SPF/DKIM.
How to read it:
- SPF: Starts with
v=spf1. Lists allowed senders.~all= softfail (mark as spam),-all= hardfail (reject).?all= neutral (useless — anyone can send). - DKIM: Look for
k=rsa; p=...— the public key for verifying DKIM signatures. Usually stored under a selector likegoogle._domainkey. - DMARC: Starts with
v=DMARC1.p=none= monitor only,p=quarantine= send to spam,p=reject= block outright.pct=100means apply to 100% of mail. - Verification tokens: Random strings from Google Search Console, Microsoft 365, Stripe, etc. Confirm domain ownership.
🖧 NS Records — "Who controls the domain?"
NS records list the authoritative nameservers. These are the servers that hold the official DNS data.
NS: ns1.digitalocean.comNS: ns2.digitalocean.com→ DigitalOcean manages this domain's DNS.
How to read it: The nameserver hostname reveals your DNS provider — Cloudflare, AWS Route53, DigitalOcean, Namecheap, GoDaddy. If you're moving providers, check NS records to confirm the switch completed.
🔄 CNAME Records — "Aliases and redirects"
CNAME is an alias — it points one domain to another. Common for www → root domain.
CNAME: example.com→ www.example.com redirects to example.com
⚙️ SOA Records — "Zone configuration"
SOA (Start of Authority) stores zone metadata. You'll mainly care about the serial number.
SOA: ns1:admin:2026050101:7200:900:1209600:86400→ Primary NS, admin email, serial (2026050101), refresh/retry/expire/minimum TTL
How to read it: The serial number (2026050101) is usually a date stamp: 2026-05-01, revision 01. It increments with every zone change. If the serial hasn't changed after you updated records, your changes haven't been applied yet.
Real-World Example: Reading GitHub's DNS
Let's run a DNS lookup on github.com and decode what we see:
Analysis:
- A records point to Fastly IPs → GitHub uses Fastly CDN for their frontend
- MX records point to Google → GitHub uses Google Workspace for email
- TXT records include SPF (
include:_spf.google.com) and a long DMARC policy - NS records show multiple authoritative nameservers for redundancy
Pro-Level DNS Reading: What to Look For
| Signal | What It Means |
|---|---|
| Missing MX | Domain can't receive email |
| Missing SPF | Anyone can spoof emails from this domain |
| DMARC p=none | Monitoring only — spoofed emails still get delivered |
| DMARC p=reject | Domain is well-protected against spoofing |
| Wildcard CNAME | All subdomains redirect to root (e.g., *.example.com) |
| Short TTL on A | Domain expects frequent IP changes (CDN, load balancer) |
| Long TTL on MX | Email infrastructure is stable — rarely changes |
Common Mistakes When Reading DNS
- Confusing resolver cache with live data — Our DNS lookup tool queries live nameservers every time. Browser DNS caches (Chrome:
chrome://net-internals/#dns) may show stale data. - Forgetting about propagation — After changing records, different resolvers see different things for 1-48 hours. Check with the DNS Propagation Checker from 15 global locations.
- Looking at the wrong record type — Want mail config? That's MX+TXT. Want website location? That's A/AAAA. Want to know who manages DNS? That's NS.
- Ignoring TXT record length limits — SPF has a hard 10-lookup limit. Long TXT records may be split across multiple strings — our tool concatenates them correctly.
Quick Reference: Our DNS Tool Suite
A, MX, TXT, NS, CNAME, SOA 🌍 Propagation Checker
15 global resolvers 🌐🔍 DNS Monitor
Change detection + alerts ↩️ Reverse DNS
IP → hostname (PTR) 📬 Email Checker
Full audit + DNS checks 🧮 Subnet Calculator
CIDR, masks, IP ranges
🔍 Try Our DNS Lookup Now → 📖 Learn More
🔗 Related: Free DNS Lookup Tools: The Complete 2026 Guide · DNS Propagation: Why Your Changes Aren't Showing · SPF, DKIM & DMARC Setup Guide
📊 Professional Email Health Report
Liked this article? Put it into practice — get a personalized email deliverability audit for your domain.
Get Fix Report — €9 →