DNS Lookup Explained: How to Query Any Domain's Records

An engineer I'll call Dana changed one DNS record on a Friday afternoon. She'd pointed her company's website at a new server, saved the change, and then did the sensible thing: she opened a terminal and ran a DNS lookup to confirm it worked. She typed nslookup, hit enter, and the old IP address stared back at her. The change hadn't taken. She reverted it, filed a ticket, and lost her weekend to a problem that did not exist.

Here is the strange part. The tool was not broken. The answer it gave her was, in a sense, perfectly correct. And understanding why is the fastest way to understand how DNS lookups actually work — because the machine you are reading this on already ships with a lookup tool built in, and that tool can quietly hand you an answer that is out of date without ever telling you it did anything wrong.

What a DNS Lookup Actually Is

When you ask for a domain, you are almost never talking to the server that holds the real answer. You are talking to a middleman called a recursive resolver, and it does the legwork for you. It asks a root nameserver, which points it at the right top-level-domain nameserver, which points it at the domain's own authoritative nameserver, which finally hands back the record. Resolver to root to TLD to authoritative. That's the walk.

The specification that still defines this behavior is a document from 1987, and it lays out the two ways a query can be handled:

"The two general approaches to dealing with this problem are 'recursive', in which the first server pursues the query for the client at another server, and 'iterative', in which the server refers the client to another server and lets the client pursue the query."

Your resolver does the recursive kind. It acts in the role of a resolver and returns either an error or the answer, but never referrals. To find the authoritative source it works from the name upward: the parent domain, the grandparent, and so on toward the root. If you want the longer story of how this whole system fits together, we wrote a plain-English guide to the Domain Name System.

Now, back to Dana. The reason her lookup lied is buried in one field attached to every record: the TTL, or Time To Live. It is a 32-bit integer in units of seconds, and its whole job is to tell a resolver how long it may keep an answer in memory before asking again. Resolvers lean on this hard, because a very important goal of the resolver is to eliminate network delay and name server load from most requests by answering them from its cache of prior results. Think of the TTL as an expiration date stamped on every answer. Dana's old record had not expired yet. Her resolver was simply doing its job, handing her a cached answer that was still, technically, in date.

This is the single most common reason a lookup shows the "wrong" thing. The change wasn't broken. A clock simply hadn't run out yet. "Propagation" is really just caches around the world quietly expiring on their own schedules.

Running a Lookup Yourself: nslookup, dig, and host

You already own the tools. The most famous is nslookup, which Microsoft describes plainly:

"Displays information that you can use to diagnose Domain Name System (DNS) infrastructure."

On Windows it is available as long as the TCP/IP protocol is installed, and it ships on macOS and Linux too. It runs in two modes, interactive and noninteractive. Most of the time you want the quick, noninteractive kind. Open Command Prompt, Terminal, or a shell, and type the name you want to resolve:

Want to aim the query at a specific public resolver instead of your default one, say to get a second opinion? Add the server's address on the end:

To ask for one particular kind of record, use the -type option. This is how you check DNS records of any flavor. Want the IPv6 address?

Inside interactive mode you can also flip settings on the fly. set type=MX changes which record type you're asking for, and set recurse tells the DNS name server to query other servers if it doesn't have the information.

One caveat trips people up, and it's the reason many administrators reach for a different tool. nslookup does its own DNS resolution. It is not necessarily reporting what your applications will see. Its counterpart dig, from the team behind the BIND server, is more literal about what it's doing:

"dig is a flexible tool for interrogating DNS name servers. It performs DNS lookups and displays the answers that are returned from the name server(s) that were queried."

The same man page is refreshingly blunt about the pecking order:

"Most DNS administrators use dig to troubleshoot DNS problems because of its flexibility, ease of use and clarity of output. Other lookup tools tend to have less functionality than dig."

If dig is on your system, the syntax mirrors what you'd expect. Ask for the short answer, or name a record type:

On Linux, dig and host usually come with your distribution's DNS utilities; if they're missing, install them from your package manager. None of this requires memorizing flags, though. The DNSai DNS Lookup tool runs the same queries from your browser with nothing to install, and the full DNS tools hub gathers the rest in one place.

nslookup Online vs. Your Local Resolver

A quick word on browser-based, or "online," lookups. A web nslookup is a DNS client running on someone else's server, so it queries from that machine's vantage point on the network, not yours. That's the point, not a limitation: it gives you a neutral, outside view that isn't colored by your own router or ISP cache. Just remember it may not be identical to what your local resolver hands your applications, which, if you think back to Dana, is exactly the kind of difference that turns a calm Friday into a long one.

MX Lookup: Reading a Domain's Mail Routing

Of all the lookups people run, the MX lookup is the one that saves the most weekends. MX stands for "mail exchange," and an MX record answers a deceptively simple question: when someone sends mail to this domain, which server should it go to?

Every MX record carries two things. Per the original 1986 specification, each MX matches a domain name with a preference value (an unsigned 16-bit integer) and the name of a host. The preference value is where the counterintuitive bit lives. You might assume a bigger number means a higher priority. It's the reverse:

"The preference number is used to indicate in what order the mailer should attempt deliver to the MX hosts, with the lowest numbered MX being the one to try first."

Lowest wins. A domain with a primary at preference 10 and a backup at 20 will always try the 10 first. When a sending server wants to deliver mail, its very first step is to issue a query for the MX records of the destination. That's an MX lookup, whether it knows the word or not. The modern SMTP spec restates the same idea: an SMTP client determines the address of an appropriate host running an SMTP server by resolving a destination domain name to either an intermediate Mail eXchanger host or a final target host.

Run that against your own domain and you'll see exactly where your mail is meant to land. It's the fastest way to confirm a Google Workspace or Microsoft 365 setup actually took, or to spot a stray backup MX nobody remembers adding. For the deeper mechanics of preference values, backup servers, and common misconfigurations, see our full write-up on MX records.

The Records People Actually Look Up

Once you can run a lookup, the domain opens up like a filing cabinet. Every record type has a name and an IANA-assigned number, and the ones worth knowing are a short list. Think of them as index cards, each answering a different question about the domain:

• A (type 1) — the IPv4 address a domain points to. The workhorse. More in our A record guide.
• AAAA (type 28) — the IPv6 address, for the modern internet. See the AAAA record guide.
• CNAME (type 5) — an alias pointing one name at another. A CNAME can't share a name with other records, and MX or NS targets should be real hostnames, not CNAMEs. A classic lookup gotcha.
• MX (type 15) — mail servers and their preference values, covered above.
• TXT (type 16) — free-form text, and the quiet workhorse behind email security. Our TXT lookup guide goes deeper.
• NS (type 2) — the authoritative nameservers for the domain. An NS lookup tells you who is actually in charge of the zone.
• SOA (type 6) — the "start of authority," the administrative header of a zone. An SOA lookup reveals the primary nameserver and serial number.
• PTR (type 12) — reverse DNS, mapping an IP back to a name. More below.
• CAA (type 257) — which certificate authorities are allowed to issue certificates for the domain. See the CAA record guide.
• SRV (type 33) — the location of specific services, like chat or directory servers.

Those numbers aren't trivia; they're the official codes in the IANA DNS Parameters registry. The core seven (A, NS, CNAME, SOA, PTR, MX, and TXT) were defined back in RFC 1035; AAAA came later in RFC 3596, SRV in RFC 2782, and CAA in RFC 8659. For a fuller tour, browse the DNS record types reference. And to swap the record you're querying, just change the type:

Reverse DNS and the PTR Lookup

Everything so far reads left to right: name in, address out. A reverse DNS lookup runs the other way: address in, name out. Give nslookup an IP and, as Microsoft notes, if the query is for an A or PTR resource record type, the name of the computer is returned:

Here's the trap. Reverse DNS is not simply the mirror image of forward DNS. PTR records live in a separate branch of the tree (in-addr.arpa for IPv4, ip6.arpa for IPv6), and they're controlled by whoever owns the IP block, often your hosting provider, not you. A perfectly good A record does not guarantee a matching PTR. That mismatch is a leading cause of mail getting rejected, which is why the reverse lookup matters so much for deliverability. The full story is in our guide to reverse DNS and PTR records.

Email Authentication Is Just More DNS Lookups

Now the part that surprises people. The entire modern system for stopping email spoofing is built out of ordinary DNS lookups. SPF, DKIM, and DMARC sound like separate security products. They're all just TXT records you can query with the same commands you've been using.

SPF lets a domain say which servers are allowed to send mail as it. The spec is emphatic about where it lives: SPF records MUST be published as a DNS TXT (type 16) Resource Record (RR) only. (There was once a dedicated SPF record type; it was deprecated, so don't go looking for one.) The mechanism lets a domain explicitly authorize the hosts that are allowed to use their domain names, so a receiving host can check that authorization. Do an SPF record lookup with a plain TXT query, read the result with our SPF validator, and see the SPF records guide for the ten-lookup limit that catches so many people out.

DKIM adds a cryptographic signature so a receiver can verify a message really came from the domain and wasn't tampered with. The public key sits in DNS: all DKIM keys are stored in a subdomain named "_domainkey", queried as selector._domainkey.example.com. DKIM lets a person, role, or organization claim responsibility for a message by associating a domain with it. Run a DKIM lookup with our DKIM record lookup, or read the DKIM guide.

DMARC ties the two together and tells receivers what to do when a message fails. Its preferences are stored as DNS TXT records in subdomains named "_dmarc", giving a sending organization a scalable way to express domain-level policies for message validation, disposition, and reporting. Check yours with the DMARC validator and the DMARC guide.

Two more lookups round out an email-delivery investigation. A blacklist check tests a sending IP against DNS-based block lists (RBLs and DNSBLs) to see if it's been flagged, which you can run with our blacklist / RBL check. And when a specific message goes wrong, our email header analyzer traces the path it took. It all sits under one email security overview. Curious who owns a domain in the first place? That's a WHOIS lookup: registration data rather than DNS records, but often the next question you'll ask.

Checking More Than One Domain: Bulk DNS Lookup

Every technique above works beautifully for one domain. The trouble starts at scale. If you manage a hundred domains (or you're auditing a client's portfolio for missing SPF, expired records, or a rogue MX), typing nslookup a hundred times is not a plan. It's a way to make mistakes.

This is where a bulk DNS lookup earns its keep. DNSai's Bulk DNS Lookup queries many domains at once and lays the results out side by side, so a whole portfolio's records surface in a single pass instead of one lonely command at a time. It comes in two shapes: the Domain Manager SaaS for teams who want it in the browser, and the DNS Explorer desktop app for heavier, offline work. Either way, the mass lookup turns an afternoon of copy-paste into a report you can actually read.

Putting It to Work

Strip away the acronyms and every DNS troubleshooting task is the same move (a lookup) pointed at a different record:

• Verifying a change? Query the record and remember the TTL. If you see the old value, the cache may simply not have expired yet.
• Diagnosing email? Start with an MX lookup, then TXT queries for SPF, DKIM, and DMARC, then a PTR and a blacklist check.
• Auditing security? Pull NS, SOA, and CAA records to confirm who controls the zone and who may issue its certificates.
• Handling many domains? Go straight to bulk.

Which brings us back to Dana, and her ruined Friday. She had the right tool and the right instinct. What she was missing was one idea: that a DNS lookup doesn't return the truth so much as a cached answer with an expiration date. Once you know that — once you know to check the TTL, to get a second opinion from another resolver, to read the record instead of trusting the first thing that flashes up — the tool built into your computer stops lying to you. It was never lying, really. You just had to learn to read what it said.

Sources

1. RFC 1034 — Domain Names: Concepts and Facilities — IETF / RFC Editor, November 1987. rfc-editor.org/rfc/rfc1034
2. RFC 974 — Mail Routing and the Domain System — IETF / RFC Editor, January 1986. rfc-editor.org/rfc/rfc974
3. RFC 5321 — Simple Mail Transfer Protocol — IETF / RFC Editor, October 2008. rfc-editor.org/rfc/rfc5321
4. RFC 7208 — Sender Policy Framework (SPF), Version 1 — IETF / RFC Editor, April 2014. rfc-editor.org/rfc/rfc7208
5. RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures — IETF / RFC Editor, September 2011. rfc-editor.org/rfc/rfc6376
6. RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC) — IETF / RFC Editor (Independent Submission), March 2015. rfc-editor.org/rfc/rfc7489
7. Domain Name System (DNS) Parameters — Resource Record (RR) TYPEs — IANA. iana.org/assignments/dns-parameters
8. nslookup — Microsoft Learn, September 2023. learn.microsoft.com
9. dig(1) man page — ISC BIND. linux.die.net/man/1/dig