To use nslookup on Mac, open Terminal, type nslookup example.com, and press Return. macOS includes nslookup, so you do not need to install anything. Replace example.com with the domain you want to check.

How to run nslookup on a Mac

Press Command-Space, search for Terminal, and open it.
Enter a hostname, without https:// or a page path:
```
nslookup example.com
```
Read the answer below the DNS server information. The first Address belongs to the server that answered your query, not the website.

For an explicit IPv4 lookup, use nslookup -type=A example.com. For IPv6, use nslookup -type=AAAA example.com. You can also use the built-in dig and host commands when you want a different output format.

Prefer a Mac app? NetUtil’s Lookup form lets you choose a record type and DNS server without typing a command.

What a DNS lookup actually does

When you type a domain name into your browser, your Mac asks a DNS resolver (usually your ISP’s or a public one like 1.1.1.1) to translate that name into an IP address. The resolver looks up the answer and your computer connects to that IP.

A DNS lookup lets you run that translation yourself and inspect the result. You can see which IP a domain resolves to, what mail servers handle its email, and which nameservers are authoritative for it. This covers most day-to-day debugging.

Common record types worth knowing:

A: IPv4 address (the main one you’ll look up)
AAAA: IPv6 address
MX: Mail server, with priority
CNAME: Alias pointing to another domain
TXT: Text records, used for SPF, DKIM, domain verification
NS: Nameservers authoritative for the domain

nslookup on Mac: the familiar starting point

The command syntax is nslookup [options] hostname [dns-server]. Leave out the final argument to use the command’s default DNS server, or provide a server address to query it directly.

Basic A record lookup

nslookup -type=A example.com

Read the output in two parts:

Server / Address at the top identifies the DNS server that answered. A suffix such as #53 is its port.
Name / Address in the answer identifies the hostname and its returned IP address. A domain can have more than one address.

Non-authoritative answer means the responding server is not authoritative for that name. It is common when querying a recursive resolver, which may serve cached data. It is not an error.

Look up a specific record type

nslookup -type=MX example.com

Replace MX with a record type such as A, AAAA, CNAME, TXT, NS, or SOA. For example, these commands check IPv6 addresses, text records, and nameservers:

nslookup -type=AAAA example.com
nslookup -type=TXT example.com
nslookup -type=NS example.com

Query a specific DNS server

Put the DNS server address after the hostname. These examples query Google Public DNS and Cloudflare directly; they do not change your Mac’s DNS settings:

nslookup -type=A example.com 8.8.8.8

nslookup -type=A example.com 1.1.1.1

Different answers can reflect cached records, geographic routing, or different DNS policies. Matching answers confirm what those servers return now; they do not prove every resolver has received a change. For a company or VPN-only hostname, query the DNS server supplied by that network.

Reverse lookup: find a name for an IP address

nslookup 8.8.8.8

An IP address triggers a reverse lookup for its PTR record. Not every address has one, and the returned name does not list every website hosted at that address.

nslookup interactive mode

Type nslookup with no arguments and you get a prompt. From there you can run multiple queries without retyping the command:

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

Common nslookup errors

NXDOMAIN: The queried name does not exist according to that DNS response. Check spelling and the exact hostname, including any subdomain.
No answer: The name may exist without the record type you requested. Try A or AAAA, and check the full response with dig.
SERVFAIL: The server could not complete the query. Compare another resolver; causes can include an authoritative server problem or DNSSEC validation failure.
Connection timed out / no servers could be reached: No usable response arrived. Check your connection and whether the selected DNS server is reachable from your network.

If your shell reports command not found, try /usr/bin/nslookup example.com. That uses the built-in executable directly instead of relying on your shell’s search path.

For more options, read man nslookup on your Mac or ISC’s nslookup reference.

dig: the power tool for DNS on Mac

dig (Domain Information Groper) is the preferred tool for sysadmins and developers who do DNS troubleshooting regularly. The output is structured and consistent, and the control options go much further than nslookup.

Basic lookup

dig google.com

The output is verbose by default: the question you asked, the answer section, timing, and the server that responded. That extra information is useful when you’re debugging, because you can see exactly what was returned and how long it took.

Get just the answer with +short

When you want a quick answer without the surrounding detail:

dig google.com +short

This produces a compact answer, which can include an alias as well as IP addresses. For mail records:

dig google.com MX +short

Returns the MX records with priorities, one per line.

Query specific record types

dig google.com MX
dig google.com TXT
dig google.com NS
dig google.com AAAA

Query a specific DNS server

dig @8.8.8.8 yourdomain.com
dig @1.1.1.1 yourdomain.com
dig @9.9.9.9 yourdomain.com

The @ syntax specifies the resolver. This is the cleanest way to check DNS propagation across multiple public resolvers.

Trace the full resolution path

dig google.com +trace

This follows referrals from the root servers toward the domain’s authoritative servers. It can help locate delegation problems, but a network that blocks direct DNS queries can also prevent the trace from completing.

Request DNSSEC records

dig google.com +dnssec

Requests DNSSEC records, such as signatures, when available. +dnssec does not itself validate the answer or prove the domain’s DNSSEC configuration is correct.

host: the quick-read option

host gives clean, human-readable output with minimal configuration. It’s the right choice when you want a fast answer and don’t need the full detail that dig provides.

host google.com

By default, host asks for A, AAAA, and MX records. Output may look like this illustrative example; actual addresses and mail records can change:

google.com has address 142.250.80.46
google.com has IPv6 address 2607:f8b0:4004:c1b::65
google.com mail is handled by 10 smtp.google.com.

For a specific record type:

host -t MX google.com
host -t TXT google.com

host lacks the advanced options of dig, but its output is immediately readable without any flags.

Which tool to use when

nslookup: cross-platform familiarity and quick spot checks, with verbose output and mixed messages.
dig: propagation checks, scripting, and full traces, with structured output. Add +short for a clean answer.
host: a fast human-readable answer with no flags needed, in concise plain text.
dig +short: scripting, batch checks, and minimal output, with only the answer.
dig +trace: finding where DNS resolution breaks, with the full chain from root servers down.
NetUtil: DNS lookups without typing command syntax, using its Lookup form and nslookup text output.

Quick reference: which DNS tool to reach for depending on what you need.

Real-world use cases

Verifying DNS propagation after changing hosting

You moved your site to a new server and updated the A record. Now you want to know if the change has propagated before you cancel the old hosting.

dig @8.8.8.8 yourdomain.com +short
dig @1.1.1.1 yourdomain.com +short
dig @9.9.9.9 yourdomain.com +short

These checks show what three public resolvers return. They are useful comparisons, but matching answers do not establish a worldwide completion time. Compare them with the records at your DNS provider, and account for any deliberate geographic differences.

To inspect the TTL returned by one resolver:

dig @1.1.1.1 yourdomain.com

In the answer section, the number after the record name is the TTL in seconds. For a cached answer, it usually indicates the remaining cache lifetime. A TTL of 300 is five minutes, but it does not tell you when every other resolver will refresh.

Debugging email deliverability with MX records

Email isn’t arriving. Before you dig into SMTP logs, confirm the MX records are correct:

nslookup -type=MX yourdomain.com

Or with dig for cleaner output:

dig yourdomain.com MX +short

The output shows your mail server hostnames and their priorities. A lower number means higher priority. Compare the hostnames with your email provider’s instructions; a mismatch is one possible cause of delivery problems.

Also check the domain’s TXT records for SPF:

dig yourdomain.com TXT +short

An SPF record starts with v=spf1. DKIM uses a separate name containing the selector supplied by your email provider:

nslookup -type=TXT selector._domainkey.example.com

Replace selector and example.com with your provider’s values. DNS records are one part of email troubleshooting; their presence alone does not confirm successful delivery.

Debugging why a site loads to the wrong IP

Your domain resolves to an old server IP even though you updated the A record an hour ago.

First, check what the command’s default DNS server returns:

dig yourdomain.com +short

Then check what an external resolver sees:

dig @8.8.8.8 yourdomain.com +short

If they differ, check which server each query used and compare the records in your DNS provider’s control panel. A cached answer is one possible explanation. If both return an unexpected IP, verify the exact hostname, its A or AAAA records, aliases, and authoritative nameservers before assuming the change was not saved.

Checking if a CNAME is set up correctly

dig yourdomain.com CNAME +short

This asks for the target of a CNAME record. Empty +short output alone does not explain the result: run dig yourdomain.com CNAME to inspect the status and answer section. The name might use an A record instead, or the query might have failed.

Why nslookup can differ from Safari or a VPN app

On macOS, nslookup, dig, and host do not use the same native name-resolution and DNS-routing mechanisms as other apps. A successful lookup therefore does not guarantee that Safari or a VPN-connected app will resolve the hostname the same way. You can read this caveat locally with man nslookup or man dig under macOS NOTICE.

Clearing your Mac’s cache does not clear a public resolver’s cache. If the problem is stale results in an app, see the separate macOS DNS cache guide. If you want to change which resolver your network uses, see how to change DNS settings on Mac.

DNS lookups without Terminal

NetUtil provides a Mac interface for the built-in nslookup command. In the current app:

Select Lookup in the sidebar.
Enter a domain in Hostname or IP address and choose a Record type, such as A, AAAA, MX, or TXT.
Optionally enter a server such as 1.1.1.1 in DNS server.
Click Lookup to see the command’s text output in the window. You can select and copy the result.

For example, example.com, record type MX, and server 1.1.1.1 correspond to nslookup -type=MX example.com 1.1.1.1. The form saves you typing flags; the DNS server and record type still determine the answer, with the same macOS routing caveats described above.

For occasional checks, the form keeps the inputs visible. For scripts or repeated batch queries, use the Terminal commands above.

Pick the right tool for the job

nslookup is fine for quick spot checks, especially if you’re already familiar with it. dig is better for anything involving propagation verification, scripting, or digging into DNS behavior. host is the fastest path to a human-readable answer when you just need to know what an IP resolves to.

All three query the same DNS system. The differences are in presentation and control. Use whichever one gives you the information you need without slowing you down.