What this symptom usually tells you
A site that works for one visitor but not another usually needs comparison across network paths rather than another application deployment. Different recursive resolvers can hold different cached answers, and IPv6-capable networks can use an AAAA endpoint that IPv4-only networks never touch. Regional routing or a CDN edge can also expose a location-specific failure.
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 regional DNS — 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.
- Check broken 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 resolver consistency — 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.
Record the current state before editing
Before changing DNS resolution and delegation settings, save the exact public values for compare regional DNS, check broken AAAA, check resolver consistency 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
Compare authoritative DNS with several independent resolvers and inspect A and AAAA separately. If one endpoint is stale or unreachable, repair that record or server path rather than changing every DNS value. If DNS is identical everywhere, move the investigation to the CDN, firewall or hosting provider with the affected region/network evidence.
How to confirm this specific repair
Retest from at least two distinct networks and compare the exact resolved IP family, final URL and status. A real fix is visible to the previously failing network without requiring local hosts-file overrides or repeated browser cache clearing.
A common wrong turn
Clearing your own browser cache proves very little about another visitor’s resolver or IPv6 path. Do not disable IPv6 globally just because one AAAA test fails; first determine whether that record is intentional and whether the corresponding server should be reachable.
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.