DNS propagation is the period of time after a DNS change during which different resolvers across the internet update their cached records. In practice, it is the delay between changing a domain’s DNS settings and seeing those changes reflected everywhere. If you have just pointed a domain to a new hosting account, updated an A record, changed nameservers, or moved a website in Plesk or another control panel, propagation is the reason why some visitors may reach the new destination while others still see the old one.
For hosting customers, DNS propagation is one of the most common causes of confusion during website moves, email changes, and domain pointing updates. The good news is that propagation is normal. It is not usually a fault with your hosting account, control panel, or web server. Understanding how it works helps you plan changes properly, reduce downtime, and know what to check when a domain does not appear to update immediately.
What DNS propagation means
DNS, or Domain Name System, translates human-friendly domain names into IP addresses and other service records. When you change a DNS record, the new value must be distributed through recursive resolvers, caching systems, and sometimes the authoritative nameservers before it is visible everywhere. This distribution process is commonly called DNS propagation.
Propagation is not a single global switch. Different networks cache DNS data for different periods, so updates may appear in one location within minutes and in another after several hours. In some cases, the old record may be visible until its TTL, or Time To Live, expires. This is why two people using the same domain can see different results at the same time.
Why DNS propagation happens
DNS is designed to be efficient and resilient. Instead of checking the authoritative nameserver every time someone types a domain, resolvers store temporary copies of DNS data in cache. This reduces lookup time and improves performance across the internet. The trade-off is that changes are not always instant.
When a DNS record has a TTL of 3600 seconds, for example, resolvers may keep the old value for up to one hour before asking again for an updated record. If many resolvers have already cached the previous value, the change can continue to appear delayed until those caches expire.
Common DNS changes that can take time to propagate
- Pointing a domain to a new hosting account by changing the A record
- Updating nameservers at the registrar
- Changing CNAME records for subdomains such as www
- Adding or modifying MX records for email delivery
- Changing TXT records for SPF, DKIM, or domain verification
- Moving a site between servers in Plesk or another hosting control panel
Any of these changes can be affected by caching. The visible delay depends on the record type, TTL values, resolver behaviour, and whether the change was made at the registrar, DNS host, or within the hosting platform’s control panel.
How long DNS propagation takes
There is no exact global timeframe. Some users may see changes within a few minutes, while others may continue to see the previous record for several hours or even longer in edge cases. A common expectation is 24 to 48 hours, although many changes complete sooner.
Several factors influence the timing:
- TTL values: Lower TTL values usually allow faster refreshes
- Resolver caching policies: Some public DNS resolvers cache more aggressively than others
- Record type: A, CNAME, MX, and TXT records may be cached differently
- Where the change was made: Registrar-level changes can behave differently from zone-file changes
- Local network cache: Your device, router, or ISP may also store old DNS data
If you are updating a live website, it is best to plan for a temporary mixed state where old and new destinations may both receive traffic.
DNS propagation vs nameserver changes
People often use “DNS propagation” to describe both record updates and nameserver changes, but they are not identical.
Changing a DNS record
When you update an A record, CNAME, MX record, or TXT record, you are changing the content of a zone that is already hosted somewhere. The authoritative DNS server for the zone will usually have the updated value immediately, but resolvers may still serve the old cached value until TTL expiry.
Changing nameservers
When you change nameservers at the registrar, you are moving authority for the domain to a different DNS provider. This can take longer to fully settle because some resolvers may still query the old nameservers for a period of time while others begin using the new ones. During this transition, both DNS configurations may appear active from different locations.
For hosting customers, nameserver changes are often part of a migration, while record changes are more common when only the website or email destination changes.
What happens in a hosting control panel like Plesk
In a managed hosting environment, DNS changes are often made in the control panel, such as Plesk, or in the registrar’s DNS management area. If your domain is using the hosting platform’s nameservers, the zone can be edited directly in the panel. If the domain uses external DNS, then changes must be made with the external DNS provider instead.
Typical tasks in Plesk include:
- Editing the A record to point the domain to a new server IP
- Updating the www subdomain to match the root domain
- Adding MX records for mail service
- Managing TXT records for verification and email security
- Checking whether the domain is using the correct DNS zone
If a change appears not to work, the first thing to confirm is where the authoritative DNS is hosted. Editing the wrong DNS zone is a common reason for confusion, especially when a registrar, hosting platform, and third-party DNS service are all involved.
How to check whether DNS propagation is complete
You can verify DNS updates in several practical ways. No single check is enough on its own, because different resolvers may still have old data cached.
1. Check the authoritative DNS records
Use your hosting control panel or DNS provider to confirm that the record was changed correctly. If you are using Plesk, review the domain’s DNS settings and make sure the zone contains the new value you expect.
2. Test from different networks
Check the site or service from your office network, a mobile connection, and if possible a different public network. If some locations show the new destination and others do not, the change is likely still propagating.
3. Query public DNS resolvers
Public resolvers such as Google Public DNS and Cloudflare DNS may help you compare results from different cache layers. If they return different answers, propagation is still in progress.
4. Flush local cache
Your own device may be storing old DNS data. Clearing local DNS cache can help you confirm whether the problem is local rather than global.
5. Compare before and after TTL expiry
If you know the TTL of the old record, wait for that period to pass and test again. If the record still does not update after TTL expiry, the issue may be due to incorrect DNS configuration rather than propagation.
Practical steps to reduce DNS propagation issues
Although you cannot force the entire internet to update instantly, you can reduce disruption and make changes easier to manage.
Lower TTL in advance
If you know a site move, server maintenance, or email migration is coming, lower the TTL a day or two before the change. This helps resolvers refresh records more quickly when the update is made. A shorter TTL can reduce waiting time, especially for frequently changed records.
Keep the old service active during the transition
For website migrations, keep the old hosting account accessible until propagation has had enough time to complete. This prevents visitors who still resolve the old IP from seeing an error page.
Update www and root records consistently
Make sure the root domain and www subdomain both point to the correct destination. A common issue is updating one but not the other, which leads to inconsistent results during propagation.
Check MX records before changing email-related DNS
If you are moving email service, review MX, SPF, DKIM, and DMARC records together. Incomplete updates can lead to delivery problems even after the DNS change appears to have propagated.
Avoid frequent back-and-forth changes
Each new edit can restart the practical waiting period for some resolvers. If possible, make all required DNS changes in one planned update rather than several small changes in a short time.
How DNS propagation affects website visitors
During propagation, visitors may experience different outcomes depending on which DNS resolver they use. Some may see the new website, others the old one, and some may be unable to access the correct service if the previous destination has been removed too soon.
For website changes, this can produce:
- Mixed content between old and new hosting
- Temporary certificate warnings if SSL is not ready on both sides
- Different versions of the site in different regions
- Temporary 404 or connection errors if the old server is offline
For email changes, propagation issues can cause delayed mail delivery or routing to the previous mailbox provider if MX records are not fully updated everywhere.
What not to do during DNS propagation
It is easy to assume a DNS change has failed when it has simply not fully propagated. Before making additional changes, avoid the following:
- Repeatedly editing the same record without confirming the authoritative zone
- Deleting old DNS records too early during a migration
- Changing nameservers and records at the same time without a plan
- Assuming your own browser view reflects the global result
- Overlooking cached records on routers, devices, or ISP resolvers
If you are unsure, document the old settings before making changes so you can compare them later if needed.
Troubleshooting when DNS still does not update
If the expected change is still not visible after a reasonable period, use this checklist:
- Confirm the domain is using the correct authoritative nameservers.
- Verify the record was changed in the correct DNS zone.
- Check for conflicting records, such as an old A record or an unexpected CNAME.
- Review TTL values on both the old and new records.
- Flush local DNS cache and test from another network.
- Ensure the destination server is ready to receive traffic.
- For websites, confirm the web server configuration and virtual host are set up correctly.
In hosting platforms, a DNS issue is sometimes actually a server-side issue. For example, a domain can point to the right IP, but the site may still fail if the Apache virtual host, Plesk subscription, or SSL configuration is not ready.
DNS propagation examples
Example 1: Pointing a domain to a new website
You move your site to a new hosting account and update the domain’s A record to the new server IP. Some users load the new site immediately, while others still see the previous version for a few hours. This is normal propagation. Keeping the old site online during the transition avoids downtime for users with cached records.
Example 2: Changing mail provider
You switch email service and update the MX records. Incoming mail may continue to arrive at the old provider for a short time because some resolvers still cache the previous MX data. To avoid missed messages, keep both mail systems in place during the overlap if possible and monitor delivery carefully.
Example 3: Updating verification TXT records
You add a TXT record for domain verification or email authentication. A third-party service may not detect the change right away if it is checking through a resolver that still holds the old response. Wait for propagation, then verify again from a different network if needed.
FAQ
Is DNS propagation instant?
No. The authoritative record may update immediately, but caching across resolvers means it can take time before the change is visible everywhere.
Can I force DNS propagation?
No. You cannot force caches across the internet to refresh instantly. You can only reduce delays by using sensible TTL values and planning changes carefully.
Why do I see the old website on my laptop but the new one on my phone?
Your laptop and phone may use different DNS resolvers or cached data. This is a common sign that propagation is still in progress.
Does clearing browser cache fix DNS propagation?
Usually not. DNS is separate from browser cache. You may need to clear local DNS cache or test from another network, but browser cache alone will not resolve a DNS update issue.
How long should I wait before worrying?
For many changes, waiting up to 24 to 48 hours is reasonable. If the record still has not updated after that and the authoritative DNS is correct, investigate the configuration rather than assuming it is only propagation.
Why did my email stop working after a DNS change?
Email often depends on several records, including MX, SPF, DKIM, and DMARC. If one of these was changed incorrectly or not updated in the correct zone, delivery can fail even if the domain itself appears to point correctly.
Conclusion
DNS propagation is the normal delay that occurs after DNS changes while resolvers update their cached data. Whether you are pointing a domain to a new hosting account, updating nameservers, or changing mail records in a control panel such as Plesk, propagation explains why changes do not always appear everywhere at once.
The most reliable approach is to plan changes in advance, lower TTL values before a migration, keep old services available during the transition, and verify that you are editing the correct authoritative DNS zone. With the right preparation, DNS changes can be smooth and predictable even when propagation takes time.