Summary

This DNS propagation checker estimates how long a DNS change can stay invisible to some resolvers. Propagation is cache expiry: a resolver keeps the old answer until its TTL runs out, so the worst case equals the old TTL. New records can be cached as absent for the SOA negative TTL, and nameserver switches follow the registry's NS TTL. Enter the kind of change, the TTL, and the time since your edit to see the wait left. It runs in your browser and does not query live DNS.

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.

Check your wait window

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.

The TTL the record had before you edited it, not the new one.

How it works

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.

Before an email DNS change

Four steps that shorten the wait

This is the order we use for SPF, DKIM, DMARC, and MX edits on a sending domain.

  1. 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. 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. 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. 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.

See how Notification Harbor works
notificationharbor
Start free