What a DNS lookup returns — and what it cannot tell you
A DNS checker queries the Domain Name System for a domain’s published records — the addresses, mail routes, name servers and text entries that tell the internet where a domain’s services actually live.
Almost every launch problem that looks like a hosting fault is really a DNS fault. The site resolves for you but not for a client, email vanishes without a bounce, a domain verification never completes, or a migration half-works because one record still points at the old server. All of those are answered by reading the domain’s current records rather than guessing.
This checker queries six record types at once and adds registration details pulled from RDAP. The sections below explain what each record type controls, how to read a result correctly, and — importantly — why a single lookup is not a propagation map.
The six record types this tool queries
Selecting ALL runs every type below in parallel. An empty result means no record of that type exists, which is often the actual finding.
| Type | What it controls | What a problem looks like |
|---|---|---|
| A | The IPv4 address a hostname resolves to | Missing or stale A record after a host migration — the site loads for you from cache but not for anyone else. |
| AAAA | The IPv6 address | An AAAA record pointing at a server that is not listening on IPv6 causes slow or failed loads for IPv6-first networks, including many mobile carriers. |
| MX | Which mail servers accept mail for the domain, with a priority number | No MX record means inbound mail bounces. Two records with the same priority split delivery rather than failing over. |
| TXT | Free-form text: SPF, DKIM, DMARC and ownership verification strings | Two SPF records on one domain is a hard failure — the specification allows exactly one. |
| NS | The authoritative name servers for the zone | NS records that still list your old provider mean you are editing DNS in a control panel nobody is reading. |
| CNAME | An alias pointing one hostname at another | A CNAME cannot coexist with other records on the same name, which is why one on the apex domain breaks MX and TXT. |
How this lookup is performed
Knowing the mechanism tells you exactly how much to trust the answer.
- Resolver
- Queries run from our server using the operating system resolver. You are seeing one vantage point at one moment in time.
- Types queried
- A, AAAA, MX, TXT, NS and CNAME. Failed lookups are returned as empty lists rather than errors, so one missing type does not hide the others.
- Registration data
- Registrar, registration date, expiry date and approximate domain age come from RDAP — the successor to WHOIS — not from DNS. RDAP here covers .com, .net and .org; other TLDs use registry servers this tool does not query.
- Input handling
- A pasted URL is accepted: the protocol and trailing slash are stripped and the domain is lowercased before the query.
- TTL and caching
- Records carry a time-to-live set by the zone owner. Resolvers cache for that long, which is why a change you made two minutes ago is invisible to a network that cached the old answer for an hour.
- What it does not do
- It does not query resolvers in multiple countries, does not test whether the server behind an address responds, and does not validate DNSSEC.
DNS propagation, and what is really happening
Direct answer: DNS does not propagate. Nothing is pushed anywhere. Each resolver independently caches an answer for its TTL and only asks again when that expires — so the delay you experience is a cache expiry, not a distribution process.
Lower the TTL before you migrate, not after
Drop the record’s TTL to 300 seconds at least 24–48 hours ahead of a change, so resolvers are already refreshing every five minutes when you cut over. Lowering it on the day has no effect on caches that already hold the old value at 86,400 seconds.
Your own machine caches too
Browsers, the OS and your router all cache. If a lookup here shows the new address but your browser does not, flush your local cache before assuming the change failed.
A clean lookup does not prove the service works
DNS answers where a service is, not whether it is running. If the record is correct but the site is down, check the certificate with the SSL certificate checker and the address itself with the IP address lookup.
Email needs three TXT records, not one
SPF authorises sending servers, DKIM publishes the signing key, and DMARC tells receivers what to do when the first two fail. Publishing SPF alone still leaves messages liable to land in spam.
The apex CNAME trap
You cannot put a CNAME on example.com itself alongside MX or TXT records. Providers work around this with ALIAS or ANAME records — if your mail broke the moment you pointed the root at a platform, this is almost certainly why.
NS mismatch between registrar and host
If the NS records returned here are not the name servers your DNS panel belongs to, every edit you make is being written to a zone nobody queries. Fix the delegation at the registrar first.
Diagnosing a broken domain in five checks
- 1
Confirm delegation with NS
Check that the name servers returned match the provider where you are actually editing records. Everything else is meaningless if this is wrong.
- 2
Read A and AAAA together
A stale AAAA record is a classic cause of "works for me, broken for them" — IPv6-capable clients prefer it and never try the IPv4 address.
- 3
Check MX before blaming the mail host
Confirm the hostnames and priorities match your provider’s published setup. A single wrong hostname sends inbound mail nowhere.
- 4
Audit TXT records for duplicates
Look for two SPF entries, an expired verification string, or a DMARC policy set to p=reject before the sending domain was ready for it.
- 5
Note the registration dates
An expiry date inside the next 30 days deserves attention now — an expired domain takes everything with it, and renewal-plus-restore is far more expensive than renewal.
Once records are correct, confirm the site actually loads well with the website speed test — a migration that fixed DNS can still leave you on slower hardware.
This checker vs. dig, vs. a multi-location propagation service
| Option | Best for | Trade-off |
|---|---|---|
| This browser checker | A fast read of every important record type plus registration data in one screen | One resolver, one location. It answers "what is published" rather than "who can see it yet". |
| dig or nslookup | Querying a specific resolver, inspecting TTLs, tracing the delegation chain | Command line only, and the output takes practice to read. |
| A multi-location propagation checker | Watching a change roll out across regions during a cutover | Purpose-built for one narrow question and usually shows a single record type at a time. |
| Your registrar’s DNS panel | The authoritative truth about what you configured | Shows intent, not reality — it cannot tell you the zone is delegated somewhere else. |
How this page is maintained
The record types, the RDAP TLD coverage (.com, .net and .org) and the single-resolver behaviour described here were read from this tool’s server implementation. The propagation explanation reflects how DNS caching actually works, which is why the page avoids the common claim that changes are "pushed" worldwide.
Written and reviewed by the ToolsRacks editorial team. Last reviewed: .