TLS, SPF, DMARC & DNSSEC checks explained

📊 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 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 sender and receiver tests add cases of their 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 below 2048 bits (below 1024 bits caps at F), an RSA certificate key below 2048 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.