Why run a DNS propagation test?
You have just updated a record and need to know how it looks from another country.
You are moving a critical service and want to ensure caches expire according to the planned TTL.
You must reassure stakeholders after a sensitive change on a domain.
You are about to launch an email campaign and you double-check SPF, DKIM or DMARC entries.
Quick reminder
Propagation is not magic spreading: caches simply expire. The test shows which resolvers still hold the old value and how long they will keep it.
What the propagation tool measures
Simultaneous queries to the main public resolvers (Google, Cloudflare, Quad9, OpenDNS, Yandex...).
Comparison with the authoritative server to detect discrepancies.
Tracking of remaining TTL and refresh date on every checkpoint.
Timestamped history to document a migration or an incident.
How the verification works
Each resolver returns its current answer and the TTL still in cache.
The test displays when the data was fetched from the authoritative server.
If a resolver keeps the old value, you immediately see how many minutes are left before expiry.
Results are compared with the authoritative response to confirm the final state.
Tip
Run the test again a few minutes later to see the progress. You can share a public link so everyone watches the same view.
When to launch a propagation test
Before switching to a new host or CDN.
When adding a TXT record for a domain verification.
After updating an MX record to validate mail delivery.
During an incident to prove that the fix is propagating.
As a routine to check that TTL values follow your policy.
Reading the results
All resolvers show the new value
Propagation is done: close the incident or inform your customers.
Some resolvers still deliver the old answer
Wait for the reported TTL to expire. Check for extra local caches on ISP side if delays persist.
A public resolver returns NXDOMAIN
The authoritative server does not serve the record yet. Check the SOA serial and trigger a zone reload if required.
Very long TTL
Consider lowering the TTL ahead of a major change. Raise it back afterwards to reduce load on authoritative servers.
Best practices
Plan the change window with a reduced TTL in advance.
Document every measurement and archive screenshots of your tests.
Automate a verification after each major deployment.
Invite support teams or providers to follow the shared report.
Quick FAQ
How long does DNS propagation take?
It depends on the configured TTL and resolver policies. Most changes appear within minutes, but some ISPs can keep the previous value until the maximum TTL.
Can I force propagation?
No, but you can lower TTL beforehand and purge the caches you control (for example your own recursive resolvers) to accelerate visibility.
Do I need to test every record?
Focus on critical records: A, AAAA, CNAME, MX, TXT, NS, SOA. Add CAA, PTR, SRV or SVCB depending on your context.