What this symptom usually tells you
Wi-Fi and mobile data commonly use different DNS resolvers and may prefer different IP families. A home connection can reach the IPv4 A record while the mobile carrier selects a broken AAAA record, or one resolver can retain an older address while the other already uses the new authoritative answer.
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 resolver answers — 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.
- Test IPv6 — 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 and authoritative data — Query the authoritative servers directly and compare their answers. This separates a stale recursive cache from inconsistent source DNS data.
Record the current state before editing
Before changing DNS resolution and delegation settings, save the exact public values for compare resolver answers, test IPv6, check TTL and authoritative data 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
Record the A and AAAA answers seen through both paths, then query authoritative DNS to establish the source-of-truth value. Repair an incorrect or unreachable AAAA endpoint if IPv6 is the differentiator. If only resolver caches differ, leave correct authoritative DNS alone and wait for the previous TTL rather than making another change.
How to confirm this specific repair
Use the previously failing mobile network after the authoritative data is correct. Confirm that its resolver returns the intended address and that the selected IPv4/IPv6 endpoint completes HTTPS. The same hostname should reach the same intended site on Wi-Fi and mobile data even if the networks use different resolvers.
A common wrong turn
Repeated DNS edits reset the troubleshooting clock and can create a second inconsistency. Avoid assuming that “mobile data” itself is blocking the site until the returned DNS answer, IP family and connection result have been compared.
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.