Domain Risk Scanner

Domain risk scanner: nine external checks, one weighted grade

Type a domain, and this scanner runs nine independent checks against it from the outside — certificate, security headers, email authentication, DNS, HTTPS enforcement, privacy signals, reputation, known breaches, and registration data — then combines them into a single weighted score and letter grade. Every failed check comes with the specific issue and step-by-step remediation instructions for Nginx, Apache and Cloudflare.

Two things to be clear about up front. First, this one is not a client-side tool: the scan runs on our server, because it needs to make DNS queries and connections your browser cannot. Second, and more important: a risk score is a signal, not a verdict. Nothing here determines whether a domain is malicious. It measures how well a domain is configured and whether public sources have anything on record about it. A brand-new phishing domain with a valid certificate and a clean Safe Browsing record can score well; a fifteen-year-old legitimate business can score badly because nobody ever added a CAA record. Read the categories, not just the letter.

Exactly what gets checked

Separately from the nine scored categories, the scanner enumerates subdomains from Certificate Transparency logs via crt.sh, reporting the full count and listing up to twenty. That is not scored — it is an attack-surface inventory, and it is frequently the most interesting output on the page, because CT logs surface staging, admin and legacy hosts that nobody remembered were still resolving.

What it does not check

Being precise about this matters more than the feature list:

• No typosquatting or lookalike analysis. The scanner does not generate permutations of your domain, does not measure edit distance to known brands, and does not tell you whether a domain is impersonating another one. If you came here to check whether rnicrosoft.com is squatting on Microsoft, this tool will simply score that domain's configuration.
• One reputation source, not a blocklist sweep. Reputation is Google Safe Browsing only. It does not query Spamhaus, SURBL, PhishTank, or any RBL. A domain listed on a mail blocklist can still show a clean reputation here.
• No authenticated or internal testing. Everything is unauthenticated and external. It cannot see your configuration, only what your public endpoints reveal.
• Content is not assessed. Nothing evaluates what the site says or sells.

How the scoring works, category by category

Several categories use simple additive point schemes that are worth knowing, because they tell you exactly which change moves the needle.

DNS health starts at 60 if DNSSEC is enabled and 20 if it is not, then adds 15 for A records, 15 for MX records and 10 for CAA records, capped at 100. DNSSEC is therefore worth 40 points on its own — the single largest lever in the category.

Web security is 40 points for an HTTP→HTTPS redirect, 35 for an HSTS header, 25 for being on the HSTS preload list. The redirect check inspects the Location header on a manual-redirect request; if that is inconclusive but an HSTS header is present on the HTTPS response, enforcement is credited anyway.

Privacy is 65 points for finding a policy page at /privacy, /privacy-policy, /legal/privacy or /privacy.html, plus 35 for detecting a cookie-consent platform in the homepage HTML. The consent detection is pattern-matching against known vendors — OneTrust, Cookiebot, CookieYes, TrustArc, Osano, CookieFirst and several generic markers — in the first 100,000 characters of the page. A custom-built consent banner will usually not be detected, and a policy page at an unusual path will be missed. This is a 5% category; do not redesign anything over it.

Operational starts at 50 and adds 25 for a domain over a year old (15 if over 90 days), plus 25 for registration valid more than a year out (15 if more than 90 days), and subtracts 20 if the domain expires within 30 days.

Data leakage starts at 100 and subtracts 15 per matched breach, to a maximum of 80, with a further 20 off if more than a million accounts were affected across those breaches (10 off above a hundred thousand).

Category scores map to letters on a fixed scale — 98+ is A+, 90+ A, 85+ A−, 80+ B+, 75+ B, 70+ B−, 65+ C+, 60+ C, 55+ C−, 50+ D, below 50 F — and the same scale applies to the composite. Status labels are simpler: 75 and above passes, 50 to 74 warns, below 50 fails.

A worked composite

Take a competently run site that has never touched DNSSEC: SSL 100, headers 60, email auth 85, DNS 50 (A and MX present, no DNSSEC, no CAA), web security 75 (redirect and HSTS but not preloaded), privacy 65 (policy but no detected consent tool), reputation 100, data leakage 100, operational 100.

(100×0.20) + (60×0.15) + (85×0.15) + (50×0.10) + (75×0.10) + (100×0.10) + (100×0.10) + (100×0.05) + (65×0.05) = 20 + 9 + 12.75 + 5 + 7.5 + 10 + 10 + 5 + 3.25 = 82.5, rounded to 83 — a B+.

Now add DNSSEC and a CAA record. DNS goes from 50 to 100, which at a 10% weight adds 5 points to the composite: 87.5, rounded to 88 — an A−. Two DNS changes, no application work, a full grade step. That is the kind of thing the category breakdown exists to make visible, and it is why reading the weights beats chasing the letter.

The failure modes that will mislead you

This is the most important section on the page. Every check depends on a third party, and each one fails in a specific direction:

• Reputation defaults to a perfect score when it cannot run. If the Safe Browsing lookup is unconfigured or errors out, the category returns 100/A+ with a summary saying the check was unavailable. It is 10% of your composite. Read the summary text, not the grade — “No reputation issues found” and “Reputation check unavailable” look identical in the number.
• Breach checking defaults to 80/B+ when unavailable, and operational data defaults to 50/D when WHOIS and RDAP both fail. A D on operational for a well-established domain usually means the registry did not answer, not that something is wrong.
• SSL defaults to 0/F on failure. Since it is the heaviest category at 20%, one unreachable checker can cost 20 composite points. An F on SSL for a site you know has a valid certificate is a check failure, and the summary will say so.
• Header and privacy checks need the origin to answer. A WAF, geo-block or bot filter that rejects our request produces missing-header and missing-policy findings for a site that has both.
• Missing MX is not always a fault. The DNS category deducts for absent MX records, which is correct for a domain that sends mail and wrong for a domain deliberately configured not to.

One more that catches almost everyone. The data leakage check matches the HIBP catalogue on the breached service's own domain. It answers “has this domain itself been breached and catalogued publicly?” — which for the overwhelming majority of business domains is no. It does not tell you whether your employees' email addresses appear in other companies' breaches. That is a different question requiring a different data source, and a clean result here is not evidence that your staff's credentials are safe.

Remediation guidance, and the deeper scan

Findings are matched against a library of remediation guides keyed to the issue text, so a missing Content-Security-Policy returns the actual sequence — start with a report-only policy, collect reports to learn what your pages load, then build the enforcing policy — along with the Nginx directive, the Apache directive, and where the setting lives in Cloudflare. Certificate expiry, weak ciphers, TLS 1.0, missing X-Frame-Options and the rest each have their own guide. This is the part that makes the scan actionable rather than merely diagnostic.

A deep scan is available and is gated deliberately. It adds technology fingerprinting with matched CVEs, per-subdomain SSL and header grading, a port scan, and CMS exposure probing — checks that are intrusive enough that we verify you have authority over the domain first. Requesting one requires a work email at the scanned domain or a subdomain of it; free mailbox providers are rejected, the verification link expires within a day, and only one deep scan per domain is accepted in any seven-day window. Results land at their own URL. If you do not control the domain, you do not get the deep scan — that is the intended behaviour, not a bug.

Practical notes

• Input handling. Paste a full URL if you like; the scheme, www., port and path are stripped before scanning. The scan targets the registrable domain.
• Caching. Results are cached server-side for 30 days, as is registration data. A re-scan immediately after a fix may return the earlier picture.
• Timing. The nine checks run in parallel with per-check timeouts, and one slow third party cannot stall the whole scan — it fails to that category's default instead.
• PDF report. Exporting asks for an email address, stored in your browser so it only asks once.
• Use it as a checklist, not a verdict. The right output of a scan is three or four specific configuration changes with instructions attached. The letter grade is a way to track whether you made them.