Website Health: what this section covers
Website Health is the cross-layer starting point for a failure that has not yet been isolated. It compares whether the domain resolves, whether both HTTP and HTTPS respond, whether root and www agree, whether the certificate is usable, whether mail DNS still exists and whether crawler-facing directives accidentally block the site.
Signals that matter for website troubleshooting
The pages here interpret business-email DNS and mail authentication evidence through the following search tasks and configuration concepts. They are included because they help separate causes, not to repeat a keyword a fixed number of times.
- Website health — Verify website health from the public Internet and compare it with the value the responsible provider says should be live.
- Website diagnostics — Verify website diagnostics from the public Internet and compare it with the value the responsible provider says should be live.
- Website troubleshooting — Verify website troubleshooting from the public Internet and compare it with the value the responsible provider says should be live.
Which Website Health check to start with
Use the combined check when several symptoms appeared together after a migration, nameserver change or provider move. If the scan isolates one failing layer, switch to the focused DNS, SSL, HTTP or email tool so the repair can be verified without repeatedly running unrelated tests.
Diagnosis first, raw evidence second
The interface surfaces the highest-impact explanation and its confidence before raw protocol output. For website troubleshooting, that means a visitor can see what probably failed and what to change while an advanced user can still inspect the DNS, certificate, header, resolver or provider evidence behind the conclusion.
What a repaired website troubleshooting problem should look like
A healthy outcome is not a score. It is a set of compatible public signals: the intended website endpoints answer, HTTPS works on the hostnames visitors use, mail still routes to the intended provider and no higher-severity finding explains the reported failure.
Validate the business-email DNS and mail authentication change
The public MX/authentication records should match the intended mail provider, required hostnames should resolve, and the relevant SPF/DKIM/DMARC check should no longer show the original failure. Re-run the same focused tool that exposed the problem so a dashboard status, cache or unrelated healthy signal is not mistaken for proof of the repair.
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.