Public Netlify evidence we can test
Netlify is relevant here for custom domains, Netlify DNS, external DNS and HTTPS provisioning. The scanner does not sign in to the account; it compares the public-facing configuration associated with Domain management, Netlify DNS, external DNS, HTTPS so a provider dashboard and the Internet-visible result can be checked against one another.
- Domain management — Verify Domain management from the public Internet and compare it with the value the responsible provider says should be live.
- Netlify DNS — Verify Netlify DNS from the public Internet and compare it with the value the responsible provider says should be live.
- External DNS — Verify external DNS from the public Internet and compare it with the value the responsible provider says should be live.
- 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.
Where Netlify changes normally belong
Netlify Domain management/DNS together with the external registrar or DNS provider when Netlify DNS is not authoritative. Before editing that area, verify that Netlify actually controls the failing layer; a domain may use a different company for authoritative DNS, mail or the origin application.
How to interpret Netlify detection
Domain management and Netlify DNS can support a Netlify identification, but signatures are confidence-weighted. If the visible address belongs to a CDN/reverse proxy, the edge provider is reported as the edge and the hidden origin is not guessed. Mail-provider signatures likewise identify public routing, not private account ownership.
Common Netlify change points
custom domains, Netlify DNS, external DNS and HTTPS provisioning most often breaks after a domain connection, nameserver move, website migration, certificate/HTTPS change or mail-DNS edit. For this provider, compare Domain management, Netlify DNS, external DNS with the value expected for the exact domain and account before replacing a working setting elsewhere.
Repair Netlify without widening the incident
Save the current public value, change only the setting tied to the diagnosis, and preserve unrelated working records. If DNS is not authoritative at Netlify, make the DNS edit at the provider named by the active nameservers. If Netlify owns only hosting or mail, leave the other service layers where they are.
Verify the Netlify repair
HTTPS should complete for the exact hostname, the certificate should be valid for that hostname, and root/www should follow the intended canonical redirect without a TLS error. The verification should use the exact hostname/service repaired and should no longer depend on a control-panel “connected” indicator once the public check is available.
What a public scan cannot see inside Netlify
Billing state, private support actions, unpublished incidents, private origin addresses and authenticated account settings are outside a public diagnostic. HostWithShery reports those areas as unknown or a next support step instead of manufacturing certainty from a weak Netlify signature.
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.