nslookup on Windows: A Complete Guide With Examples

On Windows, nslookup is the DNS query tool that ships in the box. It is available in every version from Windows 7 through Windows 11 and Windows Server, with no install required. This guide shows how to use nslookup for real tasks: checking A records, mail records, and TXT records, switching to a specific DNS server, and understanding why its answers sometimes differ from what dig reports.

Two ways to run nslookup

nslookup has a non-interactive mode for one-off questions and an interactive mode for running several queries in a row. Both open from Command Prompt or PowerShell.

Non-interactive mode puts everything on one line and exits immediately:

C:\> nslookup example.com

Server:  UnKnown
Address:  192.168.1.1

Non-authoritative answer:
Name:    example.com
Address:  93.184.216.34

Interactive mode starts a session you can keep typing into. Launch it by running nslookup with no arguments, then issue commands one per line, and type exit when done.

C:\> nslookup
Default Server:  dns.google
Address:  8.8.8.8

> example.com
> set type=MX
> example.com
> exit

Reading the output

The first thing nslookup prints is the resolver it is using, under Server and Address. The phrase Non-authoritative answer simply means the response came from a resolver's cache rather than from the domain's own nameserver. That is normal and expected for almost every lookup, not a warning.

If you see Server: UnKnown, nslookup could not do a reverse lookup on your configured resolver's IP. The queries still work; the label is cosmetic.

Querying different record types with set type

By default nslookup asks for A (and AAAA) records. To look at anything else, set the query type first. In interactive mode this persists until you change it again.

A full interactive session to inspect a domain's mail setup looks like this:

C:\> nslookup
> set type=MX
> google.com
google.com  MX preference = 10, mail exchanger = smtp.google.com

> set type=TXT
> google.com
google.com  text = "v=spf1 include:_spf.google.com ~all"

> set type=NS
> google.com
google.com  nameserver = ns1.google.com

Querying a specific DNS server

To bypass your configured resolver and ask a particular server, add its address at the end in non-interactive mode, or use server in interactive mode. This is the key technique for checking whether a change is live at the source.

# Non-interactive: ask Cloudflare directly
C:\> nslookup example.com 1.1.1.1

# Interactive: switch the server for the rest of the session
C:\> nslookup
> server 8.8.8.8
Default Server:  dns.google
Address:  8.8.8.8
> example.com

To confirm a record at the authoritative source, first find the nameservers with set type=NS, then point server at one of them. If the authoritative server shows the new value but your ISP resolver still shows the old one, the record is correct and you are simply waiting on cache expiry.

Reverse DNS lookups

Give nslookup an IP address and it performs a reverse (PTR) lookup automatically, no special flag needed.

C:\> nslookup 8.8.8.8
Name:    dns.google
Address:  8.8.8.8

Useful set options

A few more interactive settings help when a query is slow or you want more detail.

• set debug prints the full packet, including TTL values and all sections, which nslookup otherwise hides.
• set timeout=10 raises the wait time for slow or distant servers.
• set retry=1 limits retries so a dead server fails fast.
• set port=5353 queries a resolver running on a non-standard port.

The set debug option is the closest nslookup gets to dig's verbosity. It exposes the TTL, which the normal output omits, and that TTL is what tells you how long a cached answer will linger.

> set debug
> example.com
    QUESTIONS:
        example.com, type = A, class = IN
    ANSWERS:
    ->  example.com
        internet address = 93.184.216.34
        ttl = 3600 (1 hour)

A practical mail-troubleshooting example

Suppose mail to your domain is bouncing. nslookup can confirm the whole chain in one session. First check that the MX records resolve, then verify SPF exists, then confirm the mail host itself has an address. If any step returns nothing, you have found the gap.

C:\> nslookup
> set type=MX
> example.com
example.com MX preference = 1, mail exchanger = smtp.google.com
> set type=TXT
> example.com
example.com text = "v=spf1 include:_spf.google.com ~all"
> set type=A
> smtp.google.com
Name:    smtp.google.com
Address: 142.250.80.27
> exit

If the MX lookup returns a server but that server's A lookup fails, the mail exchanger name is pointing at a host with no address, which breaks delivery. nslookup walks you to the exact broken link without guessing.

Why nslookup and dig can disagree

Engineers often notice nslookup returning something slightly different from dig on the same machine. A few reasons explain almost every case.

1. nslookup can ignore the hosts file and OS resolver logic. It talks to a DNS server more directly, while many applications (and dig in some configurations) honor the local resolver stack, including the Windows DNS Client service cache.
2. They may query different servers. nslookup uses the first configured DNS server; your application or dig may use a different one or a different interface.
3. nslookup hides TTLs and flags by default. It also silently appends your connection-specific DNS suffix to unqualified names, so server1 may become server1.corp.local without warning. Always test with a trailing dot or a fully qualified name to avoid this.
4. Caching layers differ. The Windows DNS Client service keeps its own cache. Clear it with ipconfig /flushdns before retesting.

Because of the suffix behavior and hidden TTLs, treat nslookup as a fast first look rather than the final word. When the result has to be exact, cross-check it.

Checking the local Windows cache

Before blaming a DNS server, confirm what Windows itself has cached. Two commands cover it.

# View the current resolver cache
C:\> ipconfig /displaydns

# Clear it, then retest
C:\> ipconfig /flushdns
Successfully flushed the DNS Resolver Cache.

Where to go from here

nslookup gives you one view, from one machine, through one resolver. That is perfect for a quick check and poor for answering the real question during a migration: has the change reached everyone yet? To see your record from dozens of networks around the world at once, run the same lookup through the Valla DNS propagation checker and compare regions side by side. Pair it with our guides on flushing your DNS cache and reading TTLs, and nslookup becomes the fast local probe in a much more reliable workflow.