DNS Lookup Tool

DNS is the internet’s phone book, and when a site ‘is down’ or email ‘stopped working’, the truth is usually sitting in its records: a wrong A record after a migration, a missing MX after a DNS move, a TXT record a verification service is still waiting for. This lookup queries live DNS through Google’s public DNS-over-HTTPS service and presents the answers cleanly — record type, value and TTL — for A, AAAA, MX, CNAME, NS, TXT and SOA records of any domain you enter. It is the fastest way to confirm what the world actually sees for your domain right now, as opposed to what your control panel claims you set.

Quick Answer: Enter any domain and record type to see its live DNS values and TTLs, fetched from Google Public DNS in real time.

Free Online Tool

Ask the internet’s phone book what it really says about a domain.

Domain

Record type

How to Use the DNS Lookup Tool

Type the domain to inspect, such as example.com (no https:// needed).
Choose a record type — A for the site’s address, MX for email routing, TXT for verifications and policies.
Press Look Up DNS and read the answer table: name, value and TTL in seconds.
An empty answer with a successful status means that record type does not exist for the domain — itself a useful fact.
Re-check after DNS changes to watch propagation settle (respect the TTL you see).

Key Features

Live queries via Google Public DNS (DNS-over-HTTPS) — not a stale cache.
All everyday record types: A, AAAA, MX, CNAME, NS, TXT, SOA.
Values shown with TTLs so you can judge propagation timing.
Clear status reporting, including NXDOMAIN for names that do not exist.
Free and instant, right in your browser.

Best Practices and Tips

After changing a record, the old value survives in caches until its TTL expires — the TTL column tells you the worst-case wait.
For email problems, check MX first, then the SPF record (a TXT starting with v=spf1) — most delivery mysteries live in those two.
CNAMEs cannot legally sit on a bare root domain in classic DNS; providers offering ‘ALIAS’ or flattening are working around that rule.
A verification TXT that ‘isn’t working’ is often present but on the wrong name — check both the root and the specific subdomain the service requested.
Screenshot or copy the table when raising a support ticket; exact record values beat descriptions of them.

Common Mistakes to Avoid

Judging propagation after two minutes when the old TTL was 86400 (a full day).
Editing records on the wrong nameserver set — if the NS records point elsewhere, your changes at the old provider do nothing.
Confusing a domain’s registrar with its DNS host; they are often different companies.
Deleting ‘unused-looking’ TXT records that turn out to be domain verification or SPF for a service the business quietly depends on.

Frequently Asked Questions

What do the main record types do?

A maps a name to an IPv4 address and AAAA to IPv6. MX lists the mail servers for the domain (with priorities). CNAME aliases one name to another. NS names the authoritative nameservers. TXT carries text data used for verification, SPF, DKIM and DMARC. SOA holds zone administration metadata.

Why does my change not show up yet?

DNS answers are cached worldwide for the duration of the record’s TTL. Until caches expire, different resolvers return the old value. Lower the TTL a day before a planned migration, make the change, then raise it again — the standard professional sequence.

What does NXDOMAIN mean?

The queried name does not exist at all. Causes range from a simple typo in your query to a domain that has expired or a subdomain that was never created. It is a definitive answer, not a timeout.

Whose DNS does this tool ask?

Google Public DNS (8.8.8.8), reached over its encrypted DNS-over-HTTPS endpoint. It is a large, well-maintained resolver, so its answers represent what a big share of the internet will see — though a user on a different resolver may briefly see older cached data.

Can I check records for a subdomain?

Yes — enter the full subdomain (like mail.example.com or app.example.com) and query it directly. Records such as DKIM and service verifications usually live on specific subdomains, not the root.