DNS changes can appear correct in one location and outdated in another. This guide provides a repeatable way to troubleshoot DNS propagation problems, distinguish caching from configuration errors, verify website and email changes, and record checkpoints after every domain, hosting, CDN, or security update.
Overview
DNS propagation is the process by which DNS resolvers begin returning a changed record. The term can be misleading: DNS does not move through the internet as one coordinated update. Recursive resolvers cache answers for different periods, authoritative nameservers may hold different data if they are not synchronized, and devices or networks can add their own caching behavior.
When a DNS change is not working everywhere, start by identifying which layer is returning the unexpected result. The main possibilities are:
- Authoritative DNS is wrong: the nameservers responsible for the domain do not contain the intended record.
- Delegation is wrong: the registrar has not delegated the domain to the DNS provider you edited.
- A resolver is serving a cached answer: the resolver has not reached the record's expiry time.
- The local network is caching: your operating system, browser, router, VPN, or corporate DNS may have an older answer.
- The DNS answer is correct but the service is not: the web server, TLS certificate, firewall, CDN, or mail system may still be misconfigured.
A propagation checker can show useful differences between locations, but it should not be your only test. First confirm the authoritative answer, then compare several independent recursive resolvers, and finally test the actual website or email path.
What to track
1. Record the intended change
Before editing DNS, note the fully qualified name, record type, old value, new value, TTL, and reason for the change. For example, an A record might point www.example.com to a new IPv4 address, while a MX record might route mail to a new provider. Include whether the change was made at the registrar, a hosting control panel, a DNS hosting provider, or a CDN.
This record prevents a common mistake: editing one DNS dashboard while the domain is actually using nameservers managed somewhere else.
2. Check authoritative nameservers and delegation
Find the domain's delegated nameservers with a command such as:
dig NS example.com +short
dig NS example.com @1.1.1.1 +shortThen query one of those authoritative servers directly. Replace ns1.example-dns.com with the actual authoritative nameserver:
dig A www.example.com @ns1.example-dns.com
dig MX example.com @ns1.example-dns.com
dig TXT example.com @ns1.example-dns.comIf the authoritative response is wrong, waiting will not solve the problem. Review the record name, record type, target, proxy or CDN setting, and whether the DNS provider saved the change. If the authoritative servers disagree, investigate provider synchronization or delegation before checking local caches.
3. Compare recursive resolvers
Query more than one resolver to identify cached or network-specific results:
dig A www.example.com @1.1.1.1
dig A www.example.com @8.8.8.8
dig A www.example.com @9.9.9.9The exact resolver addresses are examples, not a requirement. A DNS propagation checker can provide a broader regional view, but compare its results with direct command-line queries. Pay attention to the returned value and the TTL remaining in the answer. A low remaining TTL suggests that a cached answer may expire soon; it does not guarantee that every resolver will refresh at the same moment.
4. Track the right symptoms
| Symptom | First checks | Likely direction |
|---|---|---|
| Some locations show the old website | Authoritative A or CNAME response; resolver results; TTL | Caching, split DNS, or an incorrect record |
| The domain does not resolve anywhere | NS delegation, DNSSEC status, authoritative response | Delegation, DNSSEC, or provider configuration issue |
| Website resolves but HTTPS fails | Certificate names, CDN origin, hosting configuration | SSL or service configuration rather than propagation |
| New email provider receives no mail | MX records, priorities, SPF, DKIM, and DMARC | MX caching or incomplete mail setup |
| Only office users see the old result | Corporate resolver, VPN, router, and split-DNS rules | Local or internal DNS caching |
Cadence and checkpoints
Use a short verification schedule after a DNS change rather than repeatedly refreshing one browser tab. Check immediately to confirm that the authoritative server contains the intended value. Check again after the previous record's TTL has had time to expire, then compare several recursive resolvers and at least one network outside your usual connection.
The correct waiting period depends on the old cached TTL, resolver behavior, negative caching, and the type of change. Nameserver changes can involve delegation and should be treated separately from an individual A, CNAME, MX, or TXT update. Do not promise a universal propagation window. If a change remains inconsistent after the relevant TTL period and the authoritative answer is correct, investigate resolver-specific caching, DNSSEC, or split DNS instead of waiting indefinitely.
For a website migration, use these checkpoints:
- Confirm the new hosting server works through its temporary URL, hosts-file test, or provider-provided preview method.
- Verify the authoritative A, AAAA, or CNAME records.
- Test the apex domain and important subdomains separately.
- Confirm HTTPS on every hostname and check redirects after DNS begins resolving to the new service.
- Keep the previous hosting environment available until traffic and error logs show that the transition is complete.
For email, verify MX records and then test both inbound and outbound delivery. Also check provider-specific TXT records for SPF, DKIM, and DMARC. A correct MX response alone does not prove that mailbox provisioning, authentication, or spam-policy settings are complete.
How to interpret changes
Authoritative value wrong: treat this as a configuration problem. Check for a typo, an unintended trailing dot, an incorrect host field, or a record created in the wrong DNS zone. Some interfaces expect only the host label, while others expect the full domain name.
Authoritative value correct, recursive value old: this is consistent with caching. Compare the answer's TTL and recheck from another resolver or network. Flushing your local cache may help your device, but it cannot clear caches maintained by external recursive resolvers.
Different authoritative servers disagree: do not classify the issue as ordinary propagation until the discrepancy is understood. Check whether all delegated nameservers belong to the intended provider and whether the DNS zone is synchronized.
DNS is correct, but the site fails: troubleshoot the destination. Confirm the web server is listening, the hosting account accepts the domain, the firewall allows traffic, and the SSL certificate covers the hostname. For a focused HTTPS workflow, see SSL Certificate Errors Explained.
Only internal users see a different answer: look for split DNS, private hosted zones, VPN policies, or an enterprise resolver overriding public DNS. Test from a mobile connection or another external network, while remembering that public and private answers may be intentionally different.
Keep a change record with this format:
Date and time (with time zone):
Domain and hostname:
Record type:
Old value:
New value:
TTL before and after:
Authoritative query result:
Resolver results:
Website or email test:
Next checkpoint:
Owner and rollback plan:When to revisit
Return to this checklist whenever you change nameservers, move web hosting, connect a domain to a CDN, update an email provider, renew or replace DNSSEC settings, or add a verification record. It is also useful after a domain transfer, because registrar control and DNS hosting control may be separate.
For stable domains, review the change log monthly or quarterly. Confirm that the delegated nameservers are still expected, important A, AAAA, CNAME, MX, and TXT records still serve the intended values, and old records are removed after migrations. Include DNS checks in broader hosting and security reviews rather than waiting for an outage. The DNS records reference can help identify the purpose of each record, while the domain-to-hosting checklist covers the related SSL and hosting steps.
Before closing a DNS incident, confirm four things: the authoritative answer is correct, independent resolvers return the expected result, the real website or email service works, and the change is documented with a next review date. That distinction keeps you from treating every delay as propagation—and helps you find the configuration errors that waiting cannot fix.
