How the score is calculated

Each category starts at 100. Every failing or warning check subtracts its rule's published deduction, scaled by how sure we are and by how many times the same fault repeats, and bounded by a ceiling on the family of related faults it belongs to. The overall score is the weighted mean of the categories we were able to measure, with a handful of faults severe enough to cap it outright.

categoryScore = max(0, 100 − Σ_families min(familyCap, Σ_findings
                  deduction × statusMultiplier × confidenceMultiplier × repeatMultiplier))

overall       = min( Σ weight × categoryScore  /  Σ weight , gateCap )
                      over the categories that were actually measured

Nothing is hidden behind that. Open any finding on a report and it shows the rule, the deduction, the multipliers that were applied and the cap it landed under; the numbers in the drawer add up to the number printed next to it, and a test proves they do.

The weights are a product judgement about what matters to a domain owner — explicit, versioned, and written down here so you can disagree with a specific number rather than with a black box. They are not derived from a risk calculation, and we do not claim they are. Internet.nl, the only comparable tool covering more than one domain of risk, avoids the question by keeping its web and mail scores separate rather than blending them; we blend them, and the weights below are where that choice is visible.

A rule declares a deduction — how much it removes from its category's 100. Three multipliers stand between that number and the score.

Status: did the check fail, or merely warn?

Confidence: how sure are we?

Repeats: the same fault, several times

When one rule fires more than once — the same weak cipher on four ports, the same missing attribute on six cookies — the instances are ordered heaviest first and tapered.

Ordering by weight rather than by the order modules happened to report in is what makes the score independent of scan timing, and what makes "adding a failing check can never raise the score" true.

Related rules share a ceiling. Without one, a single underlying problem that produces many findings would outweigh everything else on the report: a host with MySQL, PostgreSQL and Redis all answering the internet has one problem — no firewall — and must not be scored as though it had three, and six SOA timer complaints are one piece of DNS hygiene, not six outages.

Each cap is sized on one rule and one heuristic. The rule: no single family may take its category to zero on its own. The heuristic: the cap sits at or a little above the family's heaviest single rule, so the fault that matters most still lands at its full published weight, and at or below the family's summed deductions, so the cap can actually bind. Both bounds are asserted by a test, and the columns below let you check them yourself.

A rule that declares no family stands alone and is bounded only by the category's default ceiling of 100. That is reserved for rules that cap a category outright anyway — the gates below.

A weighted mean cannot express "this one thing is so wrong that nothing else matters". TLS is 15.8% of the scope, so a domain serving an expired certificate would still score in the eighties on the strength of its DNS and its mail. Gates are the override that makes the mean safe: a small set of faults that cap the score outright, whatever else is right.

Each gate caps its own category as well as the overall score, so a category panel can never show a comfortable number while the summary it belongs to is gated — the drill-down would otherwise contradict the headline. And a gate never fires on a guess: the confidence floor is on every one of them, because capping somebody's score at 30 on an inference is not something we could defend to them.

These bands are reasoning rather than measurement, and that is worth saying plainly. Comparing them to Observatory's or SSL Labs' bands directly would be misleading — a threshold means nothing without the aggregation function under it, and ours is a weighted mean of fourteen categories, which regresses toward the middle where a running penalty total does not. Once there is a large enough body of real scans, we intend to plot the distribution and move the boundaries if they do not separate meaningfully. We would not move the weights to fix a distribution.

A+ needs the score, and no finding at high severity or worse, and every applicable item below demonstrated affirmatively. The old rule was two absences — a high enough score and no serious complaints — which meant a domain that did everything adequately and nothing well could reach the top grade. Both comparable tools that award a top grade require an affirmative extra, and so do we.

Each is decided by the check you can already see on the report — DMARC is enforcing, so spoofed mail is quarantined or rejected, The HSTS instruction lasts six months or more, The server supports TLS 1.3 — rather than by a second, invisible test. The grade and the finding can therefore never disagree.

Missing an A+ prerequisite withholds A+ and nothing else: the domain gets an A. These decide whether the top grade is awarded; they never deduct. And within a category we did scan, silence is not credit — if the HSTS check did not produce a pass, for any reason including an error, the achievement was not demonstrated. A category that was never in the scan at all is simply not applicable: a mail-only scan has no opinion about HSTS, and denying A+ for evidence nobody asked us to gather would make the grade depend on which tool page you arrived through rather than on the domain.

The most important part of a scoring model is what it does when it does not know. A methodology page that lists weights without describing the denominator is describing a different engine.

A category we could not test is excluded, never assumed to pass

If the TLS checks did not run, TLS does not score 100 and it does not score 0. It leaves the calculation, and the weighted mean is taken over the categories that remain. Scoring it 100 is a false pass; scoring it 0 penalises a domain for our probe being down; keeping it in the denominator at 0 points is arithmetically the same as scoring it 0. Excluding it is the only honest answer, and it is why a report will tell you "TLS was not tested" instead of showing you a green panel.

A score built on part of the assessment is labelled as one

Renormalising gives the surviving categories more influence than they would otherwise have, so a partial score is not comparable to a complete one and is never presented as though it were. Any scan with an untested or partially tested category is markedpartial and cannot be graded above B— the same principle as the A+ prerequisites, extended downward: a top grade is awarded for a demonstrated positive, and a category nobody looked at is precisely an absence of evidence.

Below half the scope, we state no score at all

When less than 50% of a scan's scoped weight was actually measured, no overall score is shown. A number derived from a fifth of the checks is a number about a fifth of the domain, and presenting it as the domain's score is the same false pass in a different place. Within a single category the same floor applies at 60% coverage: below it the category reports "incomplete" rather than a figure.

A score is comparable within one ruleset version, and not across two

Every scan stores the scoring configuration and ruleset version it was scored under — today 2026.09.6 and 2026.09.9. Changing a weight, a cap or a rule's text changes what a number means, so we bump the version rather than quietly re-baselining history. When you compare two scans of the same domain, the comparison tells you which differences are your configuration changing and which are ours — because a score that moved because we changed our mind is not an improvement, and reporting it as one would be the easiest lie on the whole report.

All 292 rules are published with their severity, deduction, family cap and the standards they cite.