You have just moved your website. It works for you, but a customer still sees the old version. Or the website loads correctly while the company’s email has stopped arriving. Sometimes these situations share a cause: the DNS information that directs visitors and messages to the right services.
A few browser-based tools can show what your domain publishes on the Internet. Used well, they help answer a practical question before you change any settings: is the problem the published destination, an old cached answer or the service itself?
Here is how to choose a tool, read the useful results and plan the next step with your hosting or email provider.
Which tool should you start with?
| Your situation | Tool to open | What to look for |
|---|---|---|
| The website is unreachable or seems to reach the wrong host. | dns.google | The address or alias published for the website’s name. |
| Email is no longer arriving, or message authentication is a problem. | MXToolbox | Receiving servers and email authentication records. |
| You changed DNS and users are getting different results. | DNSChecker | Answers observed through several DNS servers. |
Start with the tool that matches the symptom. You do not need to run every available test or know every record type to make a useful initial check.
Before you search: the right name and a reference
Enter a name in a DNS tool, such as www.example.com, without https:// or a page path. The bare domain example.com and www.example.com are separate names. Testing one does not automatically validate the other.
Also have the intended value ready: the address or hostname supplied by your web host, or the destinations specified by your email provider. Without that reference, you can establish that an answer exists, but not that it is correct for your service.
DNS may be managed somewhere other than the registrar that bills you for the domain. The active zone is hosted by the provider designated through the domain’s nameservers. A change in an old DNS control panel may therefore have no effect on visitors. Our guide to domains, aliases and subdomains explains these responsibilities.
Your website: check its destination with dns.google
dns.google lets you inspect answers from Google’s public DNS service. It provides a useful comparison when your browser displays an error or reaches an unexpected destination. Google’s documentation describes this troubleshooting use.
- Enter the website’s exact name and run the lookup.
- In the detailed result, check type A for the IPv4 address and AAAA for IPv6, if your service uses it.
- Compare the values with your host’s instructions. If a CNAME appears, it represents an alias to another name: compare that destination too.
- Repeat with and without
wwwif both addresses should work.
Illustrative example: your host expects 192.0.2.20, but the lookup still returns 192.0.2.10. You now have a specific difference to investigate. It may come from an old cache or a record left unchanged in the active zone. These addresses are reserved for documentation and must not be copied into your configuration.
An overlooked IPv6 address can also explain why some visitors reach a different server. Conversely, a missing AAAA record is not a fault if your hosting does not use IPv6.
If your site uses a CDN or proxy service, the public address may belong to that service rather than the origin host. Always compare against the intended configuration, not an address found in an old email.
When the answers match that configuration, continue with the web service: its certificate, redirects, content or website cache. A DNS lookup does not check those elements. Before a move, our guide to changing website DNS while preserving email helps prevent a website change from disrupting email too.
Your email: separate receiving and authentication checks with MXToolbox
MXToolbox brings together several email checks. Its official tool directory includes MX, SPF, DKIM and DMARC lookups. The right starting point depends on the problem.
You are no longer receiving messages
Select the MX lookup and enter the domain after the @ in your email address. The results identify the servers designated to receive messages. Compare their names with the instructions from the provider that actually hosts your mailboxes.
This is particularly useful after a nameserver change: the website can work even if the MX records were not copied into the new zone. Your web server and email may be with separate providers. Moving the website does not require moving the mailboxes.
If the destinations are correct, keep the rejection message and check the affected mailbox: does it exist, is it full, and are all senders affected? Our guide to email receiving and sending problems continues these checks.
Your messages are rejected or go to spam
Authentication lookups are useful here:
- SPF: which services are authorized to send for the domain evaluated by SPF?
- DKIM: is the sending service’s public key published? The check requires its selector, available from the provider or a message’s signature.
- DMARC: which policy is published for the visible sender’s domain?
DNS publishes the necessary information, but the actual sent message must pass authentication. DMARC requires successful SPF or DKIM authentication aligned with the visible domain. These principles are described in the DMARC specification.
Consider every sending source: a work mailbox, website form and billing application may use different services. A correctly configured mailbox does not automatically validate messages from the form.
To investigate further, retrieve the complete headers of a received message and see our article on email authentication for Gmail and Yahoo. Even successful authentication does not guarantee inbox placement: reputation, consent and sending practices also matter.
After a change: compare answers with DNSChecker
DNSChecker looks up a name and record type through a selection of DNS servers across several regions. WhatsMyDNS provides a similar comparison. These tools help when only some people appear to see the change.
Choose the same name and record type as your first check. For a website address change, examine the A record, for example; for an email change, examine MX records. Compare the returned values with the intended ones, rather than relying only on coloured check marks.
What people call “DNS propagation” depends partly on caches. Servers can retain an answer for a period governed by its TTL, expressed in seconds. A TTL of 3600 means one hour; the number a tool displays may be the time remaining in a cache. Users therefore do not all switch to a new answer simultaneously.
Lowering the TTL when you make a change does not erase old answers already cached elsewhere. An answer reporting that a name does not exist can also remain cached, as described in the negative response standard.
Should you simply wait 24 or 48 hours? Check the active zone first. If it publishes the wrong value, waiting will not fix it. If it is correct and some caches retain the old answer, the TTLs and time of the change become useful information for tracking progress.
A map is a sample, not a certificate of worldwide availability. Different answers may also be intentional when using a CDN. If only your computer seems to retain an old value, our guide to clearing the DNS cache can help once you have recorded the initial results.
Understand an empty result or an error
A lookup without an answer does not always mean the same thing. Here are the main cases to recognize:
| Result | What it tells you | Next check |
|---|---|---|
NOERROR with an answer | The query was processed and data was returned. | Compare the value with the provider’s instructions. |
NOERROR without the requested type | The name may exist without that record. | Check whether the type is needed, such as AAAA. |
NXDOMAIN | The requested name is reported as nonexistent in this response. | Check the spelling, then the name’s configuration. |
SERVFAIL or timeout | Resolution did not complete. | Keep the error and compare through another tool or network. |
DNS response codes describe the query’s result, not the full state of the website or email service.
A public tool can also obtain a different answer from your computer, particularly with a VPN, corporate network or browser-specific DNS. That difference is a useful clue for the technical team. On its own, it does not justify replacing every computer’s DNS settings.
Prefer the terminal? A few commands are enough
The web tools already cover the checks above. A terminal is particularly useful for repeating a lookup and sharing its exact output. Replace example.com with your public domain; these examples read data without changing your settings.
Windows: nslookup or PowerShell
In Command Prompt or PowerShell, nslookup can look up the website’s address and receiving servers:
nslookup -type=A example.com
nslookup -type=MX example.comThe first query concerns the website, the second email reception. A “non-authoritative answer” is normal when it comes from an intermediate resolver; that label does not mean the answer is wrong.
On Windows, the DnsClient module also provides Resolve-DnsName. To compare an A answer with Google’s public DNS:
Resolve-DnsName -Name example.com -Type A -Server 8.8.8.8 -DnsOnly -NoHostsFileThis command selects the server for this lookup only. -DnsOnly restricts the lookup to DNS and -NoHostsFile excludes the hosts file.
Linux and macOS: dig, or host for a concise answer
In Terminal on macOS, or with DNS utilities installed on your Linux distribution, dig provides a detailed answer. host offers shorter output when available. The options are described in the BIND manuals.
dig example.com A
dig @8.8.8.8 example.com A
host -t MX example.comThe first two commands compare the same record using the server selected by the tool, then Google. The third looks up receiving mail servers. Keep the full output, queried server and test time: they give support more useful information than a screenshot showing only that something failed.
Looking for who manages the domain instead?
To find a domain’s registrar or statuses, use ICANN Lookup for generic domains such as .com, or CIRA’s WHOIS for .ca. This can help you identify the right contact before a renewal or transfer.
ICANN now uses RDAP as the reference for generic-domain registration data following its transition from WHOIS. These searches complement DNS troubleshooting but do not provide your website’s or mailboxes’ complete settings. The registrar is not necessarily their hosting provider, and some contact details are redacted to protect privacy.
When to ask Nuagerie for help
If results remain contradictory, the whole domain stops resolving after a nameserver change, or you cannot identify the active zone, have the configuration examined before making several more changes.
Specialist tools such as DNSViz and Zonemaster can then help a technical team examine delegation and DNSSEC, the mechanism for validating DNS responses. They support investigation of a specific fault; you do not need to master their reports before asking for help.
For an existing service, find our contact details on the Support page. Simply prepare:
- the affected domain or subdomain;
- what is failing and when it started;
- any recent change;
- the tool used, result and test time;
- who is affected: everyone, certain recipients or a single network.
Do not send passwords or private keys. Redact personal information in email headers and use public tools only for names you can share with them.
Planning a new website or a migration instead? Tell us about your current configuration. Identifying where your domain, DNS, website and email are hosted helps establish the right checks before the change.
