How to Read DNS Records (A, AAAA, MX, NS, TXT, and More)
DNSRECON.io keeps every record in monospace tables so you can audit them like log entries. This guide walks through each core record type, how to interpret the data inside the lookup UI, and how to gather the same information through the API for automation.
Updated: 07 December 2025
Estimated read: 10 minutes
1. Start with the Lookup Baseline
Begin on the Home lookup page and run the domain with all record types enabled. The stats row returns domain, record count, and query time—capture this as your baseline snapshot. It tells you whether the zone is healthy before you dive into individual record types.
Click the export buttons immediately after the first lookup. JSON captures all records, ASN enrichment, and metadata such as query time so you can compare later runs. CSV works when you need to share data with managers who live inside spreadsheets.
2. A & AAAA Records
A records map hostnames to IPv4 addresses; AAAA records do the same for IPv6. DNSRECON.io renders them with neon green badges and shows TTLs, priority (when applicable), and attached services. Pay attention to:
- Multiplicity: Multiple A/AAAA answers usually mean load balancing. Check the topology view to confirm each IP belongs to the correct ASN.
- Geo spread: The geographic map surfaces whether addresses reside in the intended regions. Unexpected countries might indicate misconfigured CDN edges.
- Reverse lookup: The enrichment table includes reverse DNS, useful for spotting ISP-provided PTRs that might hurt trust.
Automation tip: /api/lookup?domain=example.com&hide_ipv6=true strips AAAA responses for scripts that only understand IPv4, while keeping enrichment data intact.
3. MX Records
MX entries show where inbound email lands. Each line displays priority and target host. Ensure that:
- Priorities are sequential (10, 20, 30). Non-standard jumps often mean stale entries.
- The target hosts themselves resolve correctly. Right-click an MX host, open a new lookup, and confirm it delivers A/AAAA answers in the correct networks.
- The Mail Auth page agrees. SPF should include the MX hosts, DKIM selectors should exist, and DMARC should line up with the MX strategy.
During migrations, pin an expected MX host in the Propagation Checker to ensure resolvers have flushed the previous provider.
4. NS Records
Nameservers define who controls the zone. DNSRECON.io lists NS hostnames plus enrichment so you can verify the vendor (Route53, Cloudflare, on-prem). After changing NS at the registrar, run the Propagation Checker against the root domain and watch the NS column flip from old to new values. Keep running it until 100% of resolvers match.
If propagation drags, confirm the SOA serial (covered below) increments. Without a serial bump, secondary servers might not reload the zone even though the registrar change succeeded.
5. TXT Records (SPF, DKIM, DMARC, vendor tokens)
TXT is the Swiss Army knife of DNS. In DNSRECON.io, each TXT entry is expandable so long strings remain legible. Interpretations:
- SPF: Ensure the string begins with =spf1 and ends with -all or ~all. Count each include: and /mx mechanism—ten lookups is the RFC limit.
- DKIM: Selector records live at selector._domainkey.domain. The Mail Auth tool auto-tries common selectors (default, google, mail, selector1/2, smtp, k1). Confirm the p= value exists.
- DMARC: Lives at _dmarc.domain. Look for p=, optional sp= for subdomains, and
ua/
uf mailboxes. Use percentages (pct=) when rolling out enforcement.
- Vendor tokens: Many SaaS providers require TXT ownership proofs. Document when they can be safely removed.
6. CNAME Records
CNAMEs alias one hostname to another. Ensure the alias points to a hostname, never directly to an IP. If you see a chain of CNAMEs (common with CDNs), follow it until you hit an A/AAAA record. DNSRECON.io keeps CNAME badges pink so you can distinguish them from true address records at a glance.
Remember: a hostname with a CNAME cannot contain any other record types. If you spot a CNAME with additional TXT or MX records, fix the zone; many resolvers will ignore the conflicting data.
7. SOA & Serial Tracking
The SOA line contains the primary nameserver, responsible person email, serial, refresh, retry, expire, and minimum TTL. Serial numbers should increment with each change. DNSRECON.io highlights the serial so teams can quote it when coordinating with registrars or DNS vendors.
If secondaries lag behind, compare their SOA serial (by querying them directly) to the primary. Mismatches indicate transfer failures, which you can solve by nudging the provider or forcing a reload.
8. CAA Records
CAA entries restrict which certificate authorities may issue TLS certificates for your domain. Each entry includes a flag (0 or 128), tag (issue, issuewild, iodef), and value (usually a CA domain or report URL). Maintain CAA whenever adopting new certificate automation platforms like Let's Encrypt or Sectigo.
9. Use Topology & Charts for Context
The Sigma-based topology graph organizes nodes as Domain → Record Type → Hostname → IP → ASN. Use it to prove relationships visually—especially handy when briefing stakeholders. The map surfaces which countries currently answer, while the ASN chart reports the mix of providers. If you expect all records to live inside one ASN and see more, investigate.
10. Monitor via API
Everything described above is available via /api/lookup. Sample workflow:
curl "https://dnsrecon.io/api/lookup?domain=example.com" \
-H "X-API-Key: YOUR_KEY" \
| jq '.data.records.A'
Schedule this in cron, stash outputs in Git, and diff between runs to catch unauthorized DNS edits. Pair with /api/propagation during cutovers so you can alert teams as soon as resolvers flip.
11. Next Steps
Now that you can read every record, practice by running lookups on staging and production zones. Compare differences, document TTL strategies, and keep exports attached to change tickets. If you need to go deeper into propagation behavior, read the companion guide on troubleshooting DNS propagation.