How to check a domain's DNS records
Start with the name that's causing trouble. example.com and www.example.com can point to different servers, so a working result for one doesn't clear the other. If you paste a website URL, this tool uses its hostname and ignores the path. DNS doesn't know which page you were trying to open.
Leave All selected for a first look, or choose the record type your provider asked you to check. All runs separate queries for the 11 supported forward record types at that exact name. It doesn't discover every subdomain or download the domain's entire DNS configuration. Reverse DNS is separate: choose PTR and enter an IPv4 or IPv6 address to look for its published hostname.
The Resolver choice decides where the answer comes from. A public resolver, such as Cloudflare or Google, looks up records on your behalf and can reuse a saved answer. Authoritative nameserver asks a server responsible for publishing the records. Use a public resolver to inspect its answer; use the authoritative option when you want to check what a domain's DNS server currently publishes.
Neither choice tests the website or sends an email. It tells you what DNS says, which is where the investigation starts.
DNS record types: which one do you need?
The record type describes the job, not how important the record is. A website address, an incoming mail server, and a domain-verification token can all belong to the same name without replacing each other.
| Record type | What to check |
|---|---|
| A | The IPv4 address used to reach a hostname. Compare it with the address your host expects. |
| AAAA | The IPv6 address. Check it alongside A when a website works on one network but not another. |
| CNAME | An alias pointing to another hostname, often used by hosted services. Compare the full target name. |
| MX | The servers that receive email. Lower preference numbers are preferred, not higher ones. |
| NS | The nameservers responsible for a DNS zone. Useful after changing DNS providers, but not a complete check of the parent domain's delegation. |
| TXT | Text used for verification and email policies. The exact name and complete value matter. |
| CAA | Rules about which certificate authorities may issue certificates. Reading one answer is not a complete certificate-policy check. |
| SOA | Zone information, including a serial number and update timers. A zone is a portion of DNS managed together. |
| SRV | A service's target hostname, port, priority, and weight. Query the service name, such as _sip._tcp.example.com. |
| DS | A record in the parent zone linking to a DNSSEC key for this zone. |
| DNSKEY | Public keys published for DNSSEC. Their presence alone doesn't prove validation works. |
| PTR | A published hostname for an IP address. It isn't a list of every website sharing that address. |
Cloudflare's record reference explains the individual types. If you've changed nameservers, use the Nameserver Delegation Checker to compare the parent delegation with the zone's own records. That checks a relationship an ordinary NS lookup cannot settle.
How to read DNS lookup results
Compare the returned address, hostname, or text with the value your provider gave you. A successful lookup means you received an answer, not that the answer matches your intended setup.
If the result shows an alias, follow it before deciding that an unfamiliar hostname is a mistake. For example, www.example.com might point to edge.example.net, whose A record supplies the address. The result keeps the record's owner name, meaning the name that record belongs to, so you can distinguish the alias from its destination. This is normal CNAME behavior, not a website redirect.
TTL means time to live: the record's cache lifetime in seconds. Resolver TTL is the value the selected public resolver reported, usually the time left in its cached answer. A value of 300 is about five minutes at the moment of the lookup. Authoritative TTL is the value published by the nameserver instead. Neither is a countdown to when everyone on the internet will see a change.
Addresses may also show a network, provider, country, and ASN. An autonomous system number identifies a network that announces routes to those addresses. This information comes from Team Cymru's IP-to-ASN mapping; it doesn't locate the physical server or identify the website owner. Nameserver addresses are looked up separately, so they aren't necessarily addresses supplied with the domain's parent delegation.
Why DNS changes show different answers
You save a new record, run a lookup, and still get the old value. That doesn't automatically mean the change failed. Public resolvers can have different cached copies, collected at different times. A resolver that recently saved the old record may keep it after another has fetched the new one.
Compare the same name and record type using the authoritative option and a public resolver. If the authoritative answer has the new value, an old cached answer is a plausible explanation. If it still has the old value, check that you edited the DNS provider serving this domain. This tool queries one discovered authoritative server, not every server hosting the zone.
Lowering a TTL after making a change doesn't shorten the lifetime already attached to someone else's cached copy. Even missing records can be cached, so adding a previously absent TXT record may not make it immediately visible. DNS defines this as negative caching.
Use the DNS Change Checker to compare sources together. Differences aren't always a waiting problem: DNS providers can return different addresses by location, and resolver policies can differ. The selected service is queried from stack127's server, not your laptop. Your browser, router, VPN, or private network may therefore see another answer. Google's DNS troubleshooting guide covers these distinctions.
Checking email and domain-verification records
A correct website address tells you little about email. For incoming mail, check MX at the domain after the @ in the email address, then compare the mail server names and preference numbers with your email provider's instructions.
Verification and email policies can live under other names. A TXT lookup at example.com won't also check _dmarc.example.com. For DKIM, use the selector supplied by your mail provider, such as selector1._domainkey.example.com, and the record type it specifies. Leave the underscores in place. They are part of the name, not formatting to remove.
If a provider can't find a new token, compare the exact name and full returned value before changing anything else. Finding the text confirms that this DNS source returned it; this tool doesn't validate SPF, DKIM, or DMARC policies, verify a signed email, or test mail delivery.
What NXDOMAIN, SERVFAIL, and empty answers mean
An empty section can be completely ordinary. A hostname doesn't need every record type, and All will often include types with no records. The response code helps separate that situation from a lookup that failed.
| Response | Meaning and next check |
|---|---|
| NOERROR with records | DNS returned records. Compare their values with the setup you intended. |
| NOERROR without the requested records | No records of that type were returned. Check the exact name and any alias path before assuming something is missing. |
| NXDOMAIN | The answer says the queried name, or a target reached through an alias, doesn't exist. Check spelling, subdomains, and alias targets. |
| SERVFAIL | The resolver couldn't complete the lookup. Unreachable nameservers or DNSSEC problems are possible causes; this code doesn't identify which one. |
| REFUSED | The server declined the query. Try another source; refusal alone doesn't establish a broken domain. |
These distinctions come from the DNS response-code definitions and negative-answer rules. A timeout is different again: stack127 didn't receive a usable answer in time. It isn't evidence that the name doesn't exist. Use DNS Trace Explorer when you need to see where resolution stops.
Does "Not authenticated" mean DNSSEC is broken?
No. DNSSEC adds signatures that a validating resolver can check. Authenticated means the selected public resolver reports that it validated the returned data. Not authenticated can simply mean the domain isn't signed. The DNSSEC authentication flag is not a general website safety verdict.
Looking up DS and DNSKEY records also doesn't validate the complete chain of trust. If you're investigating a DNSSEC failure, use the DNSSEC Chain Checker. A direct authoritative answer isn't treated as a validation verdict here, because publishing signed records and validating them for a client are different jobs.
Where your DNS query goes
stack127 sends the name to your selected public resolver. For an authoritative lookup, it uses Cloudflare to find the nameserver, then sends the question directly to that server. Nameserver-address lookups also use Cloudflare, and returned public IP addresses go through Team Cymru's DNS service for network information.
The browser may request the queried website's favicon directly after a result appears. stack127 doesn't save a lookup history or put queried names and record values in analytics. A URL containing a lookup name can still expose that name to anyone you share it with. Use public names here, not private internal hostnames you don't want sent outside your network.