How DNS propagation actually works

The short version

When you ask for a domain such as example.com, your device normally asks a recursive DNS resolver. That resolver may already have the answer cached. If the cached answer is still valid, it can return it immediately without asking the authoritative nameserver again.

When you change a DNS record, authoritative DNS may have the new value straight away while some recursive resolvers still hold the old value. That temporary disagreement is what is usually described as DNS propagation.

TTL controls how long an answer may be cached

DNS records carry a TTL, or Time To Live, measured in seconds. A TTL of 300 allows a resolver to cache the answer for up to five minutes. A TTL of 3600 allows it for up to an hour.

Changing the TTL at the same moment as the record does not instantly shorten caches that were created using the previous TTL. If you know a significant change is coming, lowering the TTL beforehand can reduce the period during which old data remains cached.

Why two resolvers can disagree

Cloudflare, Google Public DNS, Quad9, your ISP resolver and a corporate resolver may have cached the domain at different times. One can refresh seconds after your change while another still has several minutes left on its cached copy.

Resolver-specific filtering, DNSSEC validation failures and differing upstream paths can also create differences. A disagreement does not automatically mean one resolver is broken.

Propagation is not the same as authoritative DNS

If you need to know what the zone currently publishes, query the authoritative nameservers or use a normal DNS lookup with the right record type. A propagation checker is most useful when the authoritative answer is correct but users still report seeing something older.

For signed zones, DNSSEC adds another layer: the records must not only exist, but the cryptographic chain must validate. A bad DS or DNSKEY change can make a domain fail for validating resolvers even when other DNS records look correct.

A practical troubleshooting order

1. Check the record itself. Confirm the expected A, AAAA, CNAME, MX, TXT or other record is published.
2. Check the authoritative side. Make sure the nameservers responsible for the zone agree.
3. Compare recursive resolvers. Look for old versus new answers and note their TTLs.
4. Check DNSSEC if enabled. A validation problem can look like missing DNS to some users.
5. Wait for existing caches when appropriate. Repeatedly changing the record can make diagnosis harder.