How to Look Up DNS Records

DNS records control where traffic goes for a domain: which server handles email, where the website lives, how subdomains resolve. Looking up records takes seconds once you know which tool to use.

Record types and what they do

dig (Linux/macOS)

dig is the standard DNS query tool.

# A record (default query type)
dig example.com

# Specific record types
dig example.com MX
dig example.com TXT
dig example.com NS
dig example.com AAAA

# Short output — just the answer section
dig example.com +short

# All record types
dig example.com ANY

Query against a specific nameserver — useful before DNS changes propagate:

# Google's public DNS
dig @8.8.8.8 example.com A

# Cloudflare's public DNS
dig @1.1.1.1 example.com A

# The domain's own authoritative nameserver
dig example.com NS +short       # get NS records first
dig @ns1.example.com example.com A

Trace the full resolution path from root servers down:

dig example.com +trace

This shows every step in the resolution chain — useful for diagnosing propagation issues.

nslookup (Windows/cross-platform)

nslookup ships with Windows, macOS, and Linux.

# Basic lookup
nslookup example.com

# Specific record type
nslookup -type=MX example.com
nslookup -type=TXT example.com
nslookup -type=NS example.com

# Query a specific DNS server
nslookup example.com 8.8.8.8

host (Linux/macOS)

host example.com               # A and MX records
host -t MX example.com         # MX only
host -t TXT example.com        # TXT (SPF, DKIM, verification)
host -a example.com            # all records

Online tool

Paste a domain into the DNS lookup tool to get all record types at once, with TTL values and the responding nameserver — no terminal required.

Check DNS propagation after a change

After updating DNS records, changes spread gradually as resolvers around the world flush their caches. TTL (Time to Live) controls how long resolvers cache each record. A 3600-second TTL means changes take up to one hour to appear everywhere.

Check what different resolvers currently see:

for server in 8.8.8.8 1.1.1.1 208.67.222.222; do
    echo "=== $server ==="
    dig @$server example.com A +short
done

Lower your TTL to 300 seconds (5 minutes) before a planned DNS change, then restore it after propagation completes.

Read SPF and DKIM records

SPF lives in a TXT record and specifies which servers can send email for your domain:

dig example.com TXT +short | grep spf

Output: v=spf1 include:_spf.google.com ~all

The trailing directive controls how receiving servers handle unauthorized senders:

• ~all — soft fail (mark but don't block)
• -all — hard fail (reject)
• +all — allow anyone (never use this)

DKIM lives in a TXT record at a selector subdomain:

dig google._domainkey.example.com TXT +short

The selector (google here) comes from the s= tag in email headers. A missing DKIM record causes emails to fail DKIM validation at the receiving server.

Check reverse DNS (PTR records)

PTR records map an IP address back to a hostname. Mail servers check these for spam filtering.

# Reverse lookup for an IP
dig -x 93.184.216.34 +short

# With nslookup
nslookup 93.184.216.34

If a mail server's IP has no PTR record, or if the PTR doesn't match the A record, some receiving servers will reject or mark mail as spam.