How to Run a DNS Dig for Any Domain (and Read the Results)

"Google dig" usually means one of two things: querying DNS through Google's public resolvers (8.8.8.8 / 8.8.4.4), or running the dig command-line tool and pointing it at Google's resolver. Both get you the same records; the difference is whether you type a command or click a button. If you have a terminal, dig gives you the most detail. If you don't, an online DNS lookup does the same job in a browser. Below are the exact commands, the fields worth reading, and how to tell a real failure from a caching artifact.

First, pick your entry point

dig is standard on macOS and most Linux distributions. On Windows it's often absent, so either use WSL, install BIND tools, or fall back to a browser lookup.

Running dig from the command line

The basic form is dig [@resolver] name [type]. To query a domain's A records through Google's public DNS:

dig @8.8.8.8 example.com A

To use Google's secondary resolver, swap in @8.8.4.4. Common record types you'll actually need:

dig @8.8.8.8 example.com A        # IPv4 address
dig @8.8.8.8 example.com AAAA     # IPv6 address
dig @8.8.8.8 example.com MX       # mail servers
dig @8.8.8.8 example.com TXT      # SPF, DKIM, verification strings
dig @8.8.8.8 example.com NS       # authoritative nameservers
dig @8.8.8.8 example.com CNAME    # alias target
dig @8.8.8.8 example.com CAA      # which CAs may issue certs

Add +short to strip everything but the answer:

dig @8.8.8.8 example.com MX +short

What you should see: a header block, a QUESTION section echoing your query, an ANSWER section with the records, and an AUTHORITY section naming the nameservers responsible for the zone. If the ANSWER section is empty, the record type doesn't exist for that name even if the domain itself does.

Doing the same thing in a browser

If you don't want to install anything, an online lookup returns the same records. On digga, the DNS lookup page queries A, AAAA, MX, NS, TXT, CAA, and DNSSEC records live and lets you switch between Cloudflare, Google, and Alibaba DNS over HTTPS. That resolver switch matters: if one resolver returns a stale or empty answer, a second opinion from another provider tells you whether the problem is the domain or your resolver.

The workflow is the same as the command line — enter the apex domain, subdomain, or full URL, pick the record type, read the answer. The site also runs RDAP first with a raw WHOIS fallback for registration data, and a separate email security view that checks SPF, DKIM, DMARC, MTA-STS, TLS-RPT, and BIMI, including whether your SPF record exceeds the lookup limit.

Reading the output: the fields that matter

Status code. NOERROR means the query succeeded — it does not mean records exist. NXDOMAIN means the name doesn't exist at all. SERVFAIL means the resolver couldn't get an answer, often a broken zone or DNSSEC failure. REFUSED means the server won't answer you.

ANSWER section. The actual records. An empty ANSWER with NOERROR is normal when you ask for a type the domain doesn't publish (e.g. no MX on a domain that doesn't receive mail).

TTL. How many seconds the record may be cached. A low TTL (300s) means recent changes propagate fast; a high TTL (86400s) means you may be seeing an old value for up to a day. This is the single most common reason "the DNS change didn't take effect."

AUTHORITY section. The nameservers that own the zone. If these don't match what your registrar shows, your delegation is wrong.

Flags. aa means an authoritative answer; rd means recursion was requested. A non-authoritative answer came from a cache, not the source.

When the query fails

• NXDOMAIN on a domain you know exists — check for a typo, or that you're querying the right subdomain. The apex existing doesn't mean www or mail does.
• SERVFAIL — try a different resolver. If Google and Cloudflare both fail, the zone itself is likely misconfigured or has a DNSSEC problem.
• Timeout — your network or VPN may be blocking port 53. Switch to DNS over HTTPS, which runs over 443 and usually gets through.
• Stale answer after a change — query the authoritative nameserver directly (dig @ns1.example.com example.com A) to bypass caches, or wait out the TTL.
• Different answers from different resolvers — expected during propagation. Compare Google, Cloudflare, and Alibaba; once all three agree, the change has spread.

What dig doesn't tell you

A DNS query returns records, not ownership. To find the registrar, creation date, expiry, and domain status, you need RDAP or WHOIS — digga runs RDAP first and falls back to raw WHOIS when a registry hasn't caught up. To see which subdomains exist, you need passive enumeration from Certificate Transparency logs and public sources, which sends no traffic to the target. And to check whether a domain resists email spoofing, you read its SPF, DKIM, and DMARC records rather than its A record. DNS is one angle; a full picture combines DNS, registration data, subdomains, IP ownership, and email authentication.