How to Check Your DNS Records

You changed your DNS records. Maybe you pointed your domain to a new server, fixed your email configuration, or moved to a new hosting provider. Now comes the anxious part: did it work?

DNS doesn't update instantly. Your authoritative nameserver might show the correct records immediately, but the rest of the Internet is working from cached copies. Worse, your own computer caches DNS too—so you might see your changes while everyone else sees the old configuration.

The question isn't just "what's my DNS record?" It's "who do I trust to tell me?"

The Quick Answer: dig

The dig command is the fastest way to check DNS records on macOS or Linux:

dig example.com A +short

This returns the IP address your domain points to—nothing else. If you see the IP you expect, that resolver has your update.

But that query went to your system's default DNS resolver, which might have cached the old record. To see what a specific resolver knows, ask it directly:

dig @8.8.8.8 example.com A +short    # Google's DNS
dig @1.1.1.1 example.com A +short    # Cloudflare's DNS

Different answers from different resolvers means your change is still propagating.

The Trust Hierarchy

Every layer between you and the authoritative nameserver might be lying—not maliciously, just because it remembered something that's no longer true.

Your local cache → Your ISP's resolver → Public resolvers → Authoritative nameserver

To know the truth, go to the source. First, find which nameservers are authoritative for your domain:

dig example.com NS +short

Then query one directly:

dig @ns1.your-dns-provider.com example.com A +short

If the authoritative nameserver shows the wrong record, your DNS provider doesn't have your change. If it shows the right record but public resolvers don't, the change is propagating—you're waiting for caches to expire.

Checking Different Record Types

dig example.com A        # IPv4 address
dig example.com AAAA     # IPv6 address
dig example.com MX       # Mail servers
dig example.com TXT      # SPF, DKIM, domain verification
dig example.com CNAME    # Aliases
dig example.com NS       # Nameservers

Drop the +short flag when you want the full response, including the TTL (time to live)—the number of seconds resolvers will cache this record before asking again.

On Windows: nslookup

Windows doesn't include dig by default, but nslookup is built in:

nslookup example.com
nslookup -type=MX example.com
nslookup example.com 8.8.8.8    # Query a specific resolver

The output is less detailed than dig, but it answers the essential question: what does this resolver think my domain points to?

Watching Propagation Spread

Command-line tools check one resolver at a time. Online tools query dozens simultaneously:

• whatsmydns.net — Results on a world map. Green checkmarks appear across continents as your change propagates.
• dnschecker.org — Similar view, servers grouped by region.
• dns.google — Google's DNS with DNSSEC validation status.

Your Computer Lies to You

Your operating system caches DNS to avoid repeated lookups. This means you might see your new configuration while testing locally, even though public resolvers still serve the old records.

Flush your local cache:

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Windows
ipconfig /flushdns

# Linux (systemd)
sudo systemd-resolve --flush-caches

After flushing, your next DNS query fetches fresh data instead of serving cached results.

When Things Go Wrong

NXDOMAIN: The domain doesn't exist in DNS. Either it's not registered, the nameservers aren't configured, or you mistyped it.

SERVFAIL: The DNS server couldn't process your request. Often caused by DNSSEC misconfiguration or unreachable nameservers.

Different answers from different resolvers: Normal during propagation. Check the authoritative nameserver—if it's correct, wait for caches to expire.

Changes not appearing after hours: Check the TTL on the old record. If it was set to 86400 (24 hours), resolvers that cached it right before your change won't ask again for a full day. This is why experienced administrators lower TTLs before making changes.