Add Website Hosts UK to your device
Install for quick access to hosting, tools, billing and support.
Understand DNS propagation, why DNS changes do not always appear instantly and what to check while waiting for updates.
DNS propagation is the time it takes for DNS changes to update across the internet. If you have just changed nameservers, an A record, CNAME record, MX record or other DNS setting, some people may see the new result quickly while others may still see the old one for a while.
This can feel confusing during website moves, email migrations and domain setup. Your website may load correctly on one network but not another. Your email may work for some senders but still route to the old provider for others.
This guide explains how long DNS propagation usually takes, why it happens, what affects it, and how to check whether your DNS changes are updating properly.
DNS propagation can take anywhere from a few minutes to 24-48 hours.
Many changes appear much sooner, but caching, TTL settings, nameserver changes and internet provider caches can affect how quickly everyone sees the update.
Some simple record changes may appear quickly.
Many DNS updates settle across common networks.
Larger changes may still be updating in places.
Nameserver changes can sometimes take this long.
DNS propagation is the process of DNS changes spreading across different networks, DNS resolvers and internet providers. When you update a DNS record, the change is not always seen by everyone at the exact same time.
For example, you might change an A record so your domain points to a new web hosting server. Your phone on mobile data may show the new website, while your office WiFi still shows the old website. This usually happens because one network has refreshed its DNS cache and another has not.
Propagation is normal. It does not always mean the change is wrong. It often means cached DNS information is still being used somewhere.
DNS propagation is like updating an address in many directories. Some directories refresh quickly, while others keep the old address for a little longer.
DNS propagation can take a few minutes, several hours or up to 24-48 hours depending on the type of change and how DNS is cached. Many normal record changes appear within a few hours, but nameserver changes can take longer.
The exact time depends on TTL values, resolver caches, registrar updates, nameserver changes, DNS provider performance and how long different networks keep old records.
If a change has only just been made, it is usually best to check the record carefully, confirm it was edited in the correct DNS zone, and allow time before making repeated changes.
| DNS change | Typical time | What it affects |
|---|---|---|
| A record change | A few minutes to several hours. | Website or subdomain pointing to an IPv4 address. |
| CNAME record change | A few minutes to several hours. | Subdomain aliases and third-party service connections. |
| MX record change | Several hours, sometimes up to 24-48 hours. | Incoming email delivery for a domain. |
| TXT record change | A few minutes to several hours. | SPF, DKIM, DMARC, verification and security records. |
| Nameserver change | Often longer, sometimes up to 24-48 hours. | Where the whole DNS zone is managed. |
DNS propagation takes time because DNS information is cached. Caching makes the internet faster because DNS resolvers do not need to ask the authoritative nameserver every single time someone visits a website.
When you change a DNS record, some resolvers may still have the old result stored. They will keep using it until the cache expires. Once it expires, they check again and receive the new record.
This is why propagation can appear uneven. The change may be correct at the source, but some networks may still be using old cached data.
DNS resolvers keep records temporarily so lookups are faster.
TTL tells resolvers how long to keep a DNS result before checking again.
Some networks see changes quickly, while others may take longer.
TTL stands for Time To Live. It is a DNS setting that tells resolvers how long they should cache a record before asking for a fresh copy.
For example, if an A record has a TTL of 3600 seconds, a resolver may cache that result for around one hour before checking again. If the TTL is higher, old records may be kept for longer.
Lowering TTL before planned DNS changes can help changes refresh more quickly, but it works best when done in advance. Lowering TTL after making a change may not help networks that already cached the old record with the previous TTL.
Can help planned changes refresh more quickly.
Can reduce repeated DNS lookups but may slow future changes.
Nameserver changes and individual DNS record changes are different. Changing an A record, MX record or CNAME record updates one instruction inside the active DNS zone. Changing nameservers changes where the whole DNS zone is managed.
Nameserver changes can take longer because the domain’s authoritative DNS provider is changing. During this period, some networks may ask the old nameservers while others ask the new ones.
Before changing nameservers, copy all important records to the new DNS provider, including A, CNAME, MX, TXT, SPF, DKIM and DMARC records. Missing records can break websites, email or verification services.
| Change type | What changes | Risk if done badly |
|---|---|---|
| A record change | Website or hostname points to a new IP. | Website may point to the wrong server. |
| MX record change | Email delivery moves to a different mail provider. | Incoming email may fail or route to the old provider. |
| TXT record change | Verification or email authentication changes. | SPF, DKIM, DMARC or service verification may fail. |
| Nameserver change | DNS management moves to another provider. | Any missing DNS records can break connected services. |
The easiest way to check DNS propagation is to use a DNS propagation checker. This shows how your DNS record appears from different locations or networks.
If some locations show the new value and others show the old value, propagation is still in progress. If all locations show the old value after a long time, the change may not have been made in the active DNS zone.
You can use our DNS Propagation Checker to monitor updates and our DNS Lookup tool to inspect current records.
Check the exact record you changed. For example, if you changed the www CNAME, do not only check the root domain A record.
This usually happens because different networks are using different cached DNS results. Your network may have refreshed and received the new record, while another network may still be using the old cached value.
It can also happen if one person is visiting the www version and another is visiting the root domain. These can have separate DNS records, so both should be checked.
Browser caching can also add confusion. Sometimes DNS has updated, but a browser still shows an old cached page. Testing in a private browser window, on mobile data, or from another network can help compare results.
www and root records differ.www versions.Website moves often involve DNS propagation. If you move a website to a new server and update the A record, some visitors may reach the new server quickly while others still reach the old server for a while.
This is why it is best to keep the old hosting active temporarily after a move. If the old server is shut down too soon, visitors still using cached DNS may see errors.
Before a planned move, lower the TTL where appropriate, copy the website to the new server, test it privately, update DNS, then monitor propagation. After the move, check the website, redirects, SSL, forms and important pages.
www versions.Email changes can be especially sensitive because customers may send messages while propagation is still happening. If you change MX records to move email providers, some mail servers may still deliver to the old provider until their DNS cache refreshes.
During an email migration, keep old mailboxes accessible temporarily. This helps catch any messages that still arrive at the old provider.
Also check SPF, DKIM and DMARC records when changing email hosting. MX records control incoming mail, while SPF, DKIM and DMARC support outgoing mail trust.
Do not close the old email service immediately after changing MX records. Some incoming mail may still route there while propagation completes.
SSL certificates can be affected by DNS propagation because certificate systems need to verify that the domain points correctly or that DNS verification records exist.
If you have just moved a website to a new host, SSL may not issue immediately if DNS has not fully updated. You may need to wait for the domain to point correctly before the certificate can be activated.
After DNS changes, use our SSL Checker to confirm the certificate is active and valid for the correct domain.
You cannot force every network in the world to refresh instantly, but you can plan DNS changes so propagation is smoother. The main step is lowering TTL before a planned change.
Lowering TTL tells resolvers to cache records for less time. This can make future changes refresh more quickly. However, it works best when done before the change, not after old records have already been cached.
You can also avoid unnecessary repeated changes. If you keep changing records during propagation, troubleshooting becomes harder.
Do this before planned migrations where possible.
Make sure new hosting, email or service settings are ready.
Use DNS checks instead of guessing from one device.
Propagation is usually close to complete when DNS lookup tools show the new value consistently across many locations, and your own tests show the correct website or email behaviour across different networks.
For website changes, test the root domain, www version, HTTPS, redirects, forms and important pages. For email changes, test receiving from external senders and sending to different providers.
If results still vary after 24-48 hours, check whether the record was changed in the active DNS zone, whether nameservers are correct, and whether old conflicting records still exist.
www both work correctly.If DNS still appears wrong after a long wait, the issue may not be propagation. You may have edited DNS in the wrong place, added the wrong value, left old records behind, or changed the wrong hostname.
Start by checking the active nameservers. Then check the exact record type and hostname. For example, if www is wrong, check the www CNAME or A record, not only the root domain.
Also check whether your DNS provider saved the record correctly and whether there are duplicate or conflicting records.
@, www or mail.If every DNS checker still shows the old value after a long time, you may not be waiting for propagation. You may have changed DNS in the wrong control panel.
A small business moves its website to a new hosting provider and updates the A record. The owner sees the new website at home, but a customer still sees the old site at work.
This is likely DNS caching. The customer’s office network may still have the old A record cached. Keeping the old hosting active temporarily helps avoid downtime while propagation completes.
A business changes MX records to move from one email provider to another. Some test emails arrive in the new mailbox, but a few customers’ emails still arrive at the old mailbox for a short time.
This can happen during MX propagation. The business should keep both mailboxes accessible temporarily and test again once propagation settles.
A business adds a TXT record to verify a domain with a third-party service. The service says it cannot find the record immediately after it is added.
The record may need time to propagate, or it may have been added to the wrong DNS zone. Checking active nameservers and using DNS Lookup can help confirm whether the record is visible.
One common mistake is making repeated changes because the first change does not appear instantly. This can create confusion and make it harder to know which value is currently live.
Another mistake is checking only one device or one network. A local computer may still be using cached DNS, while other networks already show the new value.
It is also common to forget the difference between DNS propagation and browser caching. A DNS record may be updated, but the browser may still display an old cached page.
www records.DNS propagation only matters once a domain is connected to hosting, email or another service. These guides help visitors choose the right extension first.
DNS propagation can take from a few minutes to 24-48 hours. Many changes appear within a few hours, but nameserver and email changes can take longer.
Different networks may have different DNS cache states. Your network may have refreshed while another network is still using the old cached record.
You cannot force every network to refresh instantly, but lowering TTL before a planned change can help future changes update more quickly.
It can help if your browser is showing an old page, but it does not force DNS resolvers across the internet to refresh.
The old A record may still be cached, the wrong DNS zone may have been edited, or the root and www records may not both point to the new host.
Yes. MX record changes can take time to update, so some senders may still route mail to the old email provider during propagation.
Use our DNS Propagation Checker to see whether DNS changes are appearing across different locations.
You can also use DNS Lookup to inspect specific records, WHOIS Lookup to check domain information, and SSL Checker after moving a website.
Setting up hosting or email? Compare UK Web Hosting, Business Email Hosting or visit Start Here.
Confirm the DNS record was changed correctly.
Check propagation from multiple locations.
Test website, email and SSL after updates settle.
DNS propagation is the time it takes for DNS changes to update across different networks and resolvers. Some changes appear quickly, while others can take up to 24-48 hours depending on caching, TTL and the type of change.
If your DNS change is not visible immediately, check the active nameservers, confirm you edited the correct record, and use DNS tools to monitor progress. Avoid making repeated changes unless you know the current record is wrong.
For website moves and email migrations, plan ahead. Lower TTL in advance where suitable, keep old services active temporarily, and test everything carefully once propagation completes.
Add Website Hosts UK to your device
Install for quick access to hosting, tools, billing and support.