What Is a Domain Dig and How Do You Run One?

A domain dig is a DNS query that asks a resolver for the records attached to a domain name — the A record behind a website, the MX records behind its email, the TXT records behind its SPF policy, and so on. You can run one from a terminal with the dig command, or from a browser with a free lookup tool like digga, which queries DNS over HTTPS and adds RDAP/WHOIS, subdomain, and email-security data in the same report. Use the command line when you want raw control over the resolver and query flags; use a web tool when you want a readable answer plus registration and email context without installing anything.

What "dig" actually means

dig (domain information groper) is a command-line DNS client. It sends a query to a resolver and prints the response. It is not a domain availability checker and it does not tell you whether a name is for sale — it reports what DNS currently says about a name that already exists in the DNS system.

A "domain dig" in everyday use means any DNS lookup of that kind, whether run in a terminal or through a web interface. The core question is always the same: what records does this name resolve to, and from which resolver did that answer come?

Which record types to query and what each tells you

For a quick health check, start with A/AAAA (is the site reachable?), MX (is email routed?), NS (who controls the zone?), and TXT (what policies are published?). CAA and DNSSEC records matter when you care about certificate issuance and spoofing resistance.

Running a dig from the command line

The basic form is:

dig example.com A

Input: a domain name and a record type. Action: your system's configured resolver is queried. Expected result: an ANSWER section with the record, a TTL, and a header showing the resolver's status (NOERROR, NXDOMAIN, SERVFAIL).

Useful variations:

• dig example.com MX — mail routing.
• dig example.com ANY — many resolvers now refuse or truncate ANY; query specific types instead.
• dig @1.1.1.1 example.com A — query a specific resolver rather than your default.
• dig +short example.com — answers only, no header or sections.
• dig +trace example.com — walk the delegation chain from the root down, useful for spotting where a delegation breaks.

Reading the output: the header names the resolver used and the status code; the ANSWER section holds the records you asked for; AUTHORITY holds the nameservers for the zone; ADDITIONAL often carries glue addresses. TTL tells you how long a resolver may cache that answer — a low TTL means changes propagate faster.

Running a dig with a web tool like digga

digga runs the same kind of query through DNS over HTTPS and lets you switch resolvers live between Cloudflare, Google, and Alibaba DoH. The workflow is:

1. Enter an apex domain, subdomain, or full URL — digga normalizes it to the domain.
2. Read the DNS report for A, AAAA, MX, NS, TXT, CAA, DNSKEY, DS, SOA, SRV, PTR, NAPTR, and CNAME records.
3. Switch the DoH resolver to compare answers if one resolver looks stale or wrong.
4. Open the companion views for RDAP (with raw WHOIS as fallback), passive subdomain discovery from public sources such as Certificate Transparency logs, IP/ASN ownership for each A and AAAA record, and email authentication (SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI, with the SPF lookup limit checked).

The advantage over a bare dig is context: the same report shows who registered the domain, which network hosts it, and whether its email setup resists spoofing. The tool is open source under AGPL 3.0 and requires no account.

Combining DNS with registration and email data

DNS alone answers "where does this point right now." Pair it with:

• RDAP/WHOIS — registrar, nameservers, domain status, creation and expiry dates. RDAP returns structured data; WHOIS is the raw fallback when a registry has not caught up.
• Subdomain discovery — passive enumeration from public sources, with no traffic sent to the target, useful for mapping an attack surface or finding forgotten staging hosts.
• Email authentication — SPF, DKIM, DMARC, MTA-STS, TLS-RPT, and BIMI in one view, so you can see how well a domain resists spoofing.

Together these turn a single record lookup into a picture of a domain's infrastructure, ownership, and mail posture.

Common failures and what they mean

• NXDOMAIN — the name does not exist in DNS. Check for typos, or confirm the domain is actually delegated.
• SERVFAIL — the resolver could not get a valid answer, often a broken delegation or an unreachable authoritative server.
• Wrong resolver — different resolvers can return different answers during propagation; compare two before concluding something is broken.
• Propagation delays — a recent change may still be cached under the old TTL. Query the authoritative nameserver directly to see the current state.
• Empty ANSWER with NOERROR — the name exists but has no record of that type; common when a domain has A records but no MX.

If a web tool and your terminal disagree, check which resolver each is using — that is usually the whole explanation.