You need to check a DNS record. Maybe you switched hosting providers and want to confirm your domain is pointing to the new server. Maybe your email is bouncing and you suspect an MX record problem. Or a site is loading the wrong content and you’re trying to figure out if it’s a DNS issue or something else entirely.

macOS has three built-in Terminal commands for DNS lookups: nslookup, dig, and host. They all query DNS, but each one presents results differently and suits different situations.

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

nslookup is the command most people reach for first. It exists on every operating system, so if you’ve done DNS lookups anywhere else, the syntax feels familiar.

Basic A record lookup

nslookup google.com

The output shows the DNS server that answered and the IP address. The “Non-authoritative answer” line just means the result came from a cache, not the domain’s own nameservers. That’s normal.

Look up a specific record type

nslookup -type=MX google.com

Replace MX with any record type: A, AAAA, CNAME, TXT, NS, SOA. For example, to check SPF and DKIM for email troubleshooting:

nslookup -type=TXT google.com

Query a specific DNS server

This is where nslookup gets genuinely useful. Instead of asking your default resolver (which may have cached old data), you can query a specific server directly:

nslookup google.com 8.8.8.8

nslookup google.com 1.1.1.1

Querying multiple servers lets you see whether DNS changes have propagated. If 8.8.8.8 shows your new IP but 1.1.1.1 still shows the old one, propagation is still in progress.

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
> google.com
> set type=A
> example.com
> exit

The main downside to nslookup is that its output mixes informational messages with actual results. The formatting is inconsistent across record types, which makes it harder to parse at a glance.

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 outputs only the IP address. Good for scripting or when you just want to know the result:

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 walks through the entire DNS resolution chain: root servers, TLD servers, then the authoritative nameservers for the domain. If DNS is broken somewhere in the chain, +trace will show you exactly where it fails.

Check DNSSEC validation

dig google.com +dnssec

Adds the DNSSEC signature records to the output. Useful if you’re verifying that a domain’s DNSSEC setup is correct after enabling it.

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

This returns A records, AAAA records, and MX records in one shot:

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

Command	Best for	Output style
`nslookup`	Cross-platform familiarity, quick spot checks	Verbose, mixed messages
`dig`	Propagation checks, scripting, full trace	Structured, `+short` for clean output
`host`	Fast human-readable answer, no flags needed	Concise, plain text
`dig +short`	Scripting, batch checks, minimal output	Bare answer only
`dig +trace`	Finding where DNS resolution breaks	Full chain from root servers down
`NetUtil GUI`	No Terminal, visual record browsing	Point-and-click, formatted results

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

If all three return the same IP, propagation is done for most users. If they disagree, some resolvers are still serving cached old data.

To see how long that cache will persist, check the TTL:

dig @1.1.1.1 yourdomain.com

In the answer section, the number between the record name and record type is the TTL in seconds. A TTL of 300 means the cache clears in 5 minutes. A TTL of 86400 means you might be waiting 24 hours.

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. If the hostnames don’t match what your email provider told you to set, that’s your problem.

Also check TXT records for SPF and DKIM while you’re at it:

dig yourdomain.com TXT +short

Your SPF record will look like v=spf1 include:... ~all. If it’s missing or malformed, that’s why messages are going to spam.

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 your local resolver sees:

dig yourdomain.com +short

Then check what an external resolver sees:

dig @8.8.8.8 yourdomain.com +short

If they differ, your local resolver cached the old answer. You can either wait for the TTL to expire or flush your local DNS cache:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

If both resolvers show the same wrong IP, the A record itself was not saved correctly. Log back into your DNS provider and verify the record.

Checking if a CNAME is set up correctly

dig yourdomain.com CNAME +short

This returns the target domain the CNAME points to. If it returns nothing, you don’t have a CNAME at that name (you might have an A record instead, which can be intentional or a misconfiguration).

Flushing DNS cache on macOS

When you need to clear your Mac’s DNS cache after changing records or fixing a resolution issue:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

This command works on macOS Monterey, Ventura, Sonoma, and Sequoia. The mDNSResponder process handles local DNS resolution, and sending it HUP forces it to reload.

After flushing, run your dig or nslookup command again and you should see the fresh result.

If Terminal isn’t your thing

Apple removed Network Utility in macOS Monterey. That removed the only built-in GUI for DNS lookups.

NetUtil is a free replacement. Open it, type a domain in the DNS Lookup tab, select a record type, and get results formatted the same way the old Network Utility did. No commands to memorize, no flags to look up. The results are the same data you’d get from dig or nslookup, just presented without the noise.

For occasional DNS checks, a GUI removes friction. For repeated lookups or anything you’d want to script, stick with dig.

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.