What this symptom usually tells you
A subdomain is an independent hostname. The root working does not imply that app.example.com, shop.example.com or another label has an A/AAAA/CNAME record, hosting assignment or certificate. Wildcards can cover some names, but explicit records and platform mappings can override or bypass them.
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.
- Lookup exact subdomain — Verify lookup exact subdomain from the public Internet and compare it with the value the responsible provider says should be live.
- Check wildcard use — Verify check wildcard use from the public Internet and compare it with the value the responsible provider says should be live.
- Check certificate/platform mapping — Test the hostname actually requested, its certificate dates and SAN coverage, and the TLS handshake. Root and www can serve different certificates.
Record the current state before editing
Before changing TLS, certificate and HTTPS settings, save the exact public values for lookup exact subdomain, check wildcard use, check certificate/platform mapping 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 exact failing subdomain rather than the root. Create the record required by the service, attach that exact hostname to the destination platform and provision certificate coverage. Use a wildcard only when the service genuinely needs one and the security/hosting model supports it.
How to confirm this specific repair
The exact subdomain should resolve publicly, complete HTTPS and return the expected application. Check that the certificate SAN covers the hostname and that no wildcard/default hosting rule sends it to an unrelated site.
A common wrong turn
Avoid adding a wildcard DNS record as a quick fix for one missing hostname. Wildcards can make mistyped or unintended names resolve and can mask configuration mistakes that should remain visible.
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.