Enter a domain name to look up its records including A, AAAA, MX, TXT, NS, and CNAME records.
A DNS lookup becomes much more useful when you read it as a troubleshooting workflow rather than just a record dump. Start by confirming the record type that matches the problem. If a website is unreachable, compare and responses to make sure the domain resolves to the expected IPv4 or IPv6 address. If mail is failing, focus on records, then review values for SPF, DKIM, or verification entries that can affect delivery and reputation.
Another common mistake is treating one resolver response as the full truth. Cached answers, regional routing, CDN behavior, and stale local resolvers can make results appear inconsistent. That is where TTL helps: a short cache lifetime usually means answers can change quickly, while a longer TTL suggests a resolver may continue serving older data until the cache expires. When you are mid-migration or waiting for propagation, record type, TTL, and nameserver alignment matter more than a single lookup snapshot.
Misconfigurations often show up as subtle mismatches: an MX record pointing to a hostname with no A record, a CNAME chain where the target does not resolve, or authoritative name servers that do not match the registrar delegation. In those cases, combine this tool with reverse DNS, WHOIS or RDAP, and hostname resolution checks so you can distinguish a genuine configuration error from a temporary cache delay or provider-side routing choice.
Reading raw DNS output gets easier with a few concrete examples. A typical A-record response for a well-run domain returns one or more IPv4 addresses plus a TTL like 300 or 3600 seconds. google.com usually returns IPs in the 142.250.0.0/16 range; if you suddenly see an answer in a completely unrelated block, something is wrong with the resolver, your DNS cache, or - in rare cases - the upstream chain. AAAA records for the same hostname return IPv6 addresses (commonly starting with 2607:f8b0:: or 2a00:1450:: for Google's fronts) and should appear next to the A records on any modern dual-stack domain.
MX records are the most diagnostic for email troubleshooting. A clean Google Workspace setup returns five MX hosts with priorities 1 to 10 pointing to smtp.google.com and aspmx.l.google.com family hosts. Microsoft 365 typically returns a single MX of the form tenant-com.mail.protection.outlook.com. If you see MX hosts from a completely different provider, or if the answer is empty when you expected mail to work, that is the first place to look before checking SPF or DKIM.
TXT records carry the highest density of useful diagnostic data per response. SPF policies are visible as v=spf1 ... strings, DKIM keys live under selector._domainkey.example.com, and DMARC policies sit at _dmarc.example.com. A common misconfiguration is having two separate v=spf1 records on the same domain - the spec only allows one, and most mail receivers will treat the duplicate as a hard fail. If your DNS lookup returns two SPF strings, that alone explains many deliverability failures even when MX looks correct.
NS records expose whose servers are actually authoritative. A domain registered at GoDaddy but with NS pointing to Cloudflare means edits at GoDaddy will be ignored - records must be changed in the Cloudflare dashboard. This delegation mismatch causes a large share of "DNS change not propagating" support tickets. A quick NS lookup answers the question immediately: whoever is in the NS answer is the system that controls publicly visible records.
The single most common mistake is conflating "I can't resolve this domain" with "DNS is broken." Often the issue is local: a stale resolver cache, an OS DNS setting overriding the network resolver, a browser doing its own DNS-over-HTTPS, or a VPN forcing a specific resolver. Always confirm whether the problem appears from at least two networks before concluding the authoritative DNS is at fault. A successful lookup from this tool while your laptop fails locally points squarely at your machine, not at the domain.
TTL traps catch teams during migrations. If you lower the TTL to 60 seconds after already announcing a long TTL, resolvers around the world still hold the old answer for the original TTL period. Best practice is to drop TTLs to 60 seconds at least 24 hours before the cutover, then change records, then raise TTLs back. Skipping the pre-window step is the reason cutovers that look instant in your own network take a full day to settle for the rest of the internet.
Wildcard records (*.example.com) hide problems in unexpected places. A wildcard A record means any unconfigured subdomain still resolves - so when you test typo.example.com, you get an answer that looks legitimate but routes to a fallback page. During diagnostics, always test the exact hostname your users are typing, not a nearby variation, because wildcards can mask the actual misconfigured subdomain.
CNAME chains can break silently. A CNAME pointing to another CNAME that eventually targets an A record works fine until any link in the chain expires or changes ownership. The chain is also slower than a direct A record because each level requires its own resolution. For user-facing hostnames on high-traffic services, CNAME flattening (where supported by your DNS provider) or direct A records perform measurably better than long chains.
DNS results are most valuable when you connect them to a specific user problem. For a website outage, the first question is whether the domain has an address record at all. Check the root domain and the exact hostname the user opens, because example.com and www.example.com can be configured differently. If one uses a and the other uses direct A/AAAA records, a mistake in either branch can break only part of the site.
For email problems, DNS lookup results should be read in layers. MX records tell other mail servers where to deliver messages. TXT records often carry SPF, DKIM, DMARC, and provider verification values. A domain can have correct MX records and still fail delivery if TXT records are missing, duplicated, or pointing at an old mail provider. After checking DNS, use the IP blacklist tool on the sending server address when delivery errors mention spam reputation.
For ownership and launch issues, nameserver records are the usual starting point. If the registrar delegates to one DNS provider but the records were edited at another provider, your changes will never appear publicly. That mismatch is common after site migrations, domain transfers, and hosting changes. Compare NS records, registrar context, and the host provider before assuming propagation is simply slow.
For CDN and SaaS setups, DNS often acts as a pointer rather than the final destination. A CNAME may point to a service-owned hostname, and that service may return different addresses by region, load, or customer configuration. That is normal. The useful question is whether the chain resolves cleanly, whether the target hostname belongs to the expected provider, and whether the returned IPs match the platform you intended to use.
