What this symptom usually tells you
Working email proves only that the MX path is usable. Browsers depend primarily on A/AAAA/CNAME, HTTP, TLS and hosting configuration, so a domain can receive mail while the website has no address record, a wrong server target, an invalid certificate or an application 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 business-email DNS and mail authentication diagnosis rather than as a standalone health score.
- Check web DNS — Verify check web DNS from the public Internet and compare it with the value the responsible provider says should be live.
- Check HTTP/HTTPS — Record the public status, final URL and relevant response headers. A working DNS answer does not prove that the application is serving a genuine website response.
- Preserve working MX — Read the public MX priorities and targets, then verify that each target itself resolves. A visible MX record is not enough if its mail hostname is broken.
Record the current state before editing
Before changing business-email DNS and mail authentication settings, save the exact public values for check web DNS, check HTTP/HTTPS, preserve working MX 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
Preserve the working MX and mail-authentication records. Investigate the web hostnames separately: resolve root/www, compare A and AAAA, test HTTP/HTTPS and follow redirects. Repair the first failed web layer rather than modifying mail configuration that is already healthy.
How to confirm this specific repair
The website should resolve and complete HTTPS while the MX/provider result remains unchanged. Re-running the combined health check is useful here because it confirms that fixing the web path did not disturb the already-working mail path.
A common wrong turn
Do not use a provider’s “reset DNS zone” option just to restore a website. Resetting can erase the healthy mail configuration that demonstrates why the incident is web-specific.
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 business-email DNS and mail authentication 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.