Domain Health checker.

One domain health check across everything a domain needs to get right: DNS, the SSL/TLS certificate, the HTTP front door and email authentication. Four real checks run in parallel from this server, graded, with every finding explained and a link into the full tool for the detail.

About this check

Domain Health runs the four server-side tools on this site against one domain at the same time and condenses each into a grade and its most important findings. It is the check to run after a DNS change, a certificate renewal, a migration to a new host or mail provider, or when someone says "the site seems off". Nothing is stored; run it again whenever you like.

What it checks

PillarFindingsFull tool
DNSA and AAAA records at the apex, nameserver count, CAA. Real queries to Cloudflare's resolver, so a propagating change shows as it is right now.DNS lookup
SSL/TLSChain trust and missing intermediates, hostname match, days to expiry, TLS 1.3 support, legacy TLS 1.0/1.1 still enabled, OCSP stapling. From a live handshake, not a certificate transparency search.SSL certificate checker
HTTPWhether http:// redirects to https:// and with which code, redirect chain length, final status, HTTP/2, compression, and the security header grade from the HTTP checker.HTTP header & redirect checker
EmailMX and STARTTLS, SPF with the 10-lookup count, DMARC policy, DKIM keys under common selectors, MTA-STS, TLS-RPT and BIMI. The email checker's own findings, condensed.Email deliverability checker

How the grade works

Each pillar is graded on its own findings: A is clean, B has a warning or two, C is warnings only, D has one failure and F more than one. The overall grade applies the same rule across every finding. A domain that sends no mail and says so with a null MX is graded on what it does publish, so it is not penalised for the absence of SPF or DKIM. Info findings never affect the grade.

What makes this domain health check different

Most domain checkers read records and compare them to a list. This one connects. The TLS pillar is a live handshake, so it sees the chain the server actually sends (including a missing intermediate that a browser would quietly paper over), whether OCSP is stapled, and probes TLS 1.0 through 1.3 one version at a time rather than inferring support. The email pillar opens a session to every MX to confirm STARTTLS and check the certificate on port 25, expands SPF recursively and counts the DNS lookups the way a receiver does, and reads MTA-STS, TLS-RPT and BIMI, which most checkers skip. The HTTP pillar follows the redirect chain hop by hop and grades the security headers on the final response. And the whole report is available as text or JSON, so the same check can run from a shell or a CI step.

What it does not do, so you know: it does not check the registration (WHOIS or RDAP expiry), and it does not query blacklists or reputation feeds. Those are useful, and they are on the list, but they are not network behaviour, which is what this check is for.

What to do with the result

From the command line

curl "kirkdiamond.com/domain-health?domain=example.com" prints the same report as text; add &format=json for the structured version, which is the shape a monitor or a CI step would consume. Only public domains can be checked and the check is rate limited per visitor.

Every parameter, the JSON field names, rate limits and ready-made CI checks are in the API and curl reference.