Your web designer says the new site is live. You open it on your phone and see the new homepage. A customer opens it on a laptop and sees last week’s version. Before anyone edits another setting, run a DNS Records Lookup for the exact hostname the customer visited. The answer can help you distinguish an old address in a resolver’s cache from a missing website record or a problem at the hosting company.
Start with one question you can answer by comparing two values. For example, “Does www point to the hostname my new web host supplied?” gives you more to work with than “Is my DNS correct?” Write down the expected value first. Then run the lookup and record what you see. Here’s how that approach works for websites, business email, and domain verification.
What Does a DNS Records Lookup Tell You?
The Domain Name System publishes information about names on the internet. When someone opens your website, their device needs an address it can connect to. When someone emails your business, their mail provider needs to know which servers accept messages for your domain. Those are separate questions. Your homepage can load perfectly while the information needed to deliver email is missing. developers.cloudflare.com
A lookup asks a DNS server about a particular name and record type. That last detail matters. A search for the A record at example.com can succeed even if www.example.com has no address. Likewise, checking the TXT records at the root domain can miss a verification token published under a subdomain. Copy the name from the service you are troubleshooting before you run the check.
Choose the Right DNS Record for the Job
A and AAAA Records for Website Addresses
An A record gives an IPv4 address, such as 192.0.2.25. An AAAA record gives an IPv6 address. If your host gave you settings for both, check both after a move. An old IPv6 entry can send some visitors to the previous server even after you update the IPv4 entry. Compare each result with your host’s instructions before deleting an unfamiliar value. developers.cloudflare.com
CNAME Records for Aliases
A CNAME points one hostname to another. An online store might ask you to point shop.example.com to a hostname it manages. Compare the returned target with the one in your store dashboard. Then look up the target’s address. This second check helps when your alias is spelled correctly but the service at the far end still appears unavailable. developers.cloudflare.com
MX and TXT Records for Mail and Verification
An MX record names a server that receives mail for a domain. Each entry also has a priority, with lower numbers preferred. A TXT record holds text that a service can use for purposes such as domain verification or email authentication. If a provider asks for a TXT token, compare the entire token. Two verification codes for different accounts can look remarkably similar at a glance. developers.cloudflare.com
How to Check DNS Records in Four Steps
1. Copy the Hostname From the Affected Service
Suppose the address that fails is https://shop.example.com/checkout. Enter shop.example.com in the DNS record checker. The protocol and everything after the hostname belong to the web request. If the store’s homepage works at that same hostname but checkout returns an error, you’ve already learned something. Both pages use the same DNS name, so the checkout application and its error logs are better places to investigate the difference.
2. Select a Record Type and Resolver
Choose A or AAAA to check an address, MX for incoming mail, or the exact type a verification service requested. The linked tool lets you select a DNS server and query individual record types. Start with one targeted query. An overview helps when documenting a domain, but scrolling through unrelated records makes it easy to overlook a one-character error in the value you need. whatsmydns.me
3. Read the Result From Left to Right
Here is an illustrative answer using an address reserved for documentation:
www.example.com. 300 IN A 192.0.2.25Read the line as a sentence. The name www.example.com. has an IPv4 address of 192.0.2.25, and the displayed time to live is 300 seconds. IN identifies the internet class, and A identifies the record type. The final dot marks the end of the full DNS name. Your hosting dashboard may omit that dot from its display and still describe the same destination.
4. Compare the Public Result With the Authoritative Answer
An authoritative nameserver publishes the domain’s records. A recursive resolver looks up those records on behalf of users and may cache the answers. Compare the two after a change. If the authoritative server shows the new value and the public resolver shows the old one, save both results and their timestamps. Now you have a way to track whether the difference disappears. whatsmydns.me
Worked Example: The Root Domain Opens, but WWW Fails
Imagine a bakery has moved its website to a new platform. The owner enters example.com and sees the new menu. Printed flyers, however, send customers to www.example.com, where they see the old site. The owner has already cleared the browser cache twice. The most informative next step is to check the two names side by side against the platform’s setup instructions.
| Hostname | Expected setup | Illustrative result |
|---|---|---|
example.com | A record points to the new hosting address | Matches the new address |
www.example.com | CNAME points to the new platform hostname | Still points to the former host |
The two screenshots now make sense. Each person used a different name, and each name led to a different destination. The owner can update the www entry at the active DNS provider, confirm the authoritative answer, and test the address printed on the flyer. That isolates the repair to the hostname customers are having trouble with.
Now change one detail. Suppose both names return the expected destinations, but the www address shows a certificate warning. Open the hosting dashboard and check whether www is attached to the site and covered by its certificate. The DNS lookup tells you where the connection goes. The browser’s warning tells you what happened after it reached that destination.
Worked Example: Incoming Email Stops After a Website Move
A website migration can affect email when it includes a nameserver change. Consider a company that moves DNS management to its new web host. Its homepage opens immediately because the new zone includes the correct website address. By the afternoon, customers report that messages to sales@example.com are bouncing. Staff can still sign in to their inboxes and read older messages.
Start an MX record lookup for example.com, the part after the @ sign. Compare every returned server and priority with the instructions from the company’s email provider. If the old DNS dashboard shows the correct entries but the active authoritative server omits them, you’ve found a gap in the migration. Publish the required entries with the provider currently responsible for the domain.
After the expected MX answers appear, send a fresh test from an outside account to a known working mailbox. Keep the full bounce if it fails. An “unknown recipient” response for one address directs attention to that mailbox or alias. If several addresses fail and the advertised mail servers still differ from the provider’s instructions, continue checking the domain configuration. This sequence keeps a mistyped recipient from being mistaken for a company-wide outage.
Worked Example: A TXT Verification Token Looks Correct but Fails
When a service asks you to prove domain ownership, copy the record type, full hostname, and token into your notes. Suppose it requests a TXT record at _verify.example.com. Query that exact name. Existing TXT entries at example.com can be valid for other purposes while telling you little about whether the verification service can find its token.
A subtle mistake happens when a DNS dashboard automatically adds the domain to whatever you enter in the name field. Typing the full name can create _verify.example.com.example.com. The token looks correct in the editor because its value really is correct. The error is its location. Check the dashboard’s preview of the complete name, then repeat the public lookup for the name the service requested.
Once the correct name returns the expected token from both the authoritative server and a public resolver, use the service’s verification button again. Save the result and the time if verification still fails. Support can then check whether its verification system queried the same name and expected the same token.
How Long Should You Wait After Changing DNS?
TTL means time to live. Imagine a resolver cached your old website address at 9:00 a.m. with a TTL of one hour. You change the authoritative record at 9:10. That resolver can ordinarily reuse its cached answer until around 10:00. A second resolver that first looks up the address at 9:15 may already have the new value. Both observations fit the same timeline. developers.google.com
This is why “wait for DNS propagation” becomes useful advice after you confirm the authoritative answer. If the authoritative server still shows the previous address, check the active nameservers and where the edit was saved. For a planned move, lower the TTL far enough ahead for the old TTL to expire before you switch hosts. Lowering it at the moment of the move cannot shorten the lives of copies already held elsewhere.
What Common DNS Lookup Errors Mean
| Lookup result | What it tells you | What to do next |
|---|---|---|
NXDOMAIN | The server reports that the queried name does not exist. | Check the spelling and full hostname, especially for subdomains. |
NOERROR with an empty answer | The query succeeded, but the requested record type may be absent. | Confirm the type. A name can have an A record without an AAAA record. |
SERVFAIL | The resolver could not complete the lookup. | Compare resolvers and check nameserver availability, delegation, and DNSSEC diagnostics. |
| Timeout | The query received no reply within the time allowed. | Retry from another resolver or network and record which server failed to reply. |
If you hand the problem to support, include the hostname, record type, expected value, actual value, resolver, and time with its time zone. “At 10:15 a.m. Eastern, this resolver returned the previous IPv4 address for www” gives someone a test they can repeat. A screenshot of a browser error alone leaves them guessing which part of the connection failed. developers.google.com
Frequently Asked Questions
Can I Check the DNS Records of a Website I Don’t Own?
Yes. You can query public DNS records for a known domain or subdomain. An ALL lookup checks multiple record types at the name you enter. To investigate a particular subdomain, enter its full hostname. whatsmydns.me
Why Does a DNS Lookup Show a Different IP From My Hosting Dashboard?
If your website uses a proxy or content delivery network, visitors may receive an edge server’s address. Check the provider’s expected public configuration before replacing that address with your origin server’s IP. developers.cloudflare.com
Will Clearing My Browser Cache Make DNS Update Faster?
Clearing cached web content can help you see a changed page. An external DNS resolver manages its own cache. Compare its answer with the authoritative one to find out whether it still holds an older address. developers.google.com
Which DNS Record Should I Check When Only Email Is Affected?
For incoming mail, begin with MX. If outgoing messages reach recipients but fail authentication, read the failure report and check the SPF, DKIM, or DMARC record it identifies. developers.cloudflare.com
Conclusion
A useful DNS records lookup begins with the exact name that failed and the value you expected to find. Check the relevant record, compare authoritative and cached answers, and test the affected service again. Those observations help you decide whether to correct a DNS entry, allow a cached answer to expire, or take a specific error to your web or email provider.
