My Tool Studio
Webmaster & Network·4 min read

DNS Propagation: Why Changes Take Time and How to Check

You changed a DNS record ten minutes ago. Your phone shows the new site, your laptop shows the old one, and a client in another city says nothing has changed at all. Nothing is broken. You are watching caches expire at different times. Once you understand what DNS propagation really is, the waiting stops being a mystery and becomes something you can measure, plan for and usually shorten.

DNS recordsFoundA93.184.16.3MXmail.hostTXTv=spf1 ~allNSns1.dns.com

Propagation is caching, not broadcasting

Nothing is pushed anywhere.

The phrase suggests your new record ripples outward across the internet like a wave. It does not. The moment you save a change, your DNS provider's authoritative servers answer with the new value. The delay comes from everyone else: the resolvers run by internet providers, companies and public services such as Google and Cloudflare.

Each resolver stores the answers it fetches and reuses them until their time to live, the TTL, runs out. Only then does it ask your nameservers again. So propagation is the time it takes for every cached copy of the old answer to expire. Two resolvers that fetched your record at different moments will switch over at different moments, which is exactly why two devices in the same room can disagree for a while.

What a propagation check actually shows

Ask many resolvers the same question.

DNS Propagation Checker asks up to 13 resolvers the same question at the same time: Google, Cloudflare, Quad9, OpenDNS, AdGuard, Mullvad, DNS.SB, Control D, CIRA, NextDNS, AliDNS, DNSPod and our own server. Each row shows the answer, the remaining TTL and how long the resolver took to reply. Identical answers are grouped, so a split between an old and a new value stands out immediately.

Type the value you expect into the expected field, such as the new server's IP address or a TXT verification token, and every row is marked as a match or not. The summary counts how many resolvers already agree. Leave auto re-check running and the table refreshes every 30 seconds to two minutes, so you can get on with other work and glance back when the count reaches the total.

The checks run in your browser over DNS over HTTPS. A few resolvers refuse requests from web pages, and some networks block them, so an occasional unreachable row is normal and says nothing about your domain.

A worked example: moving a site to a new server

From old IP to new IP.

Say www.example.com has an A record pointing at 203.0.113.10 with a TTL of 3600, and you are moving the site to 198.51.100.7. On Monday you lower the TTL to 300. A propagation check that evening shows every resolver still returning 203.0.113.10, but the TTL column now reads 300 or less wherever the old one-hour copy has expired.

On Tuesday you change the record to 198.51.100.7 and run the check with that address in the expected field. Within a minute, Google and Cloudflare match; a few others still hold the old answer with TTLs counting down from 300. Five minutes later every reachable resolver matches. Had you skipped Monday's step, the same switch could have taken up to an hour, and any resolver that fetched the record just before your change would have kept sending visitors to the old server for all of it.

When resolvers disagree for good reasons

Not every split is a problem.

Some domains are meant to return different answers. Sites behind a CDN or a GeoDNS service hand out the address of the nearest edge, so a resolver that sits in Europe and one that sits in Asia get different IPs every time. A propagation check on such a site will always show several groups. Look at who owns the addresses: if every group belongs to the same CDN, the setup is working as designed.

Anycast adds another wrinkle. Public resolvers run hundreds of nodes under one address, and the node that answers you is the one nearest to you. That means a check from your browser shows what those networks answer near you. For ordinary propagation this makes no difference, because a changed record expires everywhere on the same schedule.

Mistakes that make propagation feel endless

When a change seems stuck long past its TTL, one of these is usually the cause:

  • Editing the zone at a DNS provider the domain no longer uses. Check the NS records first, because they name the servers the internet actually asks.
  • Forgetting to lower the TTL beforehand, so an old value of 86400 keeps yesterday's answer alive for a full day.
  • Testing only in a browser. Browsers and operating systems keep their own DNS cache, so the page can stay stale after resolvers have updated.
  • Changing nameservers at the registrar and expecting minutes. The NS records in the parent zone often carry TTLs of a day or two.
  • A typo in the record name, such as www.example.com.example.com, which creates a new record instead of changing the existing one.

Checking the rest of the change

Propagation is one question of several.

Once every resolver agrees, confirm the record itself is right. DNS Lookup shows the full record set with TTLs and DNSSEC status, which catches a missing MX or TXT record after a zone rebuild. For an email move, MX Lookup confirms the new mail servers resolve and have reverse DNS. And when the question is simply which addresses a hostname returns right now, with the network owner of each, Domain to IP Lookup gives the shortest answer.

After the dust settles, raise the TTL back to an hour or more. Short TTLs are a tool for change windows, not a permanent setting.

Try it now

Open DNS Propagation Checker

The tool is one click away. No sign up, no upload, no payment.

Open DNS Propagation Checker