DNS propagation explained: why your change has not appeared yet

"Wait 24 to 48 hours for propagation" is the most repeated and least accurate advice in web hosting. DNS does not propagate. There is no wave of updates rolling across the world. Your authoritative nameservers change the instant you save the record — what you are waiting for is other people's resolvers to throw away the answer they already have.

How a lookup actually works

When someone visits your site, their resolver — at their ISP, or a public one like 1.1.1.1 — asks the root servers who is responsible for .com, asks those servers who is responsible for your domain, and asks your nameservers for the record. Then it keeps the answer for as long as the record's TTL says it may. Every subsequent visitor using that resolver gets the cached copy, without your nameservers being consulted at all.

TTL is the whole story

Time to live is a number of seconds attached to every record. A TTL of 3600 means a resolver may hold that answer for an hour; 86400 means a full day. When you change a record, resolvers holding the old value keep serving it until their copy expires. That is the delay people call propagation, and you control it in advance.

The trick nobody tells you

Lower the TTL before the change, not during it:

1. A day or two ahead, set the record's TTL to 300 seconds and save.
2. Wait for the old, longer TTL to expire everywhere. This is the part you cannot rush.
3. Make the real change. Because everyone is now caching for five minutes, the world sees it in five minutes.
4. Once you are happy, raise the TTL back to 3600 or higher, which is better for resolution speed and resilience.

Do this and a migration that "takes 48 hours" takes the length of a coffee break.

Why your colleague sees the old site and you do not

Different resolvers, different cache states. You may have queried after the change and cached the new answer; they queried five minutes earlier and are stuck with the old one for another 55. Browsers and operating systems also cache DNS independently, so even flushing the resolver may not be enough. Check what the authoritative servers actually return with a DNS lookup — that is the source of truth, cache-free.

Records that catch people out

• Missing www. A record for example.com does not cover www.example.com. Both need a record, usually one A and one CNAME.
• CNAME at the apex. The standard forbids a CNAME on the bare domain alongside other records. Providers offer ALIAS or ANAME records to work around it.
• Duplicate SPF records. Two v=spf1 TXT records is a permanent error — receivers treat it as no SPF at all. Merge them into one.
• Nameservers changed at the registrar. If you moved DNS providers, the delegation itself has its own TTL, set by the registry, and often takes longer than your records.

During a migration

Keep the old server running and serving the same content for at least a few days after you switch. Some resolvers ignore TTLs and serve stale data far longer than they should; a handful of ISPs have been caught caching for a week. Leaving the old server up costs almost nothing and turns a hard cutover into a soft one.

When it really is broken

If a lookup returns nothing at all rather than an old value, that is not caching — it is a genuine fault. Check the domain has not expired with a WHOIS lookup, check the nameservers listed at the registrar match the ones you think you are editing, and confirm the zone actually has the record. An expired domain and a broken delegation both look identical to a visitor: the site simply does not exist.