DNS Lookup
Type a domain and get its A, MX, TXT, CNAME, NS, or SOA records back in seconds, queried live via Google's DNS-over-HTTPS API.
Enter any domain name to query its DNS records. Uses Google's DNS-over-HTTPS API, and all lookups are proxied server-side.
How to look up DNS records
Enter a domain, pick a record type, and see what Google's public resolver returns.
- 01
Enter the domain or subdomain
Type example.com or mail.example.com, without https:// or a path. Records belong to an exact name, so www.example.com and example.com can return different answers.
- 02
Pick one record type, or ALL
ALL asks for A, AAAA, MX, TXT, CNAME, NS and SOA in parallel and shows whatever exists. A single type is quicker to read when you know what you're after.
- 03
Read each value with its TTL
Every record shows its value and its TTL, the number of seconds resolvers may keep it cached. The TTL tells you how long an old value might linger after a change.
Where the answers come from
Lookups go through Google Public DNS, using its DNS-over-HTTPS service at dns.google. You're seeing what Google's resolver currently has, which is what anyone using 8.8.8.8 will get. Your own computer may use your ISP's resolver, or a cached answer, so the two can differ for a while after a change.
That gap is usually the TTL at work. If a record had a TTL of 3,600 seconds when you changed it, resolvers that cached the old value can keep serving it for up to an hour. Lower the TTL to 300 a day before a planned change, and the switchover takes minutes instead. If Google is still showing an old value after the TTL has passed, its cache can be cleared for a specific name at dns.google/cache.
What each record type tells you
Most DNS problems come down to one or two of these records. The example values show the shape of a typical answer.
| Type | What it holds | Example value | Check it when |
|---|---|---|---|
| A | IPv4 address of the host | 93.184.215.14 | Website not loading after a host move |
| AAAA | IPv6 address of the host | 2606:2800:21f:cb07::1 | Site works on some networks but not others |
| CNAME | Alias pointing to another name | shops.myshopify.com | Connecting a subdomain to a SaaS service |
| MX | Mail servers, with priority | 10 aspmx.l.google.com | Email not arriving |
| TXT | Free text: SPF, DKIM, DMARC, verification codes | v=spf1 include:_spf.google.com ~all | Mail going to spam, domain verification failing |
| NS | Nameservers in charge of the domain | ns1.cloudflare.com | Changes at your DNS host having no effect |
| SOA | Zone's primary server and serial number | ns1.example.net hostmaster… 2026103101 | Checking a zone update has gone out |
Two rules trip people up. A name that has a CNAME can't have other records of its own, which is why the bare example.com usually can't be a CNAME. And SPF must be a single TXT record starting with v=spf1. Two separate SPF records make receiving servers treat SPF as broken.
When to check DNS
Checking a DNS change has gone live
After updating a record at your DNS host, look it up here. If Google shows the new value, most of the internet will soon follow.
Fixing email delivery
Look up MX to see where mail is sent, and TXT to confirm SPF, DMARC and the DKIM selector your provider gave you are published.
Verifying a domain for a service
Search Console, Microsoft 365 and certificate authorities ask for a TXT record. Check it's visible before pressing Verify.
Confirming a registrar or DNS host move
NS records show which nameservers answer for the domain. If they still show the old provider, edits at the new one won't take effect.
Limits worth knowing
- Only the seven listed types are queried. CAA, SRV, PTR and DNSKEY records aren't shown.
- DKIM records live on a selector name, such as google._domainkey.example.com, so look up that full name rather than the bare domain.
- Results are Google's view only. Checking from several resolvers around the world needs a propagation-checking service.
- Internal names that exist only on a company network can't be resolved from the public internet.