Knowledge Base

Check DNS with dig and nslookup: Verify Domain Records Step by Step

In short: dig and nslookup are command-line DNS tools that show what A, MX, TXT or NS records your domain returns right now. After you change a record, use them (and if needed a public dig UI) to verify propagation and to separate email or site routing problems from application bugs.

You added a DNS record or changed nameservers; the browser still opens the old site or mail fails. The value in the panel and what the internet actually serves can differ. This guide assumes you know DNS record types and shows how to check with dig and nslookup step by step.

What are dig and nslookup?

dig (domain information groper) is a DNS query tool from the BIND suite. For daily checks, +short prints only the answer.

nslookup is an interactive or one-shot DNS query tool on Windows and many UNIX systems. Microsoft documents the Windows nslookup command; use -type= to pick the record type.

Which command checks what?

Examples use the reserved name example.com and the documentation address 198.51.100.20; substitute your domain. The DNS resolver on the machine that runs the command affects the answer — so one result does not mean "everywhere". See our DNS propagation guide.

Step-by-step DNS check

1. Note the panel value

Copy the exact A, MX or TXT row from your hosting or domain panel. You need a reference to compare.

2. Short dig query

On Linux or macOS: dig A yourdomain.com +short. An empty answer can mean the wrong type, a record that has not propagated yet or the wrong nameservers. For mail use dig MX yourdomain.com +short.

3. Check with nslookup on Windows

In Command Prompt: nslookup -type=MX yourdomain.com. Compare the mail exchanger lines with the panel.

4. Ask another resolver

If the local answer looks stale, query the same record with a public dig UI such as Google Admin Toolbox Dig. If local and public answers differ, you are looking at propagation or cache.

5. Confirm nameservers

If you wrote the record in the wrong DNS zone, dig will not match. Check the nameserver change first; the same dig step is used for Search Console domain TXT verification (TXT verification).

Common mistakes

• Only watching the browser: Browser cache can hide DNS truth; dig/nslookup is clearer.
• Wrong record type: An A query will not show an MX problem.
• Trusting one resolver: One network can be old while another is already new.
• Panicking before TTL: Not every location updates right after a change.

dig and nslookup quickly show the gap between the panel row and the published answer. If you are stuck, open a support ticket and paste the command plus its output.

Example scenarios

A record changed, browser still hits the old IP: Compare dig A yourdomain.com +short with the panel. If local is old and Google Toolbox is new, check your resolver cache. If both are old, the record may be in the wrong zone or nameservers are not updated yet.

MX looks right but mail still fails: MX only points at the mail host. SPF/DKIM TXT rows, blocklists and credentials are separate layers. Confirm dig MX first, then dig TXT for SPF.

Search Console cannot find the TXT: Use dig TXT to prove the record is published. Confirm the host is @ / blank and that you did not delete older verification rows by mistake.

Frequently Asked Questions