Look up any domain's DNS records, or the reverse DNS of an IP address, and get a plain-English note on what each record does. Compare two public resolvers to see whether a change has spread yet.
A full link or an email address works too; only the domain is used. An IP address gets a reverse (PTR) lookup.
The name you look up is sent to Cloudflare's public DNS resolver, and to Google Public DNS when you compare or if Cloudflare does not answer. Nothing else leaves your browser.
What happens in a DNS lookup
DNS is the internet's directory. When you type a domain, your device asks a resolver, usually run by your internet provider or a public service such as Cloudflare's 1.1.1.1 or Google's 8.8.8.8. If the resolver has no fresh copy, it walks the hierarchy: the root servers point it to the servers for the top-level domain, those point it to the domain's own authoritative name servers, and those give the answer. The resolver then keeps that answer for as long as its TTL, or time to live, allows, and hands the same copy to everyone who asks in the meantime.
This tool asks Cloudflare's public resolver over an encrypted connection, the same way a modern browser can, so you see what most of the internet sees rather than what your own network might have cached.
The record types
| Type | What it holds | Example |
|---|---|---|
| A, AAAA | The IPv4 or IPv6 address a name points to | 203.0.113.10 |
| CNAME | An alias: look this other name up instead | www → example.netlify.app |
| MX | The servers that receive email, with a priority | 1 aspmx.l.google.com |
| NS | The name servers that hold the domain's records | ns1.example-dns.com |
| TXT | Free text, used for SPF, DMARC and ownership checks | v=spf1 include:_spf.google.com ~all |
| SOA | Settings for the zone as a whole | Serial, refresh, negative TTL |
| CAA | Which certificate authorities may issue SSL certificates | 0 issue "letsencrypt.org" |
| SRV | The host and port for a named service | _imaps._tcp → imap.gmail.com:993 |
| PTR | Reverse DNS: the name for an IP address | 8.8.8.8 → dns.google |
Why a change has not shown up yet
"Propagation" is really cache expiry. A resolver that fetched your old record keeps serving it until that record's TTL runs out, so the wait after an edit is set by the TTL the record had before you changed it. Before a planned move, lower the TTL to a few minutes and wait out the old value; then the switch itself takes minutes.
Two other caches catch people out. If anyone looked up a record before you created it, resolvers remember that it did not exist for the zone's negative TTL, the last number in the SOA record. And a change of name servers is made at your registrar and published by the registry for the top-level domain, whose delegation is commonly cached for up to two days. Tick Compare Cloudflare and Google to check two large resolvers side by side.
Reading the answers
- No records means the name exists but has nothing of that type. A domain with no MX record, for instance, still has its website.
- Does not exist (NXDOMAIN) means the name itself is not in DNS. Check for a typo, or that the record was created in the zone your name servers actually serve.
- Server failure (SERVFAIL) means the domain's name servers did not give a usable answer. The tool then repeats the question with DNSSEC checking switched off. If that works, the records are there but their signatures are broken, often because the domain moved to a new DNS host while the registrar still publishes the old DNSSEC key.
- An alias that leads nowhere is a CNAME whose target does not exist. If the target was on a cloud service where anyone can register that name, someone else could claim it and serve content on your domain, so remove or repoint it.
DNSSEC
DNSSEC adds signatures to DNS answers so a resolver can prove they came from the domain's owner and were not altered. The tool shows the result the resolver reports. Most domains are not signed, which is normal. A signed domain whose signatures fail is the case that matters, because validating resolvers then refuse to answer at all, and the domain disappears for a large share of the internet.
Email records
SPF and DMARC are TXT records, and DKIM keys are TXT records on their own names. The notes here say what each one declares; for a full verdict on whether mail from a domain will be trusted, including SPF's ten-lookup limit and DMARC alignment, use the Email Deliverability Checker. To pull the domain out of a long tracking link first, the URL decoder breaks any address into its parts.
