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.

Health report for example.com

Overall score: 76/100 · Grade C

Overall 76/100 — critical issues in Email Authentication, Security Headers; improvements available in DNS, Performance.

Checked 2026-06-11 00:51 UTC. Categories that could not be reached are excluded from the grade.

What to fix first

high Email Authentication: DKIM: A DKIM record with "p=" and no key value is treated as revoked (RFC 6376 §3.6.1). Re-publish the active public key from your mail provider for the affected selector.
medium Email Authentication: MX Records: Confirm the A/AAAA record for your primary MX host (n/a) exists. An MX target must point at a hostname that has an address record — it must not point at an IP literal or a CNAME (RFC 5321 §5.1).
medium Email Authentication: DMARC: Add an rua= address so you receive daily aggregate reports — without them you cannot tell who is sending as you. Example: rua=mailto:[email protected]
medium Security Headers: Header Strict-Transport-Security: Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
medium Security Headers: Header Content-Security-Policy: Content-Security-Policy: default-src 'self'; object-src 'none'; frame-ancestors 'self'; base-uri 'self'
medium Security Headers: Header X-Content-Type-Options: X-Content-Type-Options: nosniff
medium Security Headers: Header X-Frame-Options / frame-ancestors: X-Frame-Options: SAMEORIGIN (or) Content-Security-Policy: frame-ancestors 'self'
medium Security Headers: Header Referrer-Policy: Referrer-Policy: strict-origin-when-cross-origin
medium Security Headers: Header Permissions-Policy: Permissions-Policy: geolocation=(), camera=(), microphone=()
low DNS: Publish a CAA record naming only your CA (RFC 8659), e.g. `example.com. IN CAA 0 issue "letsencrypt.org"`, to block mis-issuance by other authorities.
low Performance: Enable Brotli or gzip compression for text responses to cut transfer size substantially.

DNS Zone resolves with 2 nameserver(s). A+

NS records: 2 authoritative nameservers published.
A / AAAA: 2 IPv4 and 2 IPv6 address record(s). IPv4: 172.66.147.243, 104.20.23.154.
SOA: Primary NS elliott.ns.cloudflare.com, serial 2405749864.
MX: 1 mail exchanger(s) published.
CAA: No CAA record. Any public CA may issue a certificate for this domain.
TXT: 2 TXT record(s) at the apex (SPF and verification tokens live here).

Dig deeper with the DNS tool

DNSSEC DNSSEC is enabled and validating. A+

Zone signing: The zone publishes DNSKEY records and a validating resolver set the AD bit — DNSSEC is signed and the chain of trust validates.
Key count: 5 DNSKEY record(s) present.
DS delegation: 2 DS record(s) published at the parent — the secure delegation is complete.

Dig deeper with the DNSSEC tool

Email Authentication Score 72/100 — failing: DKIM; needs attention: MX Records, DMARC. C

MX Records: MX records exist but the primary host did not resolve to an IP.
SPF: Valid SPF record with a hard fail (-all) — strongest policy.
DKIM: DKIM selector(s) exist but contain a revoked (empty) public key.
DMARC: DMARC at full enforcement (p=reject).
MTA-STS: No MTA-STS policy — SMTP TLS is opportunistic and downgrade-attackable.
TLS-RPT: No TLS-RPT record — you will not receive SMTP TLS failure reports.

Dig deeper with the Email Authentication tool

SSL / TLS Valid certificate, 80 days remaining. A+

Expiry: Valid for 80 more day(s) (until 2026-08-29).
Hostname match: Certificate covers example.com.
Signature algorithm: ecdsa-with-SHA256.
Certificate chain: 4 certificates presented (leaf + intermediates).
Issuer: Issued by SSL Corporation.

Dig deeper with the SSL / TLS tool

Security Headers Security-header grade F (0/100). F

Strict-Transport-Security: Add this header to force browsers onto HTTPS and block protocol-downgrade attacks (RFC 6797).
Content-Security-Policy: Add a CSP to control which scripts/styles/frames may load — the strongest defence against XSS and injection (W3C CSP Level 3).
X-Content-Type-Options: Add this header so browsers do not MIME-sniff responses into an executable type.
X-Frame-Options / frame-ancestors: Add X-Frame-Options (RFC 7034) or a CSP frame-ancestors directive to block clickjacking.
Referrer-Policy: Add a Referrer-Policy so full URLs are not leaked to third parties in the Referer header (W3C Referrer Policy).
Permissions-Policy: Add a Permissions-Policy to disable browser features (camera, microphone, geolocation) you do not use (W3C Permissions Policy).
Server: cloudflare — Reveals software/version. Consider removing or trimming it to reduce reconnaissance surface.

Dig deeper with the Security Headers tool

Blacklist Reputation No IPv4 address available for the primary MX host — blacklist check skipped. N/A

Blacklist (Primary MX IP): No IPv4 address available for the primary MX host — blacklist check skipped.
Detail: No primary MX host to test.

Dig deeper with the Blacklist Reputation tool

Performance Homepage responded in 40 ms, 0.5 KB. A

HTTP status: Homepage returned HTTP 200.
Response time: Full HTML fetched in 40 ms — fast.
HTML size: 0.5 KB of HTML — lean.
Compression: No gzip/brotli content-encoding detected on the HTML response.

Dig deeper with the Performance tool

Keep example.com healthy after today

This report is a snapshot. Certificates expire, DMARC policies slip back, and IPs get blacklisted silently - get told the moment something regresses, or wire these checks into your own systems.

Monitor this domain for changes Automate this with the API

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.