What is the DNS lookup command in Windows?

The built-in DNS lookup command in Windows is nslookup. Open Command Prompt and type nslookup followed by the domain, for example nslookup example.com. It returns the IP address the domain resolves to. Add a record type with -type=mx or -type=txt to query other records.

What is the difference between nslookup and dig?

Both query DNS records. nslookup is available on Windows, Mac, and Linux by default and is simpler. dig is the more powerful tool preferred by professionals — it shows fuller responses including TTL values and authority sections, and scripts more cleanly. dig is built into Mac and Linux and available on Windows via BIND tools.

How do I use nslookup with a specific DNS server?

Add the server address after the domain: nslookup example.com 8.8.8.8 queries Google Public DNS directly. This is essential for checking DNS propagation — comparing what different resolvers return tells you whether a recent DNS change has spread worldwide.

How do I check MX records with a DNS lookup command?

With nslookup: nslookup -type=mx example.com. With dig: dig example.com mx. MX records show which mail servers accept email for the domain. If email delivery is failing, missing or wrong MX records are one of the first things to check.

Why does nslookup say non-authoritative answer?

It means the response came from a caching resolver rather than the nameserver that officially holds the zone. This is normal and the data is usually accurate. To get an authoritative answer, query one of the nameservers of the domain directly, for example nslookup example.com ns1.example-nameserver.com.

Terminal window running DNS lookup command with query results displayed

WHOIS & Research

nslookup and dig: DNS Lookup Commands Every Domain Owner Should Know

Domain 360 Team

·July 13, 2026·8 min read

Every domain problem I have ever diagnosed — a site that would not load, email that vanished, a DNS change that seemed stuck — started with the same thirty seconds at a terminal. Two commands, nslookup and dig, tell you what the DNS system actually believes about your domain right now, as opposed to what your registrar dashboard says it should believe.

You do not need to be a network engineer to use them. You need about eight commands, and this guide covers all of them.

Opening the Terminal

On Windows, press the Windows key, type cmd, press Enter. On Mac, open Terminal from Applications, Utilities. On Linux, you already know.

nslookup is preinstalled on all three systems. dig is preinstalled on Mac and Linux; Windows users can either use nslookup for everything in this guide or install BIND tools for dig.

The Basic Lookup: What Does This Domain Point To?

The simplest question DNS answers is which IP address a domain resolves to.

With nslookup: nslookup domain360.site

With dig: dig domain360.site

Both return the A record — the IPv4 address of the server behind the domain. If a website is down, this is the first check. Three outcomes tell three different stories. An IP comes back and the site still fails: the problem is the server or hosting, not DNS. Nothing comes back or you see NXDOMAIN: the domain does not resolve at all — it may have expired, or its nameservers are broken. The wrong IP comes back: DNS is pointing somewhere it should not, often after a botched migration.

That NXDOMAIN case deserves emphasis. If a previously working domain suddenly returns NXDOMAIN, check the expiry immediately with a WHOIS lookup. An expired domain whose DNS has been suspended produces exactly this symptom, and the sooner it is caught, the cheaper the recovery. Our guide on what happens to your email when your domain expires covers why the damage extends well beyond the website.

Querying Specific Record Types

DNS holds more than IP addresses. Each record type answers a different question, and both tools let you request them directly.

MX records — where does email go?

nslookup -type=mx domain360.site dig domain360.site mx

If email to a domain is bouncing, compare the MX records against what the email provider says they should be. A missing MX record, or one still pointing at an old provider after a migration, explains most sudden email failures.

TXT records — verification and email security

nslookup -type=txt domain360.site dig domain360.site txt

TXT records hold SPF and DKIM policies, plus verification strings for services like Google Search Console. If emails from your domain land in spam, checking that the SPF record exists and is correct is step one.

NS records — which nameservers control the domain?

nslookup -type=ns domain360.site dig domain360.site ns

This shows which nameservers the DNS system currently trusts for the domain. After changing nameservers at your registrar — say, moving to Cloudflare — this query confirms whether the change has actually taken effect.

CNAME records — aliases

nslookup -type=cname www.domain360.site dig www.domain360.site cname

CNAMEs point one name at another. Subdomains like www or blog are often CNAMEs to a hosting platform.

Querying a Specific DNS Server

By default, these commands ask whatever resolver your computer uses — your ISP or your configured DNS. You can ask any resolver directly by naming it:

nslookup domain360.site 8.8.8.8 dig @8.8.8.8 domain360.site

That queries Google Public DNS. Swap in 1.1.1.1 for Cloudflare.

This is the single most useful trick in DNS troubleshooting, because it lets you check propagation. When you change a DNS record, resolvers around the world update at different speeds as their caches expire. Query three or four public resolvers; if some return the new value and others the old, the change is still propagating — normal for up to 48 hours. If every resolver returns the old value long after the change, the record was probably not saved correctly at the DNS host.

You can also query the authoritative nameserver directly — the server that officially holds the zone:

dig @ns1.your-dns-host.com domain360.site

If the authoritative server shows the new value, the change is live at source and the rest is just cache patience.

Reading dig Output

dig returns more than nslookup, and two parts are worth understanding. The ANSWER SECTION contains the records you asked for. Each line shows the name, a number, the class, the type, and the value — the number is the TTL, the seconds remaining before caches must refresh this record. A TTL of 3600 means up to an hour of caching; this is why DNS changes are not instant. The status field near the top should read NOERROR; NXDOMAIN means the name does not exist, and SERVFAIL means the nameservers themselves are failing.

The Cheat Sheet

Site down? nslookup yourdomain.com — no answer means DNS or expiry, an answer means hosting. Email failing? nslookup -type=mx yourdomain.com — verify mail servers. Spam folder issues? nslookup -type=txt yourdomain.com — verify SPF. Changed nameservers? nslookup -type=ns yourdomain.com — confirm the switch. Change not showing? dig @8.8.8.8 yourdomain.com and compare resolvers — measure propagation.

These commands diagnose problems after they appear. Preventing the most expensive one — a domain quietly expiring — is a monitoring job, and a domain management dashboard that watches every expiry date and alerts you weeks ahead means you rarely need the emergency toolkit at all.

Never lose a domain again

Track every domain you own in one dashboard. Free for up to 15 domains.