DNS propagation

Every DNS record carries a number called a TTL, or time to live, that tells other computers how long they are allowed to remember the answer before checking again. When you change a record, that change does not appear everywhere at once. It has to wait for every cached copy, held by internet providers, phones, and other servers around the world, to expire and get refreshed. That waiting period is DNS propagation.

It is not a single event with a finish line. It is thousands of independent caches, each on its own clock, gradually catching up to the new answer. Two people can look up the same domain minutes apart and get different results, both correct as far as their own cache is concerned.

Why it matters to you

Propagation is the reason a DNS change never looks instant, even when it was made correctly. If you switch hosts, move mail providers, or update a record and the site or a service still looks wrong five minutes later, that is not necessarily a mistake. It might just be a cache somewhere that has not caught up yet.

The risk is acting on that assumption too casually. A real misconfiguration and a propagation delay look identical for the first hour. The difference only shows up if the problem is still there the next day. Knowing which one you are looking at saves a lot of panicked troubleshooting on a change that was actually fine.

How I set it up

When I know a DNS change is coming, I lower the TTL on the affected record a day or two beforehand if the timing allows it. A shorter TTL means caches expire faster once the real change goes live, which shrinks the propagation window from hours to minutes. After the change, I raise the TTL back up, since a very short one adds unnecessary load for no benefit once things have settled.

For changes that cannot be planned ahead, like an emergency host switch, I just build the wait into the timeline honestly rather than promising something DNS cannot deliver. I also check the change from more than one location and network, since a single test from my own machine can be misleadingly fast if my own cache already picked up the update.

What it looks like in practice

If you make a DNS change and check it right away from your own phone, it can look done immediately, purely because your device’s cache happened to update quickly. Someone else checking from a different provider an hour later might still see the old version. Neither of you is wrong.

The honest way to confirm a DNS change worked is to check from a few different networks, or simply wait a few hours and check again before declaring a problem. I never tell a client a DNS change is fully live within minutes of making it, because that promise is not mine to make. It belongs to every cache on the internet, on its own schedule.