A domain isn't one thing. It's a registration record at a registrar, a set of DNS records pointing at servers, a TLS certificate, an HTTP layer that decides how requests get routed, and a handful of security headers that most people never see. Each of those lives in a different place, and any one of them failing can take a site or its email down. Checking them by hand means jumping between five tools and remembering what "healthy" looks like for each.
The Domain Health Check runs all of those checks at once. You give it a domain, and it reports back on registration status, DNS routing, HTTPS enforcement, and security headers in a single pass - the fragmented picture pulled into one place.
What "healthy" means here
A healthy domain is registered and locked, routed to servers that actually answer, served over HTTPS with a valid certificate, and configured so that browsers can't be tricked into an unencrypted connection. When one of those slips, the failure is rarely subtle. An expired certificate throws a full-screen browser warning and conversions stop. A registration that lapses because the WHOIS contact email was stale can be grabbed by someone else within days. A missing security header leaves a narrow window an attacker on shared Wi-Fi can use.
The point of the scan is to catch these while they're still cheap to fix, not after the support tickets start.
Registration and ownership
The first thing the check does is pull WHOIS data: the registrar, the creation date, and - the one that matters most - the expiration date. Plenty of high-profile outages trace back to nobody renewing a domain on time, so seeing the expiry timeline up front works as an early warning.
It's also worth confirming two things WHOIS reveals:
- The domain is locked at the registrar, which blocks unauthorized transfers.
- The nameservers listed in WHOIS match the ones actually answering queries. A mismatch is a "lame delegation," and it makes DNS behave unpredictably.
The DNS foundation
Next the tool looks at the records that decide where traffic and mail go. It checks that A and AAAA records resolve to valid IPv4 and IPv6 destinations, and that MX records exist so email has somewhere to land. You can see the full record set any time with the All DNS Records lookup.
A couple of things it flags that are easy to miss:
| Check | Why it matters |
|---|---|
| Single nameserver | One NS record is a single point of failure - lose it and the whole zone goes dark |
SOA timers |
Refresh, retry, and expire values that are set too aggressively or too loosely cause caching problems |
If you want to go deeper on the zone's integrity, a DNSSEC check tells you whether the records are cryptographically signed against tampering.
Web connectivity and HTTPS
Plain HTTP is done - search engines rank it lower and browsers actively warn against it. So the check makes a real connection and asks a few direct questions. Does the domain answer on port 443? Does a request to http:// get a 301 permanent redirect to https://, or does it just sit on the insecure version?
This is where the HTTP/HTTPS check earns its place. Redirect logic breaks constantly during host migrations and certificate swaps - you'll see missing redirects, redirects that point at the wrong host, and the occasional redirect loop where the server bounces a request back and forth until the browser gives up.
Security headers, starting with HSTS
Redirecting HTTP to HTTPS is a good start, but it isn't the whole story. There's a moment during that very first connection - before the redirect fires - where someone on the same network can strip the encryption out. That's a downgrade attack, and it's exactly what the HSTS check guards against.
HSTS (HTTP Strict Transport Security) tells the browser to never even attempt an unencrypted connection to your domain again. The health check looks at three things:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
- Is the header present at all?
- Is
max-ageset to a meaningful duration (a year,31536000seconds, is common)? - Does
includeSubDomainsextend the protection towwwand everything else under the domain?
A real audit, start to finish
Say an IT firm takes on a business that was just acquired. No documentation, no idea where the domain is registered, no record of how any of it was configured. The fastest first move is to run the domain through the health check.
A few seconds later the report shows the domain expires in three days, the site has no HSTS header, and DNS still points at the previous owner's nameservers. That's not a diagnosis you'd want to assemble by hand under time pressure - and it becomes the to-do list for the whole handover.
The short version
The value of a single health check is that it stitches together things you'd otherwise inspect separately: registration status, DNS routing, HTTPS enforcement, and security headers. Run it when you inherit a domain, right after a migration to confirm everything landed, or on a schedule so an expiry or a dropped header never catches you off guard. It won't fix anything for you, but it'll tell you exactly what needs fixing before someone else notices first.