Can you speed up or force DNS propagation?

You cannot force it, because you have no control over other providers' caches. What does help is lowering the TTL before you make the change and then flushing your own DNS cache. That way you see the new value sooner yourself, and the cache expires more quickly for others after the change.

Why can I see the change already while someone else cannot?

Because every resolver has its own cache that expires at a different time. You and the other person probably use different resolvers, for example, those of different internet providers. One has already fetched the new value, while the other is still waiting for its copy to expire.

Why does my email still arrive at the old server after an MX change?

Sending mail servers remember the MX record for as long as the TTL specifies. Until that cache expires, they keep sending mail to your old server. Keep your old mailbox reachable until the change has come through everywhere, so that no messages are lost.

How do I check whether my DNS change is already live?

Use an online propagation checker such as whatsmydns.net for a worldwide picture, or look up the record yourself with dig (macOS and Linux) or nslookup (Windows). Compare the answer from the authoritative nameserver with that of a public resolver such as 8.8.8.8. If they match, propagation is as good as complete.

What is DNS propagation? How long and how to check

Q: What exactly is DNS propagation?

DNS propagation is the time it takes for a DNS change to become visible everywhere. The change is live almost immediately on the authoritative nameservers for your domain. The delay happens because DNS resolvers along the way still keep a cached copy of the old answer until it expires.

Q: How long does DNS propagation take?

A record change is usually live everywhere within a few minutes to a couple of hours, depending on the TTL. As an outer limit, allow 24 to 48 hours. Nameserver and registrar changes tend to sit at the upper end of that range because the registry of the top-level domain also has to be updated.

DNS propagation is the time before a DNS change is visible everywhere. Learn why TTL and caching cause it, how long it takes, and how to check it.

You have just made a DNS change (for example, new nameservers, a different IP address, or an updated MX record), and nothing seems to happen yet. That is completely normal. DNS propagation is the time it takes for such a change to become visible everywhere on the internet. This article explains what DNS propagation is, why it takes time, how long it lasts, and how to check the progress yourself.

What is DNS propagation?

DNS propagation is the period during which a DNS change becomes available everywhere. The term is actually a little misleading because nothing is actively pushed or broadcast. The moment you save a change, it is live almost immediately on the authoritative nameservers for your domain. Those are the servers that give the official answer for your domain. At LJPc you manage your DNS in Plesk, and a change you save there appears on our nameservers ns1, ns2, and ns3.ljpc.network almost at once.

The delay you experience does not come from those nameservers, but from caching along the way. Everywhere between you and the nameservers, DNS resolvers keep a copy of the previous answer. As long as that copy is still valid, you see the old value. Propagation is therefore not a distribution of new data, but the expiry of outdated copies.

A DNS lookup passes through several links: your internet provider's resolver, sometimes a public resolver such as Google's (8.8.8.8) or Cloudflare's (1.1.1.1), your operating system's cache, and even your browser's cache. Each link stores the answer independently and expires at a different time. That is why a change can already be visible to you while someone else still sees the old address.

Why does a DNS change take time?

The TTL controls how long an answer is cached

Every DNS record has a TTL (Time To Live). This is a number in seconds that tells a resolver how long it may keep the answer before fetching it again. A common default is 3600 seconds, or one hour. If your old record has a TTL of one hour, a resolver may keep returning that old answer for up to an hour, even after you have already saved the new value.

At LJPc the default TTL is one hour (3600 seconds). You can set the TTL per record between 60 and 86400 seconds (one minute to one day). A lower TTL means faster changes but slightly more lookup traffic; a higher TTL does the opposite.

Not every resolver honours the TTL

In theory, a cached answer expires exactly after the TTL. In practice, some providers ignore the TTL and keep answers longer to save traffic, and there are caches in places beyond your control. That explains why a change does not arrive everywhere at the same time, and why you sometimes need patience even though everything on your side is correct.

How long does DNS propagation take?

For an ordinary record change, such as a new IP address in an A record, it is often quick: from a few minutes to a couple of hours, depending on the TTL. The well-known rule of thumb is to allow 24 to 48 hours. That outer limit mainly applies with high TTL values, with providers that stretch the TTL, and with nameserver changes.

Nameserver and registrar changes take the longest

If you switch nameservers or register a domain, an extra link is added. The link from your domain to the correct nameservers, known as the delegation, first has to be updated at the registry of the top-level domain (for example, the organisation behind .nl or .com). That step has its own cache times. For a nameserver change, therefore, expect the full 24 to 48 hours rather than the shorter time of a single record change. To learn what nameservers do, see our article on the NS record.

Common situations after a change

Almost every complaint after a DNS change can be explained by caching. If you change the IP address, some visitors will still reach the old server for a little while. If you adjust the MX record, email still arrives at the old mail server for a time. The table below summarises the most common situations.

Common symptoms during DNS propagation
Symptom	Cause	What you do
Website still shows the old site after an IP change	The old A record value is still in caches	Wait for the TTL to expire, flush your own cache, and check with a propagation checker
Email still arrives at the old server after an MX change	Sending mail servers still use the old MX record from their cache	Wait for the TTL to expire and keep the old mailbox reachable for now
A new domain or subdomain cannot be found yet	The "does not exist" answer (NXDOMAIN) is cached temporarily	Wait a while; this negative cache usually expires within an hour

Speeding up propagation: lower the TTL in advance

You cannot force propagation. Nobody can empty the caches of every provider worldwide for you. What you can do is shorten the wait in advance by lowering the TTL before you make the change.

Well before the change, lower the TTL of the record you are going to change, for example, to 300 seconds (five minutes).
Then wait at least as long as the old TTL was (so at least an hour if it was an hour), so that the old, high value has expired from caches everywhere.
Now make the actual change. Resolvers then keep the new answer for only five minutes, so you can correct a mistake quickly.
Once everything is stable, set the TTL back to a normal value such as 3600 seconds.

Important: lowering the TTL only helps beforehand. If you lower the TTL only after making the change, the old, high TTL is already in the caches and you still have to wait it out.

How do you check DNS propagation?

Use an online propagation checker

A propagation checker such as whatsmydns.net queries DNS servers at dozens of locations around the world at once and shows the answer returned from each location. At a glance, you can see where the new value is already active and where it is not yet. This is handy for tracking how far a change has spread.

Check it yourself with dig (macOS and Linux)

With the dig command, you query a record directly. Compare the answer from a public resolver with the one from the authoritative nameserver to see whether your change has been saved correctly.

# Look up the current A record
dig example.com A +short

# Compare a public resolver with the authoritative nameserver
dig @8.8.8.8 example.com +short
dig @ns1.ljpc.network example.com +short

If an authoritative nameserver (ns1.ljpc.network) already returns the new value but 8.8.8.8 still returns the old one, your change has been saved correctly and you are only waiting for the cache to expire. In the full dig output (that is, without +short), you will see a number next to the record that counts down every second. That is the remaining TTL in the cache.

Check with nslookup (Windows)

On Windows, you use nslookup. You put the server you want to query after the domain name.

nslookup example.com
nslookup -type=mx example.com
nslookup example.com 8.8.8.8

The message "Non-authoritative answer" simply means the answer comes from the resolver's cache. That is normal and not an error.

Flush your local DNS cache

Your own computer stores DNS answers too. If you want to see the new value sooner yourself, flush your local cache with the command for your system:

Windows: ipconfig /flushdns
macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
Linux (systemd): sudo resolvectl flush-caches

Note: your browser keeps its own DNS cache, separate from your operating system. Close the browser completely or clear that cache separately. Flushing your own cache only helps you; the rest of the world still has to wait out the TTL. If it still does not work after the maximum waiting time, the problem is probably not propagation but an actual mistake in the settings. In that case, work through the steps in our article on troubleshooting DNS problems.

If you cannot work it out, or a change is still stuck after the maximum waiting time, feel free to contact our support team and we will take a look with you.