DNS Propagation — Which Resolvers Have Your Change Yet
Propagation checking queries the same record against many public resolvers around the world simultaneously and shows you who has the new value and who is still serving the old one. The word propagation is slightly misleading — DNS does not push changes anywhere; each resolver simply caches an answer until its TTL runs out and then asks again. What you are really watching is a set of independent caches expiring at different times.
Why run it
During any cutover, the question is always whether an inconsistency is normal or a mistake, and a single lookup cannot tell you. If most resolvers have the new value and a few have the old one, that is caching behaving exactly as designed and the fix is patience. If none have it, the change did not take effect — wrong zone, wrong record, or edits made at a registrar that is no longer authoritative. Those two situations feel identical from your desk and demand opposite responses.
Why automate it
A migration is not a moment, it is a window, and someone has to keep watching until it closes. Scheduling the check across that window means you are not repeatedly refreshing a page to find out whether you can decommission the old host yet, and you get a definite answer to the question that actually matters — has every resolver we care about picked this up — rather than a hopeful guess. It also catches the resolver that never updates because it is serving a stale answer for reasons of its own.
What it gives you
Confidence during the least reversible operations you perform. Knowing the difference between "still propagating" and "never going to propagate" is what determines whether you wait or roll back, and it is not a distinction a single query can make.