How to identify DNS caching delays?
Still have a question, spotted an error, or have a better explanation or a source we should cite?
You updated your SPF or DMARC record yesterday. Your DNS provider's dashboard shows the new value. But external tools still show the old one, and you're not sure if the change actually took. Sound familiar?
That gap is almost always a DNS caching delay, and it's completely normal. Here's how to confirm it and stop second-guessing yourself.
Why caching happens
When a DNS resolver looks up your record, it stores a local copy for a set amount of time. That duration is controlled by your TTL (Time to Live) value. Until that timer runs out, most resolvers serve the cached copy rather than fetching a fresh one. This is by design. It reduces load on DNS servers worldwide. The downside is that after you make a change, the old record lingers everywhere until every cached copy expires.
The two-resolver test
The fastest way to confirm a caching delay is to compare what your authoritative nameserver says against what a public recursive resolver says. If they differ, you're looking at a cached old value out in the wild.
Query your authoritative nameserver directly (this is the source of truth):
dig @ns1.yourprovider.com TXT yourdomain.comThen query a public recursive resolver (this is what the rest of the internet sees right now):
dig @8.8.8.8 TXT yourdomain.comIf the first returns your new record and the second still shows the old one, that's caching at work. No action needed beyond waiting for the TTL to expire.
Check what TTL you're dealing with
The TTL in your answer tells you exactly how long to wait. Run this and look for the number in the ANSWER section:
dig TXT yourdomain.comA result like yourdomain.com. 3600 IN TXT "v=spf1..." means the cached copy has up to 3600 seconds (one hour) left to live. If you see a number close to your original TTL, the cache just refreshed and you're waiting a full cycle. If the number is small, the cache is almost stale and your new record will propagate soon.
Test from multiple locations
Your local resolver might have cleared already while resolvers elsewhere are still holding the old value. Free tools like whatsmydns.net let you check propagation from dozens of locations at once so you can see how far your update has spread. You can also use our DNS propagation guide to walk through this in more detail.
What to actually do while you wait
Honestly, mostly nothing. DNS caching is not a problem you can fix mid-flight. The old TTL on your previous record determines how long caches persist, and there's no way to force-clear caches on resolvers you don't control. If your TTL was set to 86400 (24 hours), expect up to 24 hours for full propagation.
What you can do next time is lower your TTL to something like 300 (5 minutes) a day or two before making a planned change. That way caches clear much faster after you update. Once propagation is confirmed, you can raise the TTL back up.
Still not sure what you're looking at in those dig results? Drop your domain into the SOS form and we'll take a look for free.
Contributors
Who worked on this answer
Every name links to their profile. Every company links to their site. Real people, real accountability.
