How to Read DNS Records Like a Pro: Every Type, Every Field, Every Trap

What Your DNS Records Reveal About You

Type any domain into a DNS lookup tool and you'll see something most people never look at: the entire infrastructure of an organization, exposed in plain text. Where their web servers live. Which email provider they use. What CDN fronts their traffic. Which SaaS tools they've authorized. Whether their email auth is solid or wide open. All of it, public, free for anyone to query.

DNS is the most exposed thing about your organization that you're probably not actively monitoring. Reading it well — knowing what each record type means, what fields hide important details, and what mistakes to spot — is one of those skills that makes the difference between someone who manages infrastructure and someone who actually understands it.

This guide walks through every DNS record type a working engineer needs to read fluently. Real examples, real fields, the traps that catch people. By the end you'll be able to look at any domain's DNS records and tell its story.

You can run lookups against any domain right now using our free DNS Lookup tool — it queries Cloudflare's 1.1.1.1 directly from your browser, no signup. Try it as you read.

The Anatomy of a DNS Record

Every DNS record, regardless of type, follows the same structure:

example.com.   3600   IN   A   93.184.216.34
   |             |     |   |          |
   name         TTL  class type      data

The name is the domain or subdomain the record applies to. The trailing dot makes it a fully qualified domain name (FQDN) — it's optional in most config files but important to understand. The TTL is how long, in seconds, resolvers should cache this record before re-querying. The class is almost always IN (internet); the other classes are historical curiosities. The type is what makes this record an A, AAAA, MX, or one of the dozens of other types. The data is the actual record value.

You'll see all five fields when you query DNS directly with dig or our DNS lookup tool. Most user-facing tools simplify the display, but the underlying structure is always this.

A Records: Where the Domain Actually Points

An A record maps a domain to an IPv4 address. It's the most fundamental record type — without it, browsers can't connect to your website over IPv4, which is still where the majority of internet traffic lives.

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

What to look for when reading A records:

Multiple A records at the same name means DNS round-robin load balancing. Resolvers get one of the addresses on each query, distributing traffic across servers. It's a poor man's load balancer — no health checks, no failover, but cheap and simple.

The IP belongs to a known provider. A quick reverse lookup or WHOIS on the IP usually tells you whether the site is on Cloudflare, AWS, Vercel, Netlify, or self-hosted. 104.16.0.0/12 is Cloudflare. 52.x, 54.x, and 3.x are usually AWS. 76.76.21.21 is Vercel.

The IP is suspicious or unexpected. If a production domain points to a residential ISP or a hosting provider you've never used, you have a problem — possibly a hijacked subdomain, possibly a forgotten test environment that's now public.

AAAA Records: Modern Networking

An AAAA record (pronounced "quad-A") does the same job as A but for IPv6 addresses. Same structure, same purpose, longer addresses.

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

If a domain has both A and AAAA records, modern clients prefer IPv6 and fall back to IPv4 if IPv6 fails (a behavior called Happy Eyeballs). If a domain only has A records, you're IPv4-only — which means you're missing the ~40% of internet users now reaching the web primarily over IPv6.

What to look for: missing AAAA records on consumer-facing sites are a slow loss — gradual SEO and performance degradation as IPv6 deployment grows. AAAA records pointing to private addresses (anything starting with fd or fe80) are misconfigurations that will fail for external clients. AAAA records that don't match the A record's hosting provider are usually a sign of an incomplete IPv6 rollout.

MX Records: The Email Delivery Decision

MX records list the mail servers responsible for receiving email for a domain, along with their priority. They're queried every time someone sends mail to your domain, by every sending mail server in the world.

example.com.   3600   IN   MX   1   aspmx.l.google.com.
example.com.   3600   IN   MX   5   alt1.aspmx.l.google.com.
example.com.   3600   IN   MX   10  alt2.aspmx.l.google.com.

The number after MX is the priority — lower numbers are tried first. If the priority-1 server is unreachable, sending servers fall back to priority 5, then 10, and so on. This is how mail providers build redundancy.

What MX records reveal about an organization:

What to look for: no MX records at all means the domain can't receive email — either intentional (a marketing domain that only sends from a different domain) or a real misconfiguration. MX records pointing at the domain's own A record means a self-hosted mail server, which is increasingly rare and worth investigating. A single low-priority MX with no fallbacks is a single point of failure for inbound mail.

NS Records: Who's Actually in Charge

NS records identify the authoritative nameservers for a domain. They're set at the registrar level and tell the rest of the world who to ask for DNS answers about your domain.

example.com.   86400   IN   NS   ns1.example-dns.com.
example.com.   86400   IN   NS   ns2.example-dns.com.

Reading NS records tells you which DNS provider an organization uses, which is often the most important piece of infrastructure intel about them:

What to look for: NS records that don't match the registrar means DNS is delegated elsewhere (extremely common — most companies host DNS at a specialized provider, not their registrar). Only one or two NS records means low redundancy; production domains should have at least three nameservers. NS records changing without warning is one of the strongest signals of a registrar account compromise — attackers redirect DNS to nameservers they control, then can intercept email and serve malicious content.

TXT Records: The Junk Drawer of DNS

TXT records hold arbitrary text. Originally intended for human-readable comments, they've become the universal place to store machine-readable verification tokens, configuration, and policy data. A typical production domain has 5–15 TXT records — and the longer you've been operating, the more accumulated cruft you'll find.

example.com.   3600   IN   TXT   "v=spf1 include:_spf.google.com ~all"
example.com.   3600   IN   TXT   "google-site-verification=AbC123XyZ..."
example.com.   3600   IN   TXT   "MS=ms12345678"
example.com.   3600   IN   TXT   "atlassian-domain-verification=..."
example.com.   3600   IN   TXT   "stripe-verification=..."

The most important TXT records to recognize:

SPF record starts with v=spf1. There should be exactly one. Two SPF records on the same name causes the entire SPF check to fail (per RFC 7208).

DMARC record at _dmarc.domain.com starts with v=DMARC1. Same rule — exactly one.

DKIM keys live at SELECTOR._domainkey.domain.com and start with v=DKIM1. There can be multiple selectors, one per email provider.

Verification tokens from third-party services (Google, Microsoft, Atlassian, Stripe, GitHub, Slack, etc.) sit in the root TXT records or sometimes at _subdomain paths. Each one tells you a tool the organization has authorized at some point.

What to look for: verification tokens for services you no longer use are leftover access tokens — clean them up. Multiple SPF records break SPF entirely. Tokens with names like _acme-challenge are temporary records used for Let's Encrypt cert issuance; if they're permanent and not actively rotating, you might have an automated cert renewal that's stuck.

Use the DNS lookup tool to query TXT records on any domain — you'll learn more about a company's tech stack from their TXT records than from their job postings.

CNAME Records: Aliases and Their Hidden Risks

A CNAME record creates an alias from one domain to another. When a resolver queries the alias, it gets back the canonical name, then queries that to get the actual IP.

www.example.com.   300   IN   CNAME   example.com.
shop.example.com.  300   IN   CNAME   stores.shopify.com.
docs.example.com.  300   IN   CNAME   readthedocs.io.

CNAMEs are how third-party services usually integrate with your domain — Shopify, Webflow, Mailchimp, Stripe, Vercel, Heroku, Salesforce all rely on CNAMEs pointing at their hostnames. The pattern is "we'll host the actual server, you point your subdomain at us."

The hidden risk in CNAMEs: subdomain takeover. When you stop using a service but forget to remove the CNAME pointing at it, an attacker can claim the now-unused hostname on the third-party platform and serve content under your subdomain. A live CNAME pointing to your-shop.shopify.com when you've cancelled your Shopify account means anyone can re-register that store name and now control shop.yourdomain.com.

What to look for: CNAME pointing to a domain that doesn't resolve is the signature of a subdomain takeover risk. CNAME pointing to a service you no longer use is the same risk but worse, because you forgot it exists. CNAME on the root domain (example.com. CNAME elsewhere.com.) is technically forbidden by the DNS spec — you should use ALIAS or ANAME records depending on your DNS provider.

SOA Records: The Quiet Backbone

The SOA (Start of Authority) record is one per zone and contains administrative information about the zone itself. You don't usually see it in casual DNS lookups, but it's there.

example.com.   86400   IN   SOA   ns1.example-dns.com. hostmaster.example.com. (
                                  2026050901  ; serial
                                  3600        ; refresh
                                  900         ; retry
                                  1209600     ; expire
                                  3600        ; minimum
                                  )

The serial number increments every time the zone is modified — it's how secondary nameservers know to fetch updates. The refresh interval tells secondaries how often to check for changes. The retry is the wait time after a failed refresh. The expire is how long secondaries serve stale data if they can't reach the primary. The minimum sets the default TTL for negative responses (NXDOMAIN caching).

Most engineers never touch SOA records — DNS providers handle them automatically. But if you're debugging a slow DNS propagation, the serial number is the first thing to check: it's how you confirm whether your update has been pushed to all nameservers.

TTL: The Hidden Lever

Every record has a TTL — Time To Live, in seconds. It controls how long resolvers (your ISP's DNS, Cloudflare 1.1.1.1, Google 8.8.8.8, etc.) cache the answer before re-querying.

Two TTL gotchas every operator hits at least once:

Forgetting to lower TTL before a migration. If your A record has TTL 86400 and you change it, expect the change to take up to a day to propagate fully. Lower the TTL to 300 a day before a migration so the change propagates in 5 minutes, then raise it back after.

Trusting the TTL absolutely. Some resolvers cache longer than the TTL says. Some users still hit ISPs that cache aggressively for hours. The TTL is a polite request, not a guarantee. If you need a record change to be visible to everyone within 5 minutes, the answer is "you can't, plan around that limitation."

How to Read DNS Records in Practice

Theory is useful. Reading actual records is what builds the skill. Pick three domains right now — your own, a competitor's, and a major company you're curious about — and run them through the DNS Lookup tool. Note what you see in each record type:

• A and AAAA records — what hosting provider are they on? Are they IPv6-ready?
• MX records — Google Workspace, Microsoft 365, or something else? How many servers in the failover chain?
• NS records — what DNS provider? How many nameservers?
• TXT records — read every one. Each verification token tells you a tool they use. The SPF and DMARC records tell you their email security maturity.
• CNAME records on subdomains — which services do they integrate with? Any pointing at platforms they might no longer use?

You'll learn more about an organization's infrastructure in 60 seconds of DNS reading than from an hour of marketing-page browsing.

Beyond One-Time Lookups: Continuous DNS Monitoring

A DNS lookup shows you what's there right now. It doesn't tell you what changed last week, who changed it, or whether the change was authorized. DNS records can be modified at the registrar by anyone with credentials, at any time, with no native alerting.

That's the gap between checking DNS once and actually knowing your DNS posture. The most common DNS-related security incidents — registrar account compromise, hijacked subdomains, silent MX swaps redirecting email to attackers — are all detectable as DNS changes, but only if you're watching for them continuously.

FortWatch monitors every DNS record on every domain you own, hourly, and alerts you the moment anything changes. Silent NS swap? You know within an hour. CNAME suddenly pointing at a deprovisioned service? Subdomain takeover risk flagged automatically. New TXT record you didn't add? Investigated and reported. Start free and add your first domain in two minutes.

For one-time checks, the free DNS Lookup tool queries Cloudflare 1.1.1.1 directly from your browser. No signup, no rate limits, no data sent to FortWatch — every lookup runs in your browser via DNS-over-HTTPS.

The Working Engineer's DNS Reading Checklist

Use this to read any domain's DNS records in under two minutes:

1. A / AAAA — Is the IP on a known provider? IPv6 ready? Multiple records (round-robin)?
2. MX — Email provider identified? Multiple servers in the failover chain?
3. NS — DNS provider identified? At least three nameservers?
4. TXT — SPF present and singular? DMARC at _dmarc? Verification tokens you recognize?
5. CNAME — Subdomain CNAMEs pointing at active services, not deprovisioned ones?
6. TTL — Reasonable for each record type (300–3600 for changing records, longer for stable ones)?

Run this checklist against your own domain right now using the free DNS Lookup tool. If anything looks off, you've found your weekend project.