DNS Lookup — Check Any Domain's DNS Records
A, AAAA, MX, TXT, NS and more — the public answer, not your ISP's cached one.
🔗 Queries run from our server's resolver, so you see the public answer — not something cached by your ISP or altered by your local network. Results are cached for 5 minutes. Limited to 30 lookups per minute.
Look up any domain's DNS records: where the site points (A/AAAA), where its email goes (MX), which servers answer for it (NS), and the TXT records that carry SPF, DKIM and domain-verification entries.
The query runs from our server's resolver, which matters more than it sounds: when you're debugging a DNS change, your own machine and ISP are exactly the caches you need to bypass.
How to use DNS Lookup
- Enter a domain — pasting a full URL is fine, we'll trim it.
- Pick a record type, or leave it on All to see everything at once.
- Click Look up. Records arrive grouped by type, each with its TTL.
- Copy the results if you need them in a ticket or a chat.
What each record type does
- A / AAAA — the IPv4 / IPv6 address the name points at. This is "where the website is".
- CNAME — an alias to another name. Common on www and on anything hosted by a platform.
- MX — mail exchangers, with priorities. If these are wrong, email disappears; if they surprise you, check who actually handles the domain's mail.
- TXT — free-text records that have become load-bearing: SPF (who may send mail for the domain), DKIM keys, and the verification strings every SaaS asks you to add.
- NS — the authoritative nameservers. These tell you where the zone is really managed, which is the first question in any DNS mystery.
- SOA — zone metadata, including the serial number that should change on every edit.
- CAA — which certificate authorities may issue certificates for the domain.
Why your change "isn't working"
DNS answers are cached for the record's TTL (shown next to each record, in seconds). After an edit, resolvers keep serving the old answer until their copy expires — so a record with a 3600 TTL can lag an hour, and your own machine's cache can lag longer. Checking here shows what fresh resolvers see; if the new value appears here but not in your browser, the stale cache is local to you.
The practical trick: lower the TTL to 300 a day before a planned change, make the change, then raise it back.
Reading SPF out of TXT
The TXT record starting v=spf1 lists every service allowed to send email as the domain. Too many include: entries is a real problem — SPF allows at most 10 DNS lookups, and exceeding it silently weakens enforcement. If mail is being rejected, count the includes before anything else.
Related checks
DNS says where the domain points; the header checker shows what the server there answers, the SSL checker inspects its certificate, and the WHOIS lookup shows who registered the domain.
Frequently asked questions
Why do I see different records than this tool?
Caching. Your machine, your router and your ISP each keep DNS answers until their TTL runs out, so after a change they can serve the old value for minutes to hours. This tool queries from our server's resolver, so it usually reflects fresh answers sooner than your local stack does.
How long until my DNS change is visible everywhere?
Up to the record's old TTL, in the worst case — a record cached with 3600 remaining can be stale for an hour after your edit. "Propagation" is really just caches expiring at different moments. Lowering the TTL before a planned change is the trick that makes cutovers fast.
What is a TTL?
Time-to-live: how many seconds a resolver may cache the answer, shown next to each record. Low TTLs (300) make changes fast at the cost of more queries; high TTLs (86400) are efficient but slow to update. 3600 is a common middle ground.
Why does my domain's TXT list have so many entries?
Every service you've verified the domain with tends to leave one behind — Google, Microsoft, SaaS tools — plus SPF and DKIM which are load-bearing for email. The verification strings are harmless to keep, but the SPF record specifically should stay under 10 DNS lookups or enforcement weakens.
Can I look up a subdomain?
Yes — enter it exactly (like app.example.com). Records live at specific names: www often has its own CNAME, mail subdomains their own MX. Looking up the bare domain won't show records that exist only on subdomains.
Why do some domains return no NS records here?
dns_get_record asks the resolver, and a handful of authoritative setups answer NS queries inconsistently for subdomains or during delegation changes. Ask at the parent domain (the registrable name, not a subdomain) — that's where the delegation lives.