# DNS Propagation Checker: Estimate Your Wait Window URL: https://notificationharbor.com/tools/dns-propagation-checker Type: tool Locale: en Published: 2026-10-07 Updated: 2026-10-08 --- > Estimate the worst-case wait after a DNS change from the TTL and the time since your edit. Runs in your browser, covers records, new DKIM keys, and nameserver switches. ## DNS propagation checker: how long until your change is live Enter the TTL and the time since your edit. This DNS propagation checker shows the worst-case wait left for a record change, a new DKIM key, or a nameserver switch. ## DNS propagation checker Pick the kind of change, enter the TTL that applies and the time since you saved it. The result updates as you type, and nothing leaves your browser. *[Interactive widget — see the live page for the full experience]* ## What the calculator actually measures ### Propagation is cache expiry DNS does not push changes anywhere. Each resolver keeps the answer it fetched until the TTL runs out, then asks again. The slowest resolver is the one that fetched the old answer just before your edit, so the worst case equals the old TTL. ### New records have their own clock A record that did not exist can still be cached as absent. That negative answer lasts for the smaller of the SOA TTL and the SOA minimum field. If nobody queried the name early, the new record is visible immediately. ### Nameserver changes follow the registry Switching nameservers changes the NS records at the parent zone, and you do not set that TTL. The calculator takes it as an input, with two days as the typical value for large TLDs such as .com. ## Four steps that shorten the wait 1. **Read the current TTL** — Run dig on the record and read the number in the answer section. That is the TTL your change will have to outlast. 2. **Lower it ahead of time** — Set the TTL to 300 seconds, then wait at least as long as the old TTL before you edit the record. Resolvers must expire the long-lived copy first. 3. **Make the change and note the time** — Save the edit, write down the clock time, and enter the elapsed time into the calculator above. 4. **Verify at the source, then at a resolver** — Query your authoritative nameserver first, then a public resolver. Raise the TTL back once both agree and the window has passed. ## Common questions ### Is this DNS propagation checker free? Yes. No signup, no request limit. The calculation is arithmetic on three numbers you type in, so it runs in your browser and nothing is sent to our servers. ### Does it query live DNS servers? No. It does not look up your record from resolvers around the world. It computes the longest time a cached answer can survive, from the TTL you enter. To see what a specific resolver returns right now, run dig against that resolver and compare it with the window shown here. ### Why does the estimate use the old TTL and not the new one? Resolvers cache the answer they fetched before your edit, along with the TTL that came with it. Lowering the TTL in the same edit does nothing for resolvers that already hold the old answer. The new TTL only applies to answers fetched after the change. ### What is the negative caching TTL, and when does it apply? When a resolver asks for a name that has no record, it can cache the "does not exist" answer (RFC 2308). That lasts for the smaller of the SOA record's own TTL and its minimum field. It only affects resolvers that queried the name before you created the record, for example a DKIM selector that someone tested too early. ### Why does a nameserver change take so long? The NS records that point to your nameservers live at the registry, with a TTL you do not control. For large TLDs such as .com that TTL is commonly two days. Until it expires, some resolvers keep asking your old nameservers. ### I am past the window and still see the old value. What now? Stop blaming caches. Query your authoritative nameserver directly and confirm it serves the new value. If it does not, the edit went to the wrong zone, the wrong host name, or was never saved. If it does, test from a resolver you have not used before, and check for a local cache on your own machine or network. ### Does this apply to SPF, DKIM, and DMARC records? Yes. They are TXT records, cached like any other. A receiving server that cached your old SPF record keeps evaluating it until the TTL runs out, so a send right after an edit can be judged against the old policy. ## Track the infrastructure behind your own sends This tool estimates a wait. Notification Harbor covers the sends you control: domain warmup, trace-level observability, and SPF, DKIM, and DMARC set up correctly before the first production send. *Call to action: See how Notification Harbor works* ## FAQ ### Is this DNS propagation checker free? Yes. No signup, no request limit. The calculation is arithmetic on three numbers you type in, so it runs in your browser and nothing is sent to our servers. ### Does it query live DNS servers? No. It does not look up your record from resolvers around the world. It computes the longest time a cached answer can survive, from the TTL you enter. To see what a specific resolver returns right now, run dig against that resolver and compare it with the window shown here. ### Why does the estimate use the old TTL and not the new one? Resolvers cache the answer they fetched before your edit, along with the TTL that came with it. Lowering the TTL in the same edit does nothing for resolvers that already hold the old answer. The new TTL only applies to answers fetched after the change. ### What is the negative caching TTL, and when does it apply? When a resolver asks for a name that has no record, it can cache the "does not exist" answer (RFC 2308). That lasts for the smaller of the SOA record's own TTL and its minimum field. It only affects resolvers that queried the name before you created the record, for example a DKIM selector that someone tested too early. ### Why does a nameserver change take so long? The NS records that point to your nameservers live at the registry, with a TTL you do not control. For large TLDs such as .com that TTL is commonly two days. Until it expires, some resolvers keep asking your old nameservers. ### I am past the window and still see the old value. What now? Stop blaming caches. Query your authoritative nameserver directly and confirm it serves the new value. If it does not, the edit went to the wrong zone, the wrong host name, or was never saved. If it does, test from a resolver you have not used before, and check for a local cache on your own machine or network. ### Does this apply to SPF, DKIM, and DMARC records? Yes. They are TXT records, cached like any other. A receiving server that cached your old SPF record keeps evaluating it until the TTL runs out, so a send right after an edit can be judged against the old policy.