When a domain points to the wrong server or email will not arrive, the dig command shows exactly what DNS returns and which server said it. It is more precise than nslookup or online checkers, and these dig examples cover nearly every DNS problem you will meet in hosting.
Before you start
- Linux/macOS have dig (install
dnsutilsorbind-utilsif missing). On Windows, use WSL or install BIND tools;Resolve-DnsNamein PowerShell is a close alternative. - The domain you want to test.
Basic lookup
dig example.comThe important part is the ANSWER SECTION:
;; ANSWER SECTION:
example.com. 3600 IN A 203.0.113.10That is name, TTL in seconds (how long resolvers may cache it), class, record type and value. The footer shows which resolver answered (SERVER:) and the query time.
For just the value, add +short:
dig +short example.comQuery specific record types
| Command | Shows |
|---|---|
dig example.com A | IPv4 address |
dig example.com AAAA | IPv6 address |
dig example.com MX +short | Mail servers and priority |
dig example.com TXT +short | SPF, verification and other text records |
dig example.com NS +short | Nameservers |
dig www.example.com CNAME +short | Alias target |
dig example.com CAA +short | Which CAs may issue SSL certificates |
dig -x 203.0.113.10 +short | Reverse DNS (PTR) for an IP |
Ask a specific DNS server
Your local resolver may have an old answer cached. Ask a public resolver or, better, the domain's authoritative nameserver directly:
dig @1.1.1.1 example.com +shortdig @ns1.example-dns.com example.com +shortIf the authoritative server shows the new IP but public resolvers show the old one, the change is correct and you are waiting for caches to expire (the old TTL).
Trace delegation from the root
dig +trace example.comdig walks from the root servers to the TLD servers to your nameservers, ignoring caches. Use it when you changed nameservers at the registrar: the TLD step shows which nameservers the registry actually has.
Check email DNS records
- SPF:
dig example.com TXT +short | grep spf(there must be only one SPF record). - DKIM:
dig default._domainkey.example.com TXT +short(replacedefaultwith your selector). - DMARC:
dig _dmarc.example.com TXT +short
Check DNSSEC
dig example.com +dnssecThe ad flag in the header (when using a validating resolver like 1.1.1.1) means the answer was DNSSEC-validated. A SERVFAIL from validating resolvers but a normal answer with +cd (checking disabled) points to broken DNSSEC, often a stale DS record after changing DNS providers.
Read status codes
- NOERROR with answers: record exists.
- NOERROR without answers: the name exists but has no record of that type.
- NXDOMAIN: the name does not exist.
- SERVFAIL: the resolver could not get a valid answer (nameserver down, DNSSEC failure, lame delegation).
- REFUSED: the server will not answer for that zone; often a nameserver that does not host the domain.
Troubleshooting with dig
- Site shows the old server: compare
dig @authoritativewithdig @8.8.8.8; wait out the TTL or flush local DNS. - Nameserver change not working:
dig +traceshows whether the registry has the new nameservers. - Email bouncing: verify MX targets resolve to A records (MX must not point to a CNAME or IP).
dig FAQ
dig vs nslookup?
Both query DNS. dig gives fuller, script-friendly output and is the standard for troubleshooting; nslookup is available by default on Windows.
How do I check DNS propagation?
Query several public resolvers (1.1.1.1, 8.8.8.8, 9.9.9.9) with +short and compare them to the authoritative answer.
Why does dig show a different IP than my browser?
Your browser or OS may cache DNS, or use DNS-over-HTTPS with a different resolver.