What this symptom usually tells you
When www works but the bare domain fails, the apex usually lacks a usable A/AAAA/ALIAS target, is not attached to the hosting project, or presents a certificate that does not cover the root hostname. DNS providers also differ in how they support CNAME-like behavior at the zone apex.
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 apex A/ALIAS — Verify check apex A/ALIAS from the public Internet and compare it with the value the responsible provider says should be live.
- Check certificate — Test the hostname actually requested, its certificate dates and SAN coverage, and the TLS handshake. Root and www can serve different certificates.
- Check canonical redirect — Follow every hop rather than checking only the final page. The conflicting rule is usually visible where the chain changes scheme, hostname or destination repeatedly.
Record the current state before editing
Before changing TLS, certificate and HTTPS settings, save the exact public values for check apex A/ALIAS, check certificate, check canonical redirect 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
Use the hosting provider’s documented apex record rather than copying the www CNAME blindly. Attach the root hostname to the application, obtain certificate coverage, then configure the desired root-to-www redirect if www is canonical. Preserve working www and mail records during the change.
How to confirm this specific repair
The root hostname should resolve, complete HTTPS and either serve the site or redirect once to www. Check the certificate presented on the root before the redirect and verify that the final www destination remains healthy.
A common wrong turn
Do not place an ordinary CNAME at the apex if the DNS provider/platform does not support it appropriately. A seemingly simple DNS shortcut can conflict with other zone data or fail provider validation.
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.