What this symptom usually tells you
If the authoritative web record is already new but the old site still appears, first determine whether the failing client is using a cached address or a different record type. AAAA is a frequent cause because it can remain pointed at the former server while the more obvious A record has been changed.
Evidence that narrows the cause
Use the live diagnostic to test the exact hostname involved. For this problem, the highest-value evidence is below. Treat each result as one piece of the DNS resolution and delegation diagnosis rather than as a standalone health score.
- Compare A and AAAA — Compare IPv4 and IPv6 separately. A healthy A record can hide a broken AAAA path that affects only visitors whose network prefers IPv6.
- Check TTL — Compare independent resolvers or regional probes together with TTL. Different answers are evidence of cache/authority differences, not a reason to claim a fixed global propagation time.
- Query multiple regions — Verify query multiple regions from the public Internet and compare it with the value the responsible provider says should be live.
Record the current state before editing
Before changing DNS resolution and delegation settings, save the exact public values for compare A and AAAA, check TTL, query multiple regions and note which hostname or mail path is failing. This creates a rollback point and prevents a later resolver cache, provider dashboard or unrelated working record from being mistaken for the original cause. Change one evidence-backed setting at a time, then compare the same signals again.
Safest repair path
Query the authoritative A, AAAA and CNAME data and compare those answers with the resolver used by the affected network. Correct any stale authoritative record. If authority is already correct, stop editing DNS and allow caches created under the prior TTL to expire.
How to confirm this specific repair
The affected resolver should eventually return the same intended endpoint as authoritative DNS. Test the actual connection after resolution; a browser or CDN cache can preserve old content even after DNS has converged, which is a separate layer from DNS propagation.
A common wrong turn
“Propagation” should not be used as a blanket explanation. If authoritative servers disagree with each other, the source DNS itself is inconsistent and waiting on recursive caches will not repair it.
When to escalate with evidence
If these public checks match the provider's current documented configuration but the service still fails, give support the exact hostname, the observed DNS resolution and delegation result, a timestamp, and the failing network or message path. That separates a provider-side incident from a DNS change that has not actually become authoritative.
Technical references
These primary standards and provider documents are used to verify the behavior described on this page. Provider dashboards can change, so use the current official value for tenant-specific DNS records rather than copying an example from another account.