What this symptom usually tells you
The root domain and www are separate hostnames. A healthy apex A/ALIAS record does not automatically create www, and the hosting platform may require www to be attached explicitly. HTTPS can also fail only on www when the certificate SAN does not cover it.
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 TLS, certificate and HTTPS diagnosis rather than as a standalone health score.
- Check www DNS — Verify check www DNS from the public Internet and compare it with the value the responsible provider says should be live.
- Check certificate SAN — Test the hostname actually requested, its certificate dates and SAN coverage, and the TLS handshake. Root and www can serve different certificates.
- Check platform domain assignment — Verify check platform domain assignment 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 TLS, certificate and HTTPS settings, save the exact public values for check www DNS, check certificate SAN, check platform domain assignment 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
Look up www directly. Add or correct the provider-recommended CNAME/A record, attach www to the same project where required, and ensure the certificate covers www before enforcing a redirect. Choose one canonical hostname only after both variants can establish HTTPS safely.
How to confirm this specific repair
Request https://www.example.com directly and inspect its DNS, certificate and redirect chain. It should either serve the intended site or make one deliberate redirect to the canonical root hostname. The redirect must occur after a valid TLS handshake for www.
A common wrong turn
A redirect rule cannot rescue a hostname that has no DNS record or no valid certificate, because the browser must resolve and establish the initial connection before it can receive the redirect.
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 TLS, certificate and HTTPS 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.