Change a DNS record and the world does not update at once. Enter a domain and a record type and this checker asks Google, Cloudflare and other public resolvers what they return right now, so you can see whether your change has spread or is still propagating.
Loading tool…
Lower stack cost. Back in the inbox. Built to send at any scale.
We rebuild it properly: secondary domains, inboxes, SPF, DKIM and DMARC set to enforcement, warmup and safe sending limits, blacklist monitoring on top. Send-ready in about 17 days. No campaigns, no copy, no lead lists. Infrastructure only.
Almost a decade building cold outreach infrastructure, including his own sending and verification stack built from scratch. 20+ B2B clients at companies worth $10M and above, all in tier one countries.
Free · Written plan + fixed price · No sales call required
When you change a DNS record, there is no single switch that updates the whole internet at once. DNS answers are cached by resolvers all over the world, and each cache keeps the old answer until its time to live, the TTL, runs out. Propagation is simply that waiting period: the stretch of time while some resolvers still serve the old answer and others have already picked up the new one. Nothing is broken while it happens. It is how DNS is designed to work, because caching is what makes lookups fast and keeps the system from being flooded with repeated questions.
Enter the domain you changed, pick the record type you edited, and run the check. Each row is one public resolver and the answer it gives right now, with the TTL it reports. If every resolver returns the same set of values, your change has spread as far as these resolvers can tell. If one or more resolvers still return a different value, the change is still propagating and those resolvers are serving a cached copy. A row that shows no record means that resolver has no answer of that type for the name. The verdict at the top sums it up in one line. For more checks on the same domain, see the Domain Health Checker and the Domain Age Checker.
Say you move coldmailkit.com to a new host and update its A record. Right after the change, checking coldmailkit.com with the record type set to A might show some resolvers returning the new address and others still returning the old one. That split result is normal while caches drain. Once the old TTL has passed everywhere, every resolver returns the same address, and the checker reports that the record has propagated. The same pattern applies to the records mail depends on: after an MX change, the MX Record Checker shows where mail is delivered, and the CAA Record Checker shows who may issue certificates.
Mostly, wait. Lower the TTL on the record before a planned change, a day or so ahead, so caches clear faster when you make the change. Then make the change once, and let the old TTL pass in full before you judge the result. Do not keep re-editing the record while you wait: each edit can restart caching on some resolvers and makes the picture harder to read. Check here from time to time instead, and only treat the change as done when every resolver agrees.
It depends on the TTL of the record you changed. Many records use a TTL of one hour or less, so the change is visible everywhere within a few hours. Records with a TTL of a day can take that long to clear from every cache. There is no fixed schedule, because each resolver refreshes on its own clock.
Each resolver caches answers on its own. One resolver may have fetched the record just before your change and keeps serving that copy until its TTL expires, while another fetched it just after and already has the new value. Different values during that window are the normal sign of a change spreading.
Usually not. The 48 hour figure is a safe upper estimate from the days when long TTLs were common. Most changes today are visible within a few hours, and many within minutes. A record can only take as long as its own TTL, plus the time resolvers take to notice.
You cannot force resolvers to drop their caches, but you can plan ahead: lower the TTL on the record at least a day before a planned change, so that when you make the change the old answer expires quickly. After the change, patience is the only tool. Checking more often does not make it faster.
TTL is the number of seconds a resolver is allowed to cache a record. It is the clock that drives propagation: a cached answer stays in place until its TTL runs out, and only then does the resolver ask again and see your change. A short TTL means fast updates and more queries; a long TTL means slower updates.
Because different people use different resolvers. Someone whose resolver has already refreshed sees the new record, while someone whose resolver still holds the cached answer sees the old one. It is not about geography or the device they use; it is about which cache answers them.
No. Repeated edits make things worse: resolvers that had just refreshed can cache a half-finished state, and you lose track of which value is spreading. Make the change once, confirm the value is correct at your DNS host, and then wait for the old TTL to pass.
No. The queries run from your browser to a few large public resolvers, the same ones many networks use. The results show what those resolvers answer right now, which is a good picture of what the world sees, but it is not a test from your street or your office network.
It covers what is broken, what we would build, the timeline, and one fixed price. Want it walked through instead? Book a 15 minute plan walkthrough.
Or just reply to the plan email. Either works.
