Everything about one domain, on one page.
Enter a domain. We orchestrate our own checkers — DNS records, SPF / DKIM / DMARC, DNSSEC, SSL/TLS certificate, WHOIS — concurrently, with per-source attribution. Each section degrades gracefully if any one source is slow or unavailable.
Six signals, one screen.
Every check reuses an existing tool's endpoint, so the same caching, upstream caps, and origin guards protect this page automatically. For a single deep-dive on any section, use the linked tool directly.
What a domain health check actually covers
A domain is not one system. It is a name in the DNS, a set of mail-authentication policies published as TXT records, an optional chain of DNSSEC signatures, a TLS certificate issued by some certificate authority, and a registration record held by a registrar. Each of those is maintained separately, often by different people or different vendors, and each fails in its own way. A domain can resolve perfectly while its mail is being spoofed, or send properly authenticated mail while its certificate runs down to expiry unnoticed.
This page pulls all of them into one view, so you can see the whole surface at once instead of opening six tools and holding the results in your head.
How the report is assembled
Every section is produced by a checker that already exists on this site, called server-side and in parallel:
- DNS records come from the same resolver path as the DNS lookup: A, AAAA, MX, NS, TXT and SOA.
- SPF, DKIM and DMARC come from the SPF, DKIM and DMARC checkers. DKIM has no discovery mechanism in the protocol, so when you don't supply a selector the checker probes the selectors the large providers actually use: Google Workspace, Microsoft 365, Amazon SES, SendGrid, Mailgun, Mailchimp, Zoho, Postmark, HubSpot, Salesforce, Proofpoint, Fastmail, Cloudflare and others. That avoids the false “no DKIM found” a single-guess check produces.
- DNSSEC is read from Cloudflare's DoH resolver: the AD (Authenticated Data) flag for the headline status, plus whether a DS record exists at the parent zone and a DNSKEY at the domain.
- SSL/TLS comes from the SSL checker: issuer, validity window, days remaining, and the names the certificate covers.
- WHOIS comes from the WHOIS tool, over RDAP.
Because each section is its own call, one slow upstream cannot stall the page. A check that fails is labelled unavailable and everything else still renders.
Reading the result
Suppose a domain comes back as: DNS OK, email warning, DNSSEC not enabled, SSL OK, 41 days, WHOIS OK.
The email warning is the one to open first. It usually means SPF and DKIM are present but DMARC is either missing or published at p=none, which asks receivers to take no action on messages that fail authentication. That is the common half-configured state: the records exist, so the domain looks configured, but nothing is enforced. Anyone can still send mail claiming to be from that domain without it being rejected on authentication grounds.
DNSSEC showing “not enabled” is not a fault. Most domains do not sign, and signing is an operational choice with real costs. The report says what is true rather than what it wishes were true.
SSL at 41 days matters only if nothing is renewing it. If the certificate comes from Let's Encrypt through an automated client, 41 days is the middle of a normal cycle, not a warning.
Common questions
Does this send anything to the domain?
No. Every check reads public records: DNS queries through a public resolver, the certificate presented during a TLS handshake, and RDAP registration data. Nothing is scanned, brute-forced, or delivered to the domain's own services.
Why does DKIM say “not found” when we do sign our mail?
DKIM keys live at <selector>._domainkey.<domain>, and the selector is chosen by whoever set up sending. If yours is custom, no probe list will contain it. Run the DKIM checker directly with your selector, which you can read from the s= tag in the DKIM-Signature header of any message you have sent.
Is there a single health score?
No, deliberately. Collapsing independent systems into one number hides which one is broken. Each section carries its own status.
What does “unavailable” mean?
That check could not complete: an upstream timed out, or the data source does not cover that domain. It is not the same as a failure, and the report keeps the two distinct.
Limitations and honest caveats
- WHOIS is RDAP-only. A minority of legacy TLDs still publish registration data only over port-43 WHOIS. Those return no registration section here.
- DNS answers are resolver answers. You are seeing what a public resolver returns right now, which can lag a recent change or differ from what the authoritative server holds.
- A valid SPF record is not a complete one. Syntax validity means the record parses, not that it lists every service legitimately sending your mail.
- DNSSEC status is a chain check, not an audit. It confirms the chain resolves. It says nothing about how well the keys are managed.
- Certificates are checked on the apex. A subdomain can present a different certificate with a different expiry. Check those with the SSL checker directly.
Corrections welcome — see our editorial policy.