Where the answers come from
Every lookup on this page is sent to three public recursive resolvers: Cloudflare 1.1.1.1, Google 8.8.8.8 and Quad9 9.9.9.9. A recursive resolver answers from its cache when it can and otherwise walks the hierarchy for you, asking a root server, then the servers for the top-level domain, then the zone's own authoritative nameservers. What you see is the answer those resolvers hold right now, which may be a cached copy up to one TTL old.
The All Records button fans out eight queries at once (A, AAAA, CNAME, MX, NS, TXT, SOA and CAA) plus a ninth TXT query for _dmarc.yourdomain, which feeds the security summary. Picking a single type runs just that query, and SRV is available on its own for service discovery names such as _sip._tcp.example.com. The query time shown next to the export buttons is the wall-clock time for the whole batch.
You can paste a full URL. The protocol, path and query string are stripped before the name is validated. Service labels such as _dmarc and _domainkey are accepted, so selector._domainkey.example.com with the TXT type returns a DKIM public key directly. Names under .local, .internal or localhost are refused because they can never have a public answer.
What each record type tells you
Records are grouped by type, each in its own table with the name, the value and, where known, the TTL in seconds. The TTL column only carries a value for A and AAAA rows: the resolver library used on the server exposes TTLs for address records alone, so other types show a dash rather than a guessed number.
- A and AAAA: the IPv4 and IPv6 addresses a client connects to. Several rows mean round-robin or multiple front ends.
- CNAME: an alias to another name. A name with a CNAME cannot hold other records at the same name, which is why apex domains use A records instead.
- MX: the mail exchangers for the domain with a priority. Senders try the lowest number first and use equal numbers interchangeably.
- NS: the nameservers the zone claims are authoritative. Compare them with the delegation shown by the WHOIS and RDAP lookup.
- TXT: free text, in practice SPF policies, DMARC, DKIM keys and ownership verification strings. Multi-part strings are joined for display.
- SOA and CAA: the SOA row shows the primary nameserver, hostmaster address, serial and the refresh, retry, expire and minimum timers. A CAA row shows flags, a tag (issue, issuewild or iodef) and the authority allowed to issue.
The SPF, DMARC and CAA summary
The ribbon under the overview reports three presence checks. SPF is Active when a TXT record at the domain starts with v=spf1. DMARC shows the policy from the p= tag of the v=DMARC1 record found at _dmarc.yourdomain, so you will see none, quarantine or reject. CAA is Protected when at least one CAA record exists. The sentence beneath the record tables repeats the same findings in words.
These are presence checks, not full evaluations. A v=spf1 record that exceeds ten DNS lookups or lists a dead include still shows as Active here. Run the SPF checker to expand the whole include tree and count lookups. Likewise the DMARC checker validates every tag and the reporting addresses, and the DKIM checker covers the selector-specific keys this summary cannot see.
A typical healthy set looks like this: a TXT record of v=spf1 include:_spf.google.com -all, a _dmarc TXT of v=DMARC1; p=reject; rua=mailto:dmarc@example.com and a CAA record of 0 issue "letsencrypt.org". A domain that sends no mail at all should still publish v=spf1 -all and p=reject so nobody else can send as it.
Empty results, failed queries and errors
An empty table and the message that no active records were found is a real answer: the resolvers replied that the name has no data of that type (NODATA) or does not exist at all (NXDOMAIN). Nothing was guessed. For a brand-new domain, or a subdomain nobody created, this is the expected result.
A yellow box titled Some lookups failed is different. It lists record types whose query ended in an error such as SERVFAIL or a timeout, with the error code in brackets, and their absence from the tables below is not an answer. One common cause is DNSSEC: all three resolvers validate signatures, so a zone with an expired or mismatched signature returns SERVFAIL everywhere. The DNSKEY lookup and DS lookup tools show both halves of the chain.
If every requested type fails the page shows one error instead of empty tables, and an invalid name is rejected before any query is sent. A 429 response means the per-minute limit for your IP address was reached. Wait the number of seconds given in the message and try again.
Caching, propagation and sharing a result
Because the three resolvers are shared by millions of clients, a record you changed a minute ago may still appear with its old value here until the cached copy expires. The TTL on an A row is the remaining lifetime in that resolver's cache, not necessarily the value in your zone file. Lower the TTL a day before a migration and raise it again afterwards.
To see whether a change has reached resolvers around the world, and how they compare with your authoritative servers, use the DNS propagation checker. For a scored audit of nameserver, SOA, mail and DNSSEC settings in one pass, the DNS health checker is the better starting point.
Results can be copied as JSON, downloaded as JSON or saved as a tab-separated zone-style text file. Opening /dns-lookup?domain=example.com&type=MX runs that query on page load, which makes a result easy to hand to a colleague. Lookups are rate limited per visitor IP and are not stored, as described in the privacy policy.