How to Check DNS Records — What Each Type Does and What to Look For

The DNS system translates human-readable domain names into machine-readable addresses. Every interaction with your site — a browser loading a page, a mail server accepting email, a third party verifying domain ownership — goes through DNS. When DNS is misconfigured, things stop working in ways that are often invisible to the user but devastating to operations. A missing MX record means email silently disappears. A stale A record means users hit a decommissioned server. A duplicate SPF record means deliverability collapses.

This guide explains what each DNS record type does, how to read the raw output, and how to spot the configurations that cause real damage.

The DNS Record Types You'll Actually Encounter

Each record type serves a specific purpose. Here's what each one does, with a concrete example of what it looks like in the wild.

A Record

Maps a hostname to an IPv4 address. The most fundamental DNS record — without it, your domain can't be reached in a browser. Example:

example.com.    3600    IN    A    93.184.216.34

One domain can have multiple A records for round-robin load balancing. If your site is unreachable, start here. The format is [name] [TTL] [class] [type] [value] — the TTL column tells you how long this record is cached by resolvers.

AAAA Record

Same as A but for IPv6 addresses. Increasingly important as IPv4 address space exhausts, and required for sites that want to be fully reachable on IPv6-only networks.

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

CNAME Record

Canonical Name — an alias pointing one hostname to another. www.example.com often CNAMEs to example.com. One key constraint: you cannot have a CNAME at your root domain (the "apex"). This is the CNAME-flattening problem — Cloudflare and Route 53 solve it with proprietary ALIAS/ANAME records that behave like CNAMEs at the apex.

MX Record

Mail Exchange — tells the world which servers receive email for your domain. Has a priority number; lower value = higher priority. Example:

example.com.    3600    IN    MX    10    mail.example.com.

If email is disappearing, check MX records first. A missing MX means email bounces. A wrong MX means email is delivered to someone else's server — or nowhere at all.

TXT Record

Free-form text. The Swiss Army knife of DNS. Used for:

• SPF (v=spf1 include:_spf.google.com ~all) — tells receiving servers which IP addresses are authorised to send email from your domain
• DKIM (v=DKIM1; k=rsa; p=...) — cryptographic public key used to verify email signatures
• DMARC (v=DMARC1; p=quarantine) — policy for what to do with emails that fail SPF/DKIM checks
• Domain verification — Google Search Console, Facebook, Apple, and many other services ask you to add a TXT record to prove domain ownership

NS Record

Name Server — which DNS servers are authoritative for your domain. If these are misconfigured, all other records become unreachable. NS records are typically set at your domain registrar, not inside the zone itself.

SOA Record

Start of Authority — administrative metadata about the DNS zone: primary nameserver, admin email address (encoded), zone serial number, and refresh/retry intervals. It's fetched automatically and rarely needs manual editing.

Reading dig Output

The dig command is the most reliable way to query DNS records from the command line. Example output for dig example.com ANY:

;; ANSWER SECTION:
example.com.     3600    IN    A       93.184.216.34
example.com.     3600    IN    NS      a.iana-servers.net.
example.com.     3600    IN    NS      b.iana-servers.net.
example.com.     3600    IN    MX      0 .
example.com.     3600    IN    TXT     "v=spf1 -all"
example.com.     3600    IN    AAAA    2606:2800:220:1:248:1893:25c8:1946

Each line follows the same format: [name] [TTL] [class] [type] [value]. The TTL (3600 = 1 hour) tells you how long resolvers are allowed to cache this answer before re-querying.

How to Run a DNS Lookup

Three approaches, depending on your environment:

1. Command line (dig): Available on macOS and Linux by default; install on Windows via BIND tools or WSL.

# A records
dig example.com A

# MX records
dig example.com MX

# All TXT records (SPF, DKIM, domain verification)
dig example.com TXT

# Concise output
dig example.com A +short

2. nslookup: Available on Windows, macOS, and Linux. Less detailed than dig but works everywhere.

nslookup -type=MX example.com

3. ByteWaveNetwork DNS Lookup tool: Enter any domain, select a record type (or ALL), and see results in a structured table with TTL, record type, and values. No command line access required — useful for checking DNS records on machines where dig isn't installed, or for sharing results with non-technical stakeholders.

What Bad DNS Records Look Like

DNS Propagation — Why Your Change Isn't Live Yet

After updating a DNS record, it doesn't instantly reflect everywhere. Resolvers around the world cache records until their TTL expires. A record with TTL 86400 (24 hours) can take a full day to propagate globally after you make a change.

Best practice before a DNS migration:

1. Lower TTL to 300 (5 minutes) at least 24 hours before the change — this gives all resolvers time to expire their cache of the old high-TTL value
2. Make the record change
3. Monitor propagation using the DNS Lookup tool (or dig @8.8.8.8, dig @1.1.1.1) to verify the new value is live on multiple public resolvers
4. After 48 hours, raise TTL back to 3600 or higher to reduce DNS query load

Checking Email Deliverability Records

SPF, DKIM, and DMARC are all stored as TXT records. If your outbound email is landing in spam or being rejected, these are the first three records to audit.

# SPF — check which IPs are authorised to send email for your domain
dig example.com TXT | grep "v=spf1"

# DMARC — check your policy for failed SPF/DKIM
dig _dmarc.example.com TXT

# DKIM — replace 'selector' with your actual DKIM selector (e.g. 'google', 'mail')
dig selector._domainkey.example.com TXT

The DNS Lookup tool surfaces all TXT records for a domain in one view. Look for v=spf1, v=DKIM1, and v=DMARC1 entries — and check that there's exactly one SPF record. Multiple SPF records cause immediate deliverability failures because the spec only allows one per domain.

If you're also checking your site's security posture, the HTTP Security Headers checker surfaces response headers (HSTS, CSP, X-Frame-Options) that complement DNS-level email security records.

Affiliate disclosure: Some links on this page may be affiliate links. We only mention tools we've personally used and have an honest opinion about. Affiliate revenue helps keep ByteWaveNetwork's tools free and maintained. We are not paid by any of the tools compared in this article for favorable coverage.