Domain Health Report
Enter a domain and get one graded report covering everything that decides whether it is healthy on the public internet: DNS, DNSSEC, email authentication, SSL/TLS, HTTP security headers, blacklist reputation and performance. Every category is graded A+ to F, and the most important fixes are listed first.
What is a domain health report?
A domain health report is a single graded assessment of how well a domain is configured across the seven areas that determine whether it is secure, reachable, and trusted: DNS resolution, DNSSEC, email authentication, the TLS certificate, HTTP security headers, IP reputation, and performance. Instead of running seven separate tools, this report runs them together against the domain you enter and rolls the results into one weighted A+ to F grade, with the highest-impact fixes listed first.
The overall grade is a weighted average of the category sub-grades. Categories that cannot be reached at check time (for example, a site that blocks our request) are excluded from the average rather than scored as zero, so a single unreachable check never unfairly drags the grade down.
What each category measures, why it matters, and how to fix it
DNS - does the domain resolve correctly?
DNS is the address book of the internet. The report checks the apex A/AAAA address records, the NS nameservers, the SOA zone-of-authority record, MX mail exchangers, TXT records, and CAA records. Missing nameservers mean the domain will not resolve at all; a single nameserver is a single point of failure. Most registries require at least two NS records (RFC 1034). A CAA record (RFC 8659) restricts which certificate authorities may issue certificates for your domain, reducing the risk of mis-issuance.
DNSSEC - can DNS answers be trusted?
DNSSEC (RFC 4033–4035) cryptographically signs DNS records so a resolver can detect tampering, spoofing, and cache poisoning. The report looks for DNSKEY records (the zone is signed) and confirms the AD (Authenticated Data) bit set by a validating resolver, which proves the chain of trust validates up to the root. A signed-but-not-validating zone usually means the DS record at your registrar is missing or wrong - fix it there to complete the chain.
Email authentication - will your mail be trusted?
Inbox placement is governed by DNS records that receivers read before accepting mail. The report reuses our email scorecard to grade MX, SPF (RFC 7208, the allowed senders list and its all qualifier), DKIM (RFC 6376, the signing public key), and DMARC (RFC 7489, the enforcement policy and reporting). It also checks the modern channel-security records: MTA-STS (RFC 8461), TLS-RPT (RFC 8460), and BIMI. The strongest posture is SPF ending in -all, an active DKIM key, and DMARC at p=reject with aggregate reporting.
SSL/TLS - is the certificate valid?
The report opens a TLS connection to port 443 and inspects the leaf certificate: how many days remain before expiry, whether the certificate actually covers the hostname (Common Name and Subject Alternative Names), the signature algorithm (SHA-1 and MD5 are distrusted), and whether the server sent the full chain. An expired certificate or a hostname mismatch produces a full-page browser error and blocks every visitor, so these are treated as critical.
Security headers - is the browser protected?
HTTP response headers tell the browser how to defend the user. The report reuses our header grader to check Strict-Transport-Security (RFC 6797, forces HTTPS), Content-Security-Policy (the strongest defence against XSS), X-Content-Type-Options, clickjacking protection via X-Frame-Options or CSP frame-ancestors, Referrer-Policy, and Permissions-Policy. It also flags information-disclosure headers such as Server and X-Powered-By.
Blacklist & performance - reputation and speed
Even with perfect authentication, a sending IP that is listed on a blocklist (Spamhaus, SpamCop, Barracuda) gets mail throttled or rejected; the report reuses the reputation result from the email check for the primary mail IP. Performance is measured by fetching the homepage over HTTPS and recording the full response time, the HTML transfer size, and whether the response is compressed - signals adjacent to Core Web Vitals (LCP/TTFB) that also affect search rankings.
How is the overall grade calculated?
Each category is scored 0–100 and converted to a letter (A+ ≥ 95, A ≥ 90, B ≥ 80, C ≥ 70, D ≥ 60, otherwise F). The overall score is a weighted average that emphasises the signals with the broadest impact - email authentication and SSL/TLS carry the most weight, followed by DNS and security headers, then DNSSEC, blacklist reputation, and performance. Because unreachable categories are excluded and the remaining weights are renormalised, the overall grade always reflects only what was actually measured.
How often should I run a domain health report?
Run it whenever you change DNS, rotate a certificate, migrate mail providers, or deploy a new site - and on a recurring schedule (monthly is reasonable) to catch silent regressions such as an expiring certificate, a DMARC policy that slipped back to p=none, or a blacklist listing from a compromised account. Each category links to a focused tool so you can drill into any finding in depth.
Domain health report FAQ
Is this domain health report free, and is my domain stored?
Yes, it is free and requires no sign-up. Every check runs live against public DNS and the domain's public endpoints at the moment you submit it. We do not store the domains you check server-side; results are cached only briefly (about 15 minutes) so that reloading or sharing a report link is fast and does not re-run every network check.
Why is one category shown as "could not check" with an N/A grade?
A category degrades to "could not check" when its endpoint was unreachable within the time budget - for example, a site that blocks automated requests, a server with no service on port 443, or a homepage that times out. To keep the overall grade fair, any category that could not run is excluded from the weighted average rather than counted as zero, so a single unreachable check never unfairly lowers your grade.
My domain has no email. Why does it still grade email authentication?
The email category checks the records that control mail for the domain (MX, SPF, DKIM, DMARC). If the domain is not meant to send or receive mail, the strongest configuration is an explicit "null MX" record plus an SPF record of v=spf1 -all and a DMARC policy of p=reject. Those records tell the world that no legitimate mail comes from the domain, which stops attackers from spoofing it.
Does a perfect grade mean my domain is fully secure?
No. This report measures configuration health at the DNS, transport, and edge layers - it is a strong baseline, but it does not test your application code, authentication flows, content, or server patching. Treat an A+ as "the public-facing fundamentals are correct," then continue with application-level security testing, dependency patching, and monitoring.
How is the overall letter grade decided?
Each category produces a 0–100 score that maps to a letter (A+ ≥ 95, A ≥ 90, B ≥ 80, C ≥ 70, D ≥ 60, otherwise F). The overall grade is the weighted average of the categories that ran, with email authentication and SSL/TLS weighted most heavily, then DNS and security headers, then DNSSEC, blacklist reputation, and performance. The "What to fix first" list orders every recommendation by severity (critical, then high, medium, and low) across all categories.
What is the difference between DNSSEC being "signed" and "validating"?
"Signed" means your zone publishes DNSKEY records, so the data carries cryptographic signatures. "Validating" means a resolver can follow the chain of trust from the root down to your zone and confirm those signatures, which it signals with the AD (Authenticated Data) bit. A zone can be signed but fail to validate if the DS record at your registrar is missing or wrong - in that case the protection does not actually take effect until you fix the DS delegation.
How this tool works: This tool runs in your browser and on our server in real time. Depending on the tool, results are computed directly from the input you provide or retrieved from live, authoritative data sources at the moment you run a lookup. We do not sell your data, and your lookups are kept private — any history shown here is stored only on your device.