After you update DNS records, it is normal for the new values to take some time to appear everywhere on the internet. During this period, some visitors may still reach the old website, while others already see the new one. This is called DNS propagation, although in practice it is often a mix of caching at resolvers, browsers, operating systems, and local networks.
If you have moved a domain to a new hosting platform, changed nameservers, updated an A record, or pointed mail services to a different server, checking propagation helps you confirm whether the change is live and where any delay may still exist. In a managed hosting or control panel environment such as Plesk, this is especially useful when troubleshooting site access, email delivery, or “wrong website” issues after a domain update.
What DNS propagation means
DNS translates domain names such as example.co.uk into IP addresses and other service records. When you edit DNS, the change is not always visible instantly to every resolver on every network. Many systems store older answers temporarily so they can respond faster.
Common reasons for delayed visibility include:
- TTL values on the old records, which tell resolvers how long to cache an answer.
- Recursive DNS caches used by ISPs, offices, mobile networks, and public resolvers.
- Browser cache and local operating system cache.
- Negative caching, where a missing record is temporarily remembered.
- Nameserver delegation updates, which may take longer than a simple record change.
In most cases, DNS updates begin to show within minutes to a few hours, but full propagation can take up to 24–48 hours depending on TTL and cache behaviour. For this reason, it is better to verify the live DNS state rather than rely on one device only.
First check the type of DNS change you made
Before testing propagation, identify what was changed. The method for checking depends on whether you updated a record or changed the nameservers themselves.
A record or AAAA record update
If you changed the IP address for your website, your domain is likely pointing via an A record (IPv4) or AAAA record (IPv6). Propagation testing should confirm whether public resolvers now return the new IP address.
CNAME record update
If your host asked you to point www or another hostname to a different target, check that the CNAME resolves correctly and that it does not conflict with another record on the same hostname.
Nameserver change
If you switched the domain to different nameservers, the domain delegation at the registry level must update first. This can take longer to reflect than a simple record edit inside a DNS zone.
MX, SPF, DKIM, or mail routing changes
If the issue affects email, check the mail-related records separately. Website DNS may be correct while MX or TXT records still point to old values.
How to check whether DNS changes have propagated
Use more than one method. A single check can be misleading because it may be showing cached data from your own network.
1. Check the record in your hosting control panel
If your DNS zone is managed in Plesk or another control panel, open the domain’s DNS settings and confirm the new record is saved correctly. Make sure:
- the right record type was edited;
- the hostname is correct, for example
@,www, or a subdomain; - the value is the intended IP address or destination;
- there are no conflicting records for the same hostname;
- the zone was applied after the update.
In Plesk, DNS changes are usually visible in the DNS Settings area for the subscription or domain. If DNS is hosted elsewhere, the control panel may show only local settings and not the public authoritative DNS.
2. Query the domain from a public DNS resolver
Public DNS tools and command-line queries help show what an external resolver sees. You can test against common resolvers such as Google DNS or Cloudflare DNS.
Examples of useful checks include:
- Windows:
nslookup example.co.uk 8.8.8.8 - macOS/Linux:
dig example.co.uk @8.8.8.8 - For nameservers:
dig NS example.co.uk - For mail:
dig MX example.co.uk - For CNAME:
dig www.example.co.uk CNAME
Compare the returned value with the new record you configured. If public resolvers still show the old value, propagation or caching is still in progress.
3. Use multiple DNS lookup tools
Online DNS checkers can show results from different locations and resolver networks. This is useful when you want to know whether the change is visible globally or only in some regions.
Look for tools that display:
- multiple resolver locations;
- current A, AAAA, CNAME, MX, and TXT records;
- authoritative nameserver responses;
- TTL values.
If the tool shows a mixture of old and new values, the update is still settling across caches. If all locations show the new value, the DNS record has likely propagated successfully.
4. Check the authoritative nameservers directly
To confirm the source of truth, query the authoritative nameserver for the domain rather than a cached resolver. This tells you what the DNS zone currently holds.
Example flow:
- Find the domain’s authoritative nameservers.
- Query those nameservers directly for the record.
- Confirm the returned record matches the one in your control panel.
This is useful when a resolver still shows an old answer but the authoritative server already has the new one. In that case, the issue is caching, not a failed update.
5. Test from a different network or device
Sometimes your own computer, router, or ISP caches old DNS data. To rule this out, test the domain from:
- a mobile connection instead of your office network;
- a different browser or incognito window;
- another device;
- a public DNS resolver configured on your device.
If the domain works correctly elsewhere but not on your machine, the problem is likely local cache rather than global propagation.
How to tell whether the propagation is complete
DNS changes can be considered propagated when the following are true:
- public DNS resolvers return the new record consistently;
- authoritative nameservers show the updated value;
- your website loads from the new server on different networks;
- email routing points to the intended mail service;
- the old IP address no longer appears in standard lookups.
For website pointing changes, also test the root domain and any important subdomains, such as www, cpanel, mail, or application-specific hostnames. A domain can appear “live” while a subdomain still resolves to the previous destination.
Common reasons DNS looks propagated but the site still fails
Even when DNS is correct, the website may still not work as expected. In managed hosting and Apache-based environments, the issue may be elsewhere.
The virtual host is not configured on the new server
If the DNS now points to the correct IP but the hosting account is missing or misconfigured, Apache or the web server may show a default page, error page, or the wrong site. Check that the domain is added correctly in the hosting panel and that the document root is set to the right folder.
The SSL certificate does not match the new destination
After a domain move, HTTPS can fail if the certificate was not issued on the new server, or if the hostname has not been included properly. A browser may show security warnings even though DNS is correct.
Cache at the application or CDN level
If you use a content delivery network, reverse proxy, or application cache, the DNS record may be updated while the site still serves old content. Purge or refresh the relevant cache if applicable.
Incorrect record type
A frequent error is editing the wrong record. For example, the www subdomain may be a CNAME while the root domain uses an A record. Changing only one of them may leave part of the domain pointing to the old host.
Conflicting DNS records
Multiple records for the same name can cause unpredictable results. For instance, having both an A record and a CNAME on the same hostname is not valid in standard DNS. Clean up the zone so each hostname has the intended record type.
How TTL affects DNS propagation
TTL, or Time To Live, controls how long resolvers can cache a DNS answer. Lower TTL values usually allow changes to spread faster, while higher TTL values can keep old data visible for longer.
Before making a planned migration, it is a good practice to:
- lower the TTL in advance if possible;
- wait for the lower TTL to take effect;
- make the DNS change;
- monitor propagation across several resolvers.
If the TTL was 1 hour, some users may keep seeing the old record for up to that period. If it was 24 hours, the delay can be much longer. This is normal DNS behaviour and not necessarily a fault with the hosting platform.
What to do if propagation seems stuck
If the record has not updated after a reasonable time, work through the following checks:
- Confirm the change was saved in the correct DNS zone.
- Verify the domain is using the expected nameservers.
- Check that no secondary DNS provider is still serving an old zone.
- Clear local DNS cache on your device and browser.
- Test using a public resolver.
- Check that the new record is spelled and formatted correctly.
- Look for conflicting records or old proxy/CDN settings.
If you recently changed nameservers, remember that the registry update and DNS zone visibility are separate steps. Even if the registrar panel shows the new nameservers, some resolvers may still use cached delegation data for a while.
How to clear local DNS cache
Clearing local cache helps when only your device seems to be showing the old result.
Windows
Open Command Prompt and run:
ipconfig /flushdns
macOS
The exact command can vary by version, but a common approach is to flush the DNS cache from Terminal using the appropriate system command for your release.
Browser cache
If the site has also changed IP, clear browser cache or open the site in an incognito window. This is especially useful after switching a domain to a new hosting account where the browser may have stored redirects or old assets.
Checking propagation for common record types
Website A record
Confirm the domain resolves to the new IP on multiple public resolvers. Then open the site from a different network and verify that the correct hosting account responds.
www CNAME
Check that the alias target is correct and that the final destination also resolves properly. A CNAME can appear correct while the target still points elsewhere.
MX record
For email changes, verify both the MX priority and the destination host. Then check that the mail server receives messages and that the hostname it relies on resolves properly.
TXT records for SPF, DKIM, or verification
TXT propagation can be slower to verify manually because some tools cache results differently. Make sure the exact text matches, especially for SPF syntax and DKIM selector names.
Best practices to avoid DNS confusion during changes
- Lower TTL before planned migrations.
- Document the old and new records before editing anything.
- Change one service at a time where possible.
- Keep the old hosting active until DNS has settled.
- Test root domain and subdomains separately.
- Verify both website and email records if the move affects both.
- Use authoritative DNS checks instead of relying on one browser.
These steps reduce downtime and make it easier to tell whether an issue is caused by DNS propagation or by the server configuration itself.
FAQ
How long does DNS propagation usually take?
It often takes from a few minutes to 24 hours. In some cases it may take up to 48 hours, depending on TTL, resolver caching, and whether you changed records or nameservers.
Why does the site open on my phone but not on my computer?
Your computer may still have cached the old DNS answer. Try flushing the local DNS cache, clearing browser cache, or testing from a different network.
How can I confirm the change is live everywhere?
Check the record on multiple public DNS resolvers and compare the results. If they all return the new value, propagation is likely complete.
My control panel shows the new IP, but the website still loads the old server. Why?
The record may be correct in the zone, but your network, ISP, or browser could still be caching the old answer. It is also possible that the domain is using different nameservers than the ones you edited.
Do I need to change anything in Plesk after updating DNS?
If Plesk hosts the site, make sure the domain is added correctly, the document root is right, and the SSL certificate is in place. DNS alone does not configure the website content on the server.
Can I speed up propagation?
You cannot force every resolver to refresh immediately, but lowering TTL in advance and making sure the record is correct the first time helps reduce visible delay.
Conclusion
To check whether DNS changes have propagated, verify the record in your control panel, query public resolvers, test the authoritative nameservers, and compare results from different networks. If the DNS data is correct everywhere but the website still does not work, the issue is likely related to hosting configuration, web server setup, SSL, or caching rather than propagation itself.
For domain moves, hosting migrations, and pointing changes, a structured DNS check is the fastest way to confirm whether the update is live and where any remaining delay is coming from.