How do you test DNS propagation?

You've just published a new SPF, DKIM, or DMARC record and now you're wondering: is it actually live everywhere? That's what DNS propagation testing is about. When you change a DNS record, that change doesn't teleport instantly to every resolver on the planet. It spreads out over time, and how long that takes depends on the TTL (time to live) of the old record. Until it fully propagates, some mail servers might still see the old value.

Here's how to check it properly, step by step.

Step 1: Use a global propagation checker

whatsmydns.net and dnschecker.org are the two tools most people reach for first. Both query DNS resolvers from 20-plus locations around the world simultaneously and show you what each one returns. Type in your domain, pick the record type (TXT, MX, CNAME, etc.), and hit search.

What you're looking for: all locations returning the same value. Green checkmarks across the board. If you see a mix of old and new values, propagation is still in progress. That's normal, not broken.

Step 2: Query specific resolvers from the command line

If you want more control, you can query individual resolvers directly using dig:

• dig @8.8.8.8 TXT yourdomain.com (Google's public DNS)
• dig @1.1.1.1 TXT yourdomain.com (Cloudflare's resolver)
• dig @208.67.222.222 TXT yourdomain.com (OpenDNS)

These are public resolvers that many ISPs and mail servers use. If your new record shows up correctly on all three, you're in good shape for most of the world. If one still shows the old value, it's still working through its cache.

Step 3: Check the authoritative source directly

There's a difference between what the world's resolvers are caching and what your DNS provider is actually serving. To see the ground truth, query your authoritative nameserver directly. You can find your authoritative nameservers with dig NS yourdomain.com, then query one of them with dig @ns1.yourprovider.com TXT yourdomain.com.

But if the authoritative nameserver is returning the new value but some resolvers aren't yet, that's a caching lag. If the authoritative nameserver is returning the wrong value, the problem is with how you published the record.

What to do if propagation is taking forever

Check what TTL your old record had before you changed it. If it was set to 86400 (24 hours), some resolvers might hold onto the cached version for the full 24 hours before fetching the new one. You can't speed up the past, but going forward you can set a lower TTL before making changes. Something like 300 to 600 seconds (5 to 10 minutes) is a common pre-change trick.

Full propagation for most records lands somewhere between a few minutes and 48 hours depending on your registrar, your old TTL, and how aggressive various resolvers are about cache clearing.

Once your records are showing consistently everywhere, it's worth running a full authentication check across SPF, DKIM, and DMARC to confirm everything is wired up correctly, not just published. Our free SPF checker is a good starting point if you want a quick read on whether your record is syntactically valid and globally visible.