Domain Health Checks Explained: What One Report Tells You

A domain looks like one thing — a name you type into a browser — but it's quietly held together by half a dozen unrelated systems. The DNS that points the name at a server. The records that let your mail be trusted. The certificate that turns the padlock green. The registration that proves you still own it. Each is configured separately, breaks separately, and is usually checked separately. That's exactly why problems hide: the certificate can be perfect while your email silently fails authentication, and nothing on the website itself will tell you.

A domain health check is the habit of looking at all of those systems together, in one pass, so the gaps show up. It doesn't add any new magic — it just collects the answers the internet already gives you and lines them up side by side. Our domain health report does this in a single query, but the value is in knowing what each section means and what a healthy answer looks like. So let's walk through the five things worth checking on any domain.

1. DNS records: where the domain actually lives#

Everything starts with DNS — the system that translates a name into the addresses and routing information machines need. If the DNS is wrong, nothing downstream matters, because traffic never reaches the right place. A health check looks at the core record types: the A and AAAA records that map the name to IPv4 and IPv6 addresses, the MX records that say which servers accept the domain's mail, the NS records that name the authoritative nameservers, the TXT records that carry policies like SPF, and the SOA record that holds the zone's administrative metadata.

Reading these together answers basic but important questions. Does the domain resolve at all? Is it reachable over IPv6, or only IPv4? Is mail pointed at the provider you think it is, or at a service you stopped using two years ago? If you want to go deeper on any single record type, our guide to DNS record types breaks down each one, and the standalone DNS records lookup queries them live. A health check's job here is breadth: confirm the foundation is present and pointed where you expect.

2. Email authentication: SPF, DKIM, and DMARC#

This is the section most domains fail, and the one that costs the most when it's wrong. Three records work together to prove that mail claiming to come from your domain really does:

• SPF lists which servers are allowed to send mail for the domain. A health check confirms the record exists, parses cleanly, and stays under the hard limit of 10 DNS lookups — past which SPF simply stops working.
• DKIM adds a cryptographic signature to each message so the receiver can verify it wasn't altered in transit. Because DKIM lives under a per-sender selector, a naive check often reports "not found" when the record is really there; a good check probes the common selectors used by Google, Microsoft, and the major sending platforms before drawing a conclusion.
• DMARC ties the other two together and tells receivers what to do when a message fails — nothing, quarantine, or reject — plus where to send aggregate reports. A health check surfaces the policy and the reporting address.

Why does this matter so much now? Because Gmail and Yahoo began requiring DMARC for bulk senders, and a domain with no authentication increasingly lands in spam or gets refused outright. If all three look healthy together, your mail has earned the right to be trusted; if one is missing, that's almost always where to start. Our DMARC explainer covers how the three records reinforce each other.

3. DNSSEC: is the chain of trust intact?#

Plain DNS answers aren't signed, which means a resolver can be tricked into accepting a forged response and quietly sending users to the wrong server. DNSSEC fixes that by cryptographically signing DNS records, building a chain of trust from the root zone down to your domain. A health check reports the headline status — secure, insecure, or broken — by looking for the DS record at the parent zone, the DNSKEY record at the domain, and the authenticated-data signal from a validating resolver.

Here's the honest part: most domains still don't have DNSSEC, and that isn't a failure so much as a missing optional layer — so a health check should report "not enabled" plainly rather than scoring it as broken. What you do want to catch is a misconfigured chain, where a DS record exists but the signatures don't validate. That state — sometimes called bogus — can make a domain unreachable for everyone using a validating resolver, and it's exactly the kind of silent break a one-shot report is built to surface. Our DNSSEC explainer walks the full chain step by step.

4. SSL/TLS certificate: the padlock and its expiry#

The certificate is what lets browsers encrypt the connection and confirm they're talking to the real server. A health check pulls the certificate currently served on port 443 and reports the essentials: who issued it, the validity window, how many days are left before it expires, and which hostnames it actually covers in its subject-alternative-name list.

Two failure modes dominate, and both are mundane. The first is expiry — a certificate that lapsed because an automated renewal quietly stopped working, which throws a full-page browser warning and stops most visitors cold. The second is coverage: a certificate valid for example.com but not www.example.com, so half your visitors hit a name-mismatch error. Certificate lifetimes keep getting shorter — the industry is moving toward renewals measured in weeks — which makes a regular expiry check more valuable, not less. For the full picture of how certificates establish trust, see how SSL certificates work, or run the dedicated SSL inspector for a graded report on one domain.

5. WHOIS: who owns it and when does it expire?#

The last section steps back from the technical plumbing to the registration itself. WHOIS — increasingly served by its modern replacement, RDAP — reports the registrar, the creation and expiry dates, the domain's age, and the authoritative nameservers on record. The single most useful field here is the expiry date: an expired domain doesn't degrade gracefully, it vanishes, taking the website and the email with it. More than one well-run company has lost its domain not to an attacker but to a lapsed auto-renewal on a credit card nobody updated.

The nameservers in WHOIS are worth a glance too, because they should match what's actually answering DNS queries. A mismatch — registrar pointing one way, live DNS another — is a classic symptom of a half-finished migration. If you want the background on what this record can and can't tell you since privacy rules redacted much of it, our WHOIS explainer covers it.

Why "one health score" is the wrong idea#

It's tempting to want a single grade — a green "A" or a number out of 100 — for a whole domain. Resist it. These five systems answer different questions for different audiences: DNSSEC matters to resolvers, SPF and DMARC matter to mail providers, the certificate matters to browsers, WHOIS matters to you. Averaging them into one figure hides the thing you actually need, which is which section is failing. A domain with a flawless certificate and broken DMARC isn't "80% healthy" — it has a specific, fixable email problem, and a blended score buries it.

That's why a good report labels each section with its own honest status — OK, warning, fail, or simply unavailable when a source can't be reached — rather than rolling everything into one verdict. "Unavailable" is its own useful answer: it means the check couldn't complete, not that the domain passed, and pretending otherwise would be the worst kind of false comfort.

A domain doesn't have one health. It has five, and the useful report is the one that refuses to average them.

What to fix first#

When a report comes back with more than one problem, triage in order of blast radius. WHOIS expiry and a lapsed certificate are emergencies — they take the whole domain down — so they come first. A bogus DNSSEC chain is next, because it can make the domain unresolvable for a large slice of users. Email authentication follows: missing SPF, DKIM, or DMARC won't break the website but will quietly erode deliverability, and Google's and Yahoo's requirements make it less optional every year. Missing DNSSEC on a domain that never had it is the lowest priority — a worthwhile upgrade, not a fire.

The point of checking everything at once isn't to fix everything at once. It's to see the whole board, so you spend your time on the section that's actually on fire instead of the one that happened to be in the tab you opened first.