Updated 5 days ago
To check a DNS change, look up the domain in WhatsMyDNS, choose the type of record you changed, and compare the responses with the expected value. If some networks still show the previous value, a cached response may still be waiting to expire; if the configured destination is incorrect, waiting won’t fix it.
The check depends on whether you changed the domain’s DNS servers, the website address, the email provider, or a verification record.
A change may appear within minutes or take several hours. In some cases, it can take 48 to 72 hours or longer; there’s no single fixed timeframe, and you don’t need to wait that long before checking.
What we call propagation is the process of updating DNS responses that different devices and providers store in their caches. That’s why your connection may still use an old value while another network already gets the new one.
If you changed a record: its previous TTL matters. The TTL indicates how long a response can be stored in a cache. For example, a TTL of 3600 equals one hour from the time that response was obtained.
If you changed the DNS servers or nameservers: the domain’s delegation and its caches also need to be updated. The TTL of an A record doesn’t control this entire process.
Reducing the TTL after the change doesn’t remove old responses that other servers have already cached. For a future change, it’s best to lower the TTL sufficiently in advance so the previous TTL can expire.
You need to know the exact name you changed and the value it should return. Use the configuration details for your service; don’t use another website’s IP as a reference.
What you changed | Query type | What to compare |
|---|---|---|
The domain’s DNS servers | NS | The server names, compared with the delegation you configured. |
The IP address your website points to | A for IPv4; AAAA for IPv6, if you use it | The address for the service. |
An alias, such as | CNAME, if that name uses an alias | The alias’s destination name. |
The provider that receives your email | MX | The mail servers and their priorities specified by the provider. |
An email verification or authentication record | TXT, or the type requested by the provider | The expected content at the exact name you were given. |
tudominio.com and www.tudominio.com are different names: check both if you use both addresses. For a verification record, look up the full name requested, which may include a prefix such as _dmarc.
If you delegated the domain to our hosting or reseller service, compare the NS records with the Duplika DNS list. If you keep your DNS with Cloudflare or another provider, the NS records should match that service even if your website is hosted with us.
If you need to confirm which servers the registrar has delegated to, open the HostingFAQ DNS report. You can also compare A, AAAA, and MX records between Google Public DNS and Cloudflare 1.1.1.1, or save a copy to compare before and after a migration. To see responses from different locations, continue with WhatsMyDNS.
The tool queries DNS servers in different locations. Its results are useful for comparing responses, but they don’t represent every network or guarantee what your connection returns.
Open WhatsMyDNS.
Enter the domain or subdomain you want to check, without https:// or a path such as /contacto.
Choose the record type from the selector: NS, A, AAAA, CNAME, MX, or TXT, depending on the change.
Click Search.
Compare the values returned by each location with the expected configuration. You can select a location to see the details.
If you changed the nameservers, start with NS, then check the website and email records you need to use. Seeing the new NS records doesn’t by itself confirm that the A or MX records in the new zone are configured correctly.
Compare the values, not just the colors or markers on the map. A query can return a valid response that still points to the previous service.
This is consistent with old responses still being stored in caches. Confirm that the change was saved with the provider that manages the active DNS, and run the check again later, taking the previous TTL into account.
If the results keep alternating after the expected timeframe, contact us so we can check whether the DNS servers are responding consistently. Not every difference in responses is caused by propagation.
In addition to a cache that hasn’t expired yet, you may have edited a DNS zone that your domain isn’t using.
Check who manages the active nameservers. If your DNS is with Cloudflare or another external provider, record changes must be made there; editing only the cPanel zone won’t change the public configuration.
If you changed the delegation, make sure the change was confirmed with the registrar. You can review the instructions for your situation:
An empty response or a failed query doesn’t by itself mean the entire domain is down. First, confirm that you entered the correct name and chose the right type.
For example, not getting an AAAA record is normal if you haven’t configured IPv6. If you expect a verification TXT record on a subdomain, looking up the main domain’s TXT record won’t check that record.
If the record should exist but still doesn’t appear, make sure it was created in the active DNS. If other queries for the domain are also failing, contact us with the results.
With the Cloudflare proxy enabled, public A or AAAA queries return Cloudflare IPs. You can check the hosting server’s IP in the record content in the Cloudflare dashboard.
A CNAME with the proxy enabled may also resolve publicly to Cloudflare IPs. In that case, check A or AAAA as well as the alias configuration in the dashboard.
You don’t need to disable the proxy just to try to make the checker show the hosting IP.
In addition to your connection’s DNS cache, a copy of the content may be stored in your browser, application, or a CDN. These are separate caches.
Try another network, for example, mobile data instead of Wi-Fi. A difference between networks can help guide troubleshooting, though it doesn’t by itself identify which cache is involved.
If you use Cloudflare and need to check content changes, see how to use its development mode. If the website still won’t open or shows an error, follow the service access checks.
Combine the DNS query with a test of the service you changed: a record responding correctly doesn’t by itself confirm that the website or email is working.
For a website: check that the addresses you use, with or without www, open the expected content.
For email: check the MX records and test sending and receiving messages with an external account.
For a verification: repeat the validation from the service that requested the record.
If the result points to an incorrect destination, doesn’t return a record that should exist, or the service still isn’t working, contact support from the account of the account holder or an authorized contact.
Include these details so we can check the change:
The exact domain or subdomain and the type of record you queried.
The expected value and the one WhatsMyDNS returns, ideally with a screenshot.
The date and time of the change, including your time zone.
The provider and dashboard where you made the change.
Whether the problem affects the website, email, or both, and which networks you checked from.
