DNS Lookup & Record Explainer
Look up A, AAAA, CNAME, MX, TXT and NS records — and finally understand what they mean.
Enter a domain name and every record type you select comes back with a plain-English explanation of what it does, plus a health check panel that flags the configuration problems that actually break websites and email: CNAME conflicts, MX records pointing at IP addresses, nameservers that don't resolve, missing SPF/DMARC, and more. Paste an IP address instead and it runs a reverse (PTR) lookup for you.
Domain or IP address (try a domain like example.com — or an IP like 93.184.216.34 for a reverse lookup)
Health check (common problems, in plain English)
Mail security (SPF · DKIM · DMARC)
DKIM selectors are chosen by each mail provider, so a missing DKIM key under the common selectors is a hint, not proof. Check your provider's docs for the exact selector.
Raw DNS-over-HTTPS responses (JSON, RFC 8484)
What is DNS, in one paragraph?
DNS (Domain Name System) is the internet's phone book. When you type
example.com, your device asks a recursive resolver (usually
run by your ISP or a public service) to translate that name into an IP address.
The resolver walks the DNS hierarchy — root servers, then the
.com servers, then the authoritative nameservers for
example.com — until it gets the answer, and caches it for the
record's TTL (time-to-live, in seconds). This tool queries that same
hierarchy over DNS-over-HTTPS (DoH): the DNS query travels encrypted inside
an HTTPS request to a public DoH endpoint, so your ISP can't see or tamper with
it. Each record type below is one kind of fact about the name.
Record type quick reference
| Type | What it does | Example |
|---|---|---|
| A | Maps a name to an IPv4 address. This is the record your browser actually connects to when you visit a website. | example.com. 3600 IN A 93.184.216.34 |
| AAAA | The IPv6 equivalent of an A record — maps a name to a 128-bit IPv6 address. | example.com. 3600 IN AAAA 2606:2800:220:1:248:1893:25c8:1946 |
| CNAME | An alias: says this name is really another name. Resolvers follow the chain until they hit a real record. A CNAME must be the only record at its name. | www.example.com. 3600 IN CNAME example.com. |
| MX | Mail exchanger: which servers receive mail for the domain, with a priority (lower = tried first). The target must be a hostname, never an IP. | example.com. 3600 IN MX 10 aspmx.l.google.com. |
| TXT | Free-form text. In practice: SPF (which servers may send mail for the domain), DKIM keys, domain-verification tokens for hosting/CDN providers, and SRV-style metadata. | example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all" |
| NS | The authoritative nameservers for the zone — the servers holding the official copy of all these records. Only exists at the zone apex (e.g. example.com, not www.example.com). |
example.com. 172800 IN NS ns1.example-dns.com. |
| PTR | Reverse lookup: maps an IP address back to a name. Used by mail servers and monitoring tools to identify where a connection came from. | 34.216.184.93.in-addr.arpa. 300 IN PTR example.com. |
How to read the health checks
Every lookup runs a set of rules against the returned records. CRIT means something is almost certainly broken — a website or mail flow will fail. WARN means a configuration that works today but is fragile or against the RFCs — fix it before it bites. INFO is context, not a problem. OK confirms something is set up correctly.
Common DNS problems and what they mean
- NXDOMAIN — "name does not exist." The domain isn't registered, the spelling is wrong, or the registrar hasn't delegated the zone yet (NS records missing at the registry). This is the single most common "my site is down" cause right after a domain purchase or registrar change.
- SERVFAIL — an authoritative server answered with an error. Usually a misconfigured zone file (syntax error, missing glue) on the nameserver side. Retrying later or via a different provider tells you if it's transient.
- No A record — the name exists but nothing points it at an IP, so browsers can't connect. Common after a hosting migration where the old A record was deleted before the new one was added.
- CNAME conflict — a CNAME sitting next to other records at the same name. RFC 1034 says a CNAME must stand alone; resolvers behave differently, so half your users may see the site and half may not.
- MX pointing at an IP — RFC 5321 requires MX targets to be hostnames. Many receiving mail servers reject the whole MX set when one target is an IP, which silently kills mail delivery.
- Stale cache / TTL — after a change, resolvers keep serving the old answer until the record's TTL expires. If this tool (which queries fresh, uncached) shows the new value but your laptop shows the old one, your local resolver is caching — wait out the TTL or flush it.
- Propagation — not a real DNS phase, but a useful way to say: different resolvers around the world learn about a change at different times, up to the TTL (and up to the delegation TTL at the zone apex). "Waiting for propagation" = waiting for caches to expire.
- Single nameserver — one NS record means one point of failure. If that server goes down or its network blips, the entire zone is unreachable. Use at least two, ideally from different providers.
Verifying after you change DNS
After editing records in your host or registrar: (1) look the name up here and confirm the new value is present; (2) note the TTL of the old record — that's how long caches may keep serving it; (3) repeat the lookup via the other provider (Google vs Cloudflare) to rule out a single resolver's cache; (4) for mail changes, re-run the lookup and check the Mail security panel — SPF, DKIM and DMARC all live in TXT records and are the first things to verify after switching providers.
Suggested
