Has your DNS propagated?

What is DNS propagation?

When you change a DNS record — pointing your domain to a new server, updating an MX record, adding a TXT record for email authentication — the update doesn't take effect instantly everywhere on the internet. The change has to propagate from your authoritative DNS server outward through the network of caching resolvers that every internet user actually queries.

"Has it propagated yet?" is a question every developer has asked themselves while waiting for a deploy to go live. This tool answers it concretely: it queries 8 widely-used public DNS resolvers in parallel and shows you what each one currently sees for your domain. If they all agree on the new value, you're propagated. If they don't, you're not — yet.

Why it takes time

Every DNS record has a TTL (time to live), a number of seconds telling resolvers how long they're allowed to cache the answer. When a resolver sees a record with TTL 3600, it stores the answer and serves it for the next hour without asking again. Change the record at the authoritative server, and that resolver still won't notice until its cached copy expires.

Multiply this by every resolver on the internet, each with independent caches, plus the layers above them (recursive resolvers behind ISPs, behind operating systems, behind individual browsers), and propagation is fundamentally about waiting for caches to expire. Twenty-four to forty-eight hours is the conventional safe window — usually most resolvers are updated within minutes, but stragglers can persist much longer.

How to speed up the next change

The trick is to lower your TTL before you make the change. If your record has TTL 86400 (a day) and you update it, every resolver that recently cached it will hold the old value for up to a day. But if you set TTL to 300 (five minutes) twenty-four hours before the change, every cache fully turns over in five-minute windows by the time you actually update the record. The propagation completes almost immediately.

For records that change rarely (your A record pointing to your origin server, your MX records), TTLs of 3600 to 86400 are fine and reduce resolver query load. For records you might need to flip quickly (DNS-based failover, CDN switchovers), lower TTLs are appropriate. The right value is "long enough to be efficient, short enough that you'd tolerate that much downtime on a switchover."

What the columns mean

Each row in the results table is one resolver. The status dot is green if the resolver returned at least one answer of the requested type, red on NXDOMAIN or error, amber on timeout or "no data" (the domain exists but has no record of this type). The TTL column shows the remaining time on the cached answer — a value far below the authoritative TTL means the resolver just fetched it fresh. Response time is wall-clock from when we hit the resolver to when it answered — useful for noticing slow resolvers or geographic distance effects.

For a deeper look at any single resolver's view, the DNS records tool queries Cloudflare DoH directly and returns full record-level detail across all common types.