What Is a Domain Lookup and What Can It Tell You About a Domain?

A domain lookup is a query that pulls the public records attached to a domain name: its DNS records, its registration data, its subdomains, the networks behind its IP addresses, and its email authentication setup. On digga, one search box accepts an apex domain, a subdomain, or a full URL and returns all of these in a single report, free and without an account. Use it when you are debugging a deploy, triaging an incident, checking whether a domain is safe to trust, or just curious who is behind a name.

The six things a full lookup covers

digga bundles six tools behind one search. Each also has its own dedicated page if you only need one angle.

The subdomain finder is passive: it reads public sources and sends no traffic to the target, so you can enumerate a domain you do not control without touching its servers.

Reading DNS records: what each type actually tells you

DNS is the part people skip past, but each record type answers a different question. Here is what to look for.

• A and AAAA — the IPv4 and IPv6 addresses the name points to. If a site is down, this is the first place to confirm it still resolves, and to check whether it moved.
• CNAME — an alias. A www CNAME pointing at a hosting provider's hostname tells you where the site is actually served from.
• MX — where email for the domain is delivered. A missing or unexpected MX is a common cause of "our email stopped working."
• NS — the authoritative nameservers. These tell you which DNS provider controls the zone, which matters when you are about to change DNS and need to know who to change it with.
• TXT — free-form text, and the home of verification tokens and email policy records. SPF and DMARC both live here.
• CAA — which certificate authorities are allowed to issue certificates for the domain. A restrictive CAA is a real anti-misissuance control.
• DNSSEC records (DNSKEY, DS) — whether the zone is cryptographically signed. If DS exists at the parent but DNSKEY does not resolve, the domain is misconfigured and validating resolvers will fail it.
• SOA, SRV, PTR, NAPTR — zone metadata, service locations, reverse lookups, and service discovery. Less common, but SOA is useful for finding the zone's primary nameserver and contact.

Because digga queries resolvers live, you can switch between Cloudflare, Google, and Alibaba DoH and compare. If one resolver returns a different answer than another, you are usually looking at propagation lag or a split-horizon setup — a genuinely useful signal during a migration.

RDAP vs WHOIS: why the order matters

Both answer "who registered this and when," but they are not the same format.

• RDAP returns structured, machine-readable data: registrar, domain status codes, creation and expiry events, and DNSSEC status, each as a labeled field.
• WHOIS returns raw text in whatever format the registry happens to use, which varies by TLD.

digga queries RDAP first and falls back to raw WHOIS when a registry has not caught up. In practice this means you get clean fields most of the time and still get an answer for the TLDs that lag. What you can reliably read from either: the registrar, the nameservers, the domain status (for example whether it is on client-hold or pending delete), and the creation and expiry dates. Expiry is the one to watch — a domain expiring in days is a real operational risk.

Judging email security from SPF, DKIM, and DMARC

This is the part of a lookup with the most direct security payoff, because it tells you how easily someone could send mail pretending to be that domain.

• SPF lists which servers may send mail for the domain. The catch is the lookup limit: SPF allows a maximum of 10 DNS lookups, and exceeding it silently breaks the policy. digga checks that limit for you, which is the failure most people miss.
• DKIM publishes a public key so recipients can verify a signature on outgoing mail. A missing DKIM record means mail cannot be cryptographically tied to the domain.
• DMARC tells receivers what to do when SPF and DKIM fail, and where to send reports. The policy value is the headline: p=none only monitors, p=quarantine sends failures to spam, and p=reject blocks them outright. A domain with no DMARC record at all is straightforward to spoof.
• MTA-STS and TLS-RPT enforce and report on encrypted mail transport.
• BIMI controls the verified logo shown next to mail in supporting clients.

Read together, these tell you whether the domain is defended or wide open. A domain with a strict DMARC policy, valid DKIM, and a passing SPF is hard to impersonate. One with none of them is trivial.

Running a full lookup, step by step

1. Enter the target. Type an apex domain, a subdomain, or paste a full URL. digga normalizes it, so you do not need to strip https:// or paths yourself.
2. Start with DNS. Confirm the name resolves and check the record types that matter for your task — A/AAAA for reachability, MX for mail, NS for control, CAA and DNSSEC for security posture.
3. Check registration. Read the RDAP result for registrar, status, and expiry. If the registry has not caught up, the WHOIS fallback fills the gap.
4. Enumerate subdomains. Trigger the subdomain finder to see what else is exposed. Results stream back as they are found, so you can start reading before the scan finishes.
5. Map the infrastructure. Click through the A and AAAA records to see the ASN, network owner, and geolocation behind each address.
6. Audit email security. Open the email security view and read SPF, DKIM, DMARC, MTA-STS, TLS-RPT, and BIMI together, with the SPF lookup count already validated.

Common snags and what they mean

• A record missing but the site works — the name may be CNAME'd elsewhere, or served only over IPv6. Check AAAA and CNAME before concluding anything is broken.
• Different answers from different resolvers — usually propagation lag after a change, or intentional split-horizon DNS. Compare resolvers to tell which.
• SPF present but mail still fails — almost always the 10-lookup limit. The check flags this so you do not have to count manually.
• No RDAP data — some registries are slow to support it. The WHOIS fallback exists precisely for this.
• DNSSEC half-configured — a DS record without a matching DNSKEY breaks validation for everyone using a validating resolver. Treat it as urgent.

When to use this

Reach for a full domain lookup when you are debugging a deploy or DNS change, triaging a mail or deliverability incident, evaluating whether a domain is trustworthy before interacting with it, or auditing your own domain's spoofing resistance. digga is open source under AGPL 3.0, needs no account, and has browser extensions for Chrome and Firefox that let you right-click any page to dig its domain without copying anything.