Domain Health Check

What “domain health” actually covers

Domain health isn’t one thing. It’s three layers stacked on top of each other, and a problem in any of them shows up as a different symptom. The bottom layer is resolution: can the world turn your name into an address? The middle layer is mail authentication: when your domain sends email, can the receiving server prove it was really you? The top layer is transport security: does the TLS certificate check out so browsers and mail servers don’t throw warnings?

Most “my site is fine but emails go to spam” problems live in the middle layer, and that’s exactly where people don’t look, because the website loads fine. A health check exists to surface all three at once so you’re not debugging one record while a different one is the actual cause.

DNS: does the name resolve, and to where

The scan pulls your A records (the IPv4 addresses the domain points at) and your NS records (the nameservers that answer for the zone). No A record means the domain doesn’t resolve at all — nothing else matters until that’s fixed. One nameserver is a single point of failure: if it goes down, your whole domain goes dark, which is why registrars and RFC 1034 practice expect at least two on separate infrastructure.

DNS also carries a TTL on every record — the number of seconds resolvers are allowed to cache it. A high TTL (say 86400, a full day) means a change you make today won’t be visible everywhere until tomorrow. That lag is “propagation,” and it’s why a record can look correct in your registrar’s panel but still resolve to the old value for hours.

Email authentication: SPF, DKIM, DMARC

These three records are what a receiving server uses to decide whether your mail is legitimate. SPF is a TXT record listing which servers are allowed to send for your domain. It has a hard limit that trips people constantly: a maximum of 10 DNS lookups during evaluation (RFC 7208 §4.6.4). Chain too many include: mechanisms — a common side effect of adding every SaaS vendor — and SPF returns permerror, which many receivers treat as a fail.

DKIM signs each message with a private key; the receiver fetches the matching public key from your DNS and verifies the signature, proving the body wasn’t altered in transit. DMARC ties SPF and DKIM together and tells receivers what to do when a message fails both: p=none means “do nothing, just report,” p=quarantine means “send it to spam,” p=reject means “bounce it.” A domain sitting on p=none is publishing a policy that protects nobody — it’s monitoring only.

Since February 2024, Google and Yahoo require bulk senders (roughly 5,000+ messages a day to their users) to have SPF, DKIM, and a DMARC record, or the mail gets throttled or rejected. That single change turned “nice to have” email auth into a hard requirement, and it’s the reason a domain that sent fine last year can suddenly see deliverability collapse.

TLS: the certificate and its clock

The scan connects on 443 and reads the certificate the way a browser would: is it valid for this hostname, who issued it, and how many days until it expires. An expired certificate is the loudest failure on this list — browsers replace your page with a full-screen warning, and mail servers negotiating STARTTLS may refuse the connection.

The common trap is automation that quietly stops. Let’s Encrypt certs last 90 days and are meant to auto-renew; when the renewal cron dies, nobody notices until the 90 days run out. That’s why the check reports the exact days remaining rather than a simple valid/invalid — a cert with 6 days left is technically valid and about to become an outage.