Explanations & scoring methodology

Each check produces a finding with a status and a weight. The weighted findings of a module yield a percentage, which is converted into a letter grade (A+ … F). The home page combines all modules into an overall grade.

• pass – passed (full points)
• good – fulfilled, but does not count toward the grade (optional hardening)
• warn – room for improvement (half points)
• fail – problem/risk (0 points)
• info / skip – purely informational or not testable (does not count toward the grade)

What "not testable" does to the grade. A check we could not carry out leaves the numerator and the denominator, so it never counts against the domain. But that alone would mean the less we measured, the better the grade – a scan in which three of six checks failed to run could report a flawless 100 %. Modules therefore report the weight they lost, and the report says it: the module header names how many of its weight points the grade covers, and the overall grade is marked as provisional. A module that could not be graded at all is the same thing in stronger form: it leaves the average completely, so the overall number covers less and can come out higher than a complete run would give – the report names which module is missing and says so. It is a limit of the scan, not a finding about the domain – a repeat run may well measure it. Checks that simply do not apply (MTA-STS on a domain that receives no mail) are not counted as a gap: nothing was missed there.

The overall grade is a weighted total across all the modules’ findings, not an average of their grades, and it does not carry their rating caps. A module that raises more rating-relevant weight therefore counts for more than one that raises less. A module capped at F for an expired certificate still enters the overall figure with its uncapped percentage. Where that happens the overall grade names the capped module and its reason – the module grade is the one that counts.

There is a second way out of the calculation: a finding can carry the weight 0. It is then shown with its status and its full text, but stays out of the numerator and the denominator alike – whatever its status. That is how one defect avoids being charged twice when two findings describe it (for example DANE / TLSA and DANE configuration).

Rating basis: BSI first, Internet.nl and NIST beside it

Since September 2026 the cryptographic verdicts (cipher suites, certificate keys, Diffie-Hellman groups, DNSSEC keys) rest on the German BSI technical guidelines as the primary basis – TR-02102-2 (2026-01) for the catalogue of recommended suites, groups and key lengths, and TR-03116-4 with its TLS checklist for the profile – with Internet.nl (the NCSC-NL guideline of May 2025) and NIST SP 800-52 Rev. 2 as comparison columns. One rule decides the status of a suite or a key: fail when all three frameworks reject it, warn when BSI lists it as "not recommended" or when it is on none of the three lists, pass when BSI recommends it – being merely "not listed" costs nothing, because one list that carries a suite is evidence and the absence from another is not. Every affected finding shows up to three neutral norm pills – one per framework that speaks to the point – each with that framework’s own modal word (BSI MUSS/SOLL/SOLLTE/KANN/DARF NICHT or empfohlen/nicht empfohlen/nicht gelistet, Internet.nl required/recommended/info, NIST shall/should/may/shall not); the pill names the norm, the colour of the row is our verdict. The cipher-suite drill-down shows the three columns per suite, with BSI's "recommended until" year; that year is read against the current date, so a verdict expires on 1 January without a code change, and a weekly watcher reports new versions of the cited source documents.

Since wave 2 of the same effort the pills also stand on the policy findings (name servers, DNSSEC, SPF, DKIM, DMARC, MTA-STS, TLS-RPT, certificates, redirects, HTTP headers) and on the live mail tests. One rule picks each pill from the mapping table that backs the whole rating: per framework the strictest obligation level the table cites for the finding (BSI MUSS/DARF NICHT over SOLL over SOLLTE over KANN; NIST shall over should over may; Internet.nl required over recommended over info); a plain remark without an obligation level yields no pill, and a document that is still a draft yields none either. A BSI or NIST pill appears only where a federal document governs exactly the property being judged; the header checks carry no NIST pill, because NIST has no header guideline of that kind. The tooltip of a pill names the document and the clause; where two documents disagree (an SPF -all versus ~all, DANE required versus MTA-STS recommended) the table, not the pill, carries the difference, and every documented exception to the rule is recorded there with its reason. Each finding that shows a pill also lists the cited document among its references.

Rating caps (modeled on SSL Labs)

A single serious finding must not be averaged away by many "pass" results. For this reason, certain findings cap the module grade regardless of the average (minimum logic). The lists below name the most frequent causes and are deliberately not exhaustive – the live email test adds cases of its own, and every capping finding names its own reason in the report. A cap takes effect only while its finding stands at fail or warn. A cap can apply without changing anything: if the module average already sits at or below the cap, the grade stays where it is. The module header names such a finding anyway – it is severe enough to overrule the average, it just does not bind here. The lists also read per module: a cause named here caps where the module that raises it applies a cap. Mail transport on port 25 is the systematic exception – STARTTLS there is opportunistic security, and RFC 9325 §5.2 says of exactly that situation that stricter rules "might be too strict, since adhering to them could cause fallback to cleartext, a worse outcome than using TLS with an outdated protocol version or cipher suite". The MX checks therefore give a verdict but no cap for a missing forward secrecy, an obsolete TLS version, an incomplete or untrusted chain and an expired certificate; the only cap they hand out is Cap C.

• Cap A-: no TLS 1.3.
• Cap B: legacy TLS 1.0/1.1, no Forward Secrecy, no AEAD ciphers, incomplete certificate chain, DH parameters of 1024–2047 bits (below 1024 bits caps at F), an RSA certificate key of 1024–2047 bits, RC4.
• Cap C, among others: single DES/RC4/3DES with TLS 1.1+, a weak cipher on an MX, cleartext-only MX (no STARTTLS), a redirect that ends on unencrypted HTTP, DMARC p=none, an inoperative or duplicated DMARC record, SPF that authorises every sender (+all or a /0 range) or is inoperative through several records, DANE-TLSA without DNSSEC or not matching the presented certificate, a DANE-TA record that matches but whose certificate does not carry the mail server's name or has expired, an MX that announces STARTTLS while none of its probed connections completes a TLS session. The live mail tests add their own: cleartext delivery, a message failing DMARC alignment, a missing or failing DKIM signature, a forgeable DKIM or MX key, STARTTLS command injection, MTA-STS enforce that would drop mail.
• Cap F, among others: an expired certificate, an RSA key below 1024 bits, a certificate key whose private half can be computed from the public one (ROCA, Fermat-factorable primes), DH parameters below 1024 bits, NULL/export/anonymous ciphers, a DNSSEC zone that validating resolvers reject – invalid signatures, a DS at the parent with no DNSKEY in the zone, or a stale DS matching no published key – and expired or not-yet-valid signatures of a zone anchored by a DS, as long as no validating resolver reports it as authenticated. The receiving test adds a domain with no resolvable or reachable mail server.
• T (Trust) or M (Mismatch): T for a certificate that is not trusted (and whose chain we could not repair from the publicly disclosed intermediates), that is signed with a weak hash (SHA-1/MD5, in the leaf or in an intermediate of the served chain), or that was issued on or after 1 September 2020 for more than 398 days and is therefore rejected by Chrome and Safari; M for a certificate that does not match the hostname. Both override the letter grade.

Methodology based on the SSL Labs Server Rating Guide, Mozilla, OWASP, and the relevant RFCs.