How to Check DNS Propagation (Step-by-Step Guide)
A practical step-by-step guide to checking DNS propagation, including what to compare, how TTL affects results, and how to interpret inconsistent answers.
Start with the exact record type
When checking DNS propagation, always begin by identifying the exact record type that changed. If you updated an MX record, check MX. If you updated a TXT record such as SPF or DKIM, check TXT.
Looking at the wrong record type can give a misleading impression of whether the change has propagated.
You can verify specific record types using a DNS lookup tool, ensuring you are querying the correct record directly.
Compare multiple resolvers
The most reliable way to assess propagation is to compare responses from multiple public DNS resolvers, such as Google and Cloudflare.
If different resolvers return different answers, the change is likely still propagating or cached differently across networks.
This is significantly more informative than checking a single resolver.
Tools can help you query multiple sources quickly and compare results side by side.
Understand how TTL affects propagation
TTL (Time To Live) controls how long a resolver is allowed to cache a DNS response before it must refresh it from the authoritative source.
If a record had a high TTL before you made a change, some resolvers may continue serving the old value until that TTL expires.
Lower TTL values can help changes become visible more quickly, but they do not force immediate updates — they only control cache duration.
When troubleshooting propagation, always consider what the previous TTL was, not just the current one.
Check the authoritative source
To confirm whether a change has been correctly published, query the authoritative nameserver directly rather than relying only on public resolvers.
If the authoritative server returns the new value, the change is live and any differences elsewhere are due to caching.
If the authoritative server still returns the old value, the change has not been applied correctly at the source.
Advanced DNS tools can help identify authoritative responses and distinguish them from cached results.
What different outcomes usually mean
- Same answer everywhere: strong indication the change has fully propagated
- Different answers at different resolvers: normal propagation or caching behaviour
- Old answer persists on some resolvers: TTL has not yet expired
- No answer at some resolvers: possible misconfiguration or record removal
- Authoritative answer differs from public resolvers: expected during the propagation window
Common mistakes when checking propagation
- Checking only one resolver and assuming global propagation
- Looking at the wrong record type, such as checking A instead of MX
- Ignoring TTL timing and cache behaviour
- Forgetting that previous TTL values control cache duration
- Assuming every mismatch is a configuration issue rather than normal DNS behaviour
A practical DNS propagation workflow
- Identify exactly which record changed and its type
- Query the authoritative nameserver to confirm the new value is published
- Check multiple public resolvers for comparison
- Review TTL values to understand expected cache duration
- Use a DNS tool such as DNS Pro to compare results quickly
- Wait for TTL expiry before assuming there is a problem
- Re-test after the expected propagation window has passed
When propagation is not the problem
Not all DNS issues are caused by propagation. If inconsistent behaviour persists beyond the expected TTL window, the issue may be related to incorrect records, delegation problems, or missing configuration.
For example, email delivery issues may instead be caused by misconfigured SPF, DKIM, or DMARC records rather than propagation delays.
Understanding this distinction helps avoid unnecessary waiting when the root cause is actually a configuration error.