What the mail module tests against your MX hosts over port 25: STARTTLS, negotiated TLS and ciphers, certificates, FCrDNS and DANE/TLSA – with scoring and fixes.
Check your domain →
Need a DANE record? The free TLSA/DANE generator can fetch your live certificate and build the recommended 3 1 1 record for you.
Last updated: September 2026 · 13 checks documented
Mail server present #
No MX record does not mean "no mail". RFC 5321 §5.1: “If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host.” A domain with an A/AAAA record and no MX therefore receives mail on that very host, and every sending server knocks on port 25 there – so that host is tested like any MX. Only a domain with neither MX nor address records cannot receive mail at all; and only a Null MX record (RFC 7505) declares that on purpose.
RatingInformational (weight 0) – a missing MX record is a valid setup, not a defect. Three cases: no MX but address records present → the implicit MX is tested (all the findings below apply to it); no MX and no address records → nothing can be delivered, the module is marked not applicable; the MX or address lookup gave no conclusive answer → skipped, and the answer is cached only briefly instead of for an hour. A fourth path is not another verdict but an early exit: if every address of the implicit MX lies in one of three CDN edge networks (Cloudflare, Fastly, Amazon CloudFront), nothing is contacted on port 25 and the mail server tests below do not run at all – not even the DNS-only ones – because an address published as the domain's own A/AAAA record inside a CDN edge range was published for the website, not for mail. Not because no mail lives in those ranges: Cloudflare Email Routing's own MX hosts resolve into Cloudflare's published list. Reaching them takes an explicit MX record, and this gate only ever applies where there is none. That gate is all-or-nothing: a single address we do not recognise as one of those three (your own address, or simply a range our provider data does not cover) makes the host an ordinary probe target.
How to fix itPublish an explicit MX record so mail routing does not depend on the website address – or a Null MX ("0 .", RFC 7505) if the domain is not meant to receive mail.
Null MX (mail explicitly declined) #
A Null MX record (MX 0 ., RFC 7505) declares that a domain does not accept mail at all. Senders get an immediate, clean bounce instead of long timeouts, and the domain is harder to abuse as a spoofed sender (together with SPF -all and DMARC p=reject).
Ratingpass – a deliberate "no mail" declaration is a correct, secure configuration, and only a Null MX that stands alone in the RRset earns it. STARTTLS/DANE probes are skipped for the Null MX pseudo-entry. warn in two cases. First, a Null MX published alongside any other MX record: RFC 7505 §3 forbids that combination – "A domain that advertises a null MX MUST NOT advertise any other MX RR" – and what a sending server makes of such an RRset is not defined by RFC 7505 itself — RFC 5321 §5.1 settles it anyway, because an MX whose exchange returns no address record is unusable, and where no MX in the set is usable a sender MUST report the situation as an error. The prohibition covers any other MX RR, a malformed one included. Second, a record whose target is the DNS root but whose preference is not 0: RFC 7505 §3 defines the Null MX as a single MX RR whose RDATA section consists of "preference number 0 and a zero-length label", so a record with a different preference is neither that declaration nor the name of a host. What senders should do with it is something the RFC does not say – our reading is that it says nothing, and this scanner never connects to it. Weight 1 wherever the finding appears; an RRset with no root target at all does not produce it.
How to fix itNo action needed. If the domain SHOULD receive mail, replace the Null MX with real MX records pointing to your mail servers.
MX host addresses (A/AAAA) #
An MX record only names a host; that host still has to resolve to an address a sender can connect to. RFC 5321 §5.1 requires the MX host name to return at least one A or AAAA record, and says that if MX records are present but none of them are usable, that situation MUST be reported as an error. Two ways this goes wrong in practice: the MX name has no address record at all (a typo, a removed host), or it resolves only to addresses that are not usable on the public internet – a private or loopback range left over from an internal setup, but also documentation, benchmarking, multicast or otherwise reserved ranges. The finding names the reason for each address.
Ratingfail, weight 2. Only raised on a CONCLUSIVE DNS answer: a SERVFAIL or a resolver failure on our side is never reported as "this host has no address", because that would state our own failed measurement as a fact about your domain. It covers the MX hosts this scanner actually contacts – the five best-preferred ones – so a host beyond that limit is listed in the report but does not raise this finding.
How to fix itPublish an A and/or AAAA record with a publicly routable address for every MX host – or remove the MX record if the host no longer exists.
Addresses not contacted #
A domain without an MX record still receives mail: RFC 5321 §5.1 has the sender fall back to the domain’s own address ("implicit MX"). Those addresses were published for a website, though, and when one of them belongs to a content-delivery network — Cloudflare, Fastly, Amazon CloudFront — a connection on port 25 there is traffic nobody asked for and tells nothing about the domain’s mail setup. This scanner does not make it. The finding exists so that the omission is visible: the mail server tests below describe only the addresses that were actually contacted.
RatingInformational, weight 0, no effect on the grade — this is a decision of the scanner, not a defect of the domain. It appears only for the implicit MX; a CDN address behind a real, published MX record is a deliberate choice by the operator and is tested normally. Where every address of the implicit MX lies in one of those networks, no probe runs at all and the "Mail server present" finding says so instead.
How to fix itPublish an explicit MX record pointing at the mail host, so mail routing does not depend on the website address — or a Null MX ("0 .", RFC 7505) if the domain is not meant to receive mail at all.
STARTTLS on the MX #
STARTTLS encrypts the SMTP connection between mail servers. An MX that accepts only cleartext transmits mail unprotected.
RatingEach MX is probed over every published address family (IPv4 and IPv6) – one connection per family, and the finding states the sample size when a host publishes more addresses than that. Judged over the connections that actually produced an EHLO answer: a connection the server refused before that (a 4xx greeting, e.g. a rate limit) is reported as “not determined”, never as cleartext. pass if every measured connection offers STARTTLS and no host failed every one of the connections on which it announced it; warn if a published address family is unreachable while the other works – a family that failed on our side, or on every probed MX, does not count; fail + Cap C in two situations – a measured connection on which STARTTLS is not usable (not announced in EHLO, or the command refused after it was announced), and a host that announces STARTTLS while every connection carrying that announcement fails before a TLS session exists, for a reason that is not ours (our own timeout or a missing egress route never caps) – an announcement a sender cannot use is not protection. The report names which of the two capped the grade. Weight 3. skip when no connection produced a STARTTLS answer at all: port 25 unreachable, every server refusing before EHLO, or our own connection budget stopping the probes – and where that gap is a transient one of ours (our connection budget, or a missing egress route) the answer is cached for a minute instead of an hour.
How to fix itEnable STARTTLS on all MX hosts.
Mail server TLS version & cipher strength #
For mail transport, too, only modern TLS versions (1.2/1.3) and strong ciphers should be used. Besides the best-case handshake (run separately over IPv4 and IPv6 where published), two downgrade probes per MX check whether obsolete TLS ≤ 1.1 or a weak cipher is still on offer – an attacker could otherwise force a downgrade. Which weak families the probe can actually offer depends on this scanner’s own TLS build, and that is a real limit rather than a formality: measured on the current build (Node 24, OpenSSL 3.5), only NULL and anonymous suites can be offered at all, while RC4, 3DES, DES and export suites are compiled out and therefore cannot be tested for. The finding says so where it applies instead of implying a check that did not happen. The downgrade probes run on each host’s primary connection (the TLS configuration is per server, not per address family).
Ratingpass with TLS 1.2+ and no obsolete fallback; warn if TLS ≤ 1.1 is offered; fail + Cap C if a weak cipher is accepted. Weight 2. Two states are neither of those three: when STARTTLS was announced but no TLS session came about anywhere, the finding is reported as skipped and carries no weight – there is nothing to say about a version that was never negotiated; and where a downgrade probe did not run (our connection budget, a transport error, a rate limit on the extra connection), the all-clear is withdrawn for that host and the finding names it. The cap is the strength cap for this module: an obsolete version alone does not cap, a weak cipher does.
How to fix itEnforce TLS 1.2/1.3 on the MX hosts, disable 1.0/1.1, and remove RC4/3DES/DES/export/NULL cipher suites.
Cipher suites per TLS version #
Lists the cipher suites the mail server actually accepts, grouped by TLS version (TLS 1.3 / 1.2 / 1.1 / 1.0) – the same view a sending MTA negotiates against. To keep the outbound port-25 footprint small (blacklist protection), only one representative MX is enumerated: the first host, in preference order, on which a TLS session actually came about – being reachable is not enough. The other MX with a TLS session are compared by certificate fingerprint and negotiated suite – if identical, the list applies to them too; if they differ, that is stated instead of enumerated.
Ratingpass when none of the enumerated suites is weak; warn when a weak suite is offered (the strength cap itself lives on the “TLS version & cipher strength” check). Weight 1 – it counts towards the module grade like every other finding of that weight; good, info and skip stay out of the calculation entirely. An enumeration can also end at our own cap, deadline or a transport error, and then it may not claim absence: the counts are prefixed “≥” and the sentence about no weak suites is withdrawn. A weak suite that WAS found still counts – presence needs no completeness, absence does. skip when nothing could be enumerated at all; the per-version list exists only where an enumeration produced one. The same “not measured” form is used, on purpose, for a host that makes most connections wait: when at least two of our three connections to it (the first one and the two downgrade probes, each timed inside its own port-25 slot) took longer than a quarter of the sweep’s time budget, the sweep is not started at all – the finding prints every measured time and says that this decides nothing about the server’s list. When this scan’s time budget was used up before the enumeration could even start, the check is reported as “not measured”: its weight leaves the denominator instead of counting as a defect, and the report shows how much coverage was lost that way.
How to fix itPrefer AEAD suites (AES-GCM, ChaCha20-Poly1305) with ECDHE key exchange; disable CBC-only and static-RSA (no forward secrecy) suites where compatibility allows.
Forward secrecy on the MX #
Forward secrecy means each session gets its own ephemeral key, so recording the traffic today is useless even if the server’s private key leaks years later. Without it – a static-RSA key exchange – every recorded session becomes readable the moment that one key is compromised. RFC 9325 §4.1 requires implementations to support and prefer forward-secret suites and says static-RSA key transport SHOULD NOT be negotiated.
Ratingwarn if any probed connection negotiated a cipher without forward secrecy, otherwise pass. Weight 1, and deliberately NO grade cap: mail on port 25 is opportunistic security, and RFC 9325 §5.2 notes that its own recommendations "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 website module treats the same property more strictly, because HTTPS is a mandatory TLS channel: a client that dislikes the offer can simply refuse, and nothing silently degrades to cleartext. It caps at B where our own connection got no forward secrecy at all, and warns without a cap where the server merely also offers static-RSA suites.
How to fix itPrefer ECDHE suites on the mail server and switch off the static-RSA suites — IANA TLS_RSA_WITH_*, which in OpenSSL are the TLS ≤ 1.2 names carrying no key-exchange prefix at all (e.g. AES256-GCM-SHA384). The rule stops at TLS 1.2: RFC 9846 §1.3 separated the key exchange from the cipher suite, so TLS_AES_256_GCM_SHA384 and TLS_CHACHA20_POLY1305_SHA256 name no key exchange at all — every full TLS 1.3 handshake takes its forward secrecy from (EC)DHE — and they must stay enabled.
Diffie-Hellman parameter strength (MX) #
Where a mail server uses finite-field Diffie-Hellman (DHE) rather than the elliptic-curve variant (ECDHE), the size of the DH group decides how much forward secrecy is actually worth. Logjam showed two separate problems: a group below 1024 bits can be attacked outright, and the downgrade forces a connection onto export-grade parameters; at 1024–2047 bits the issue is different — only a handful of standard primes are in use worldwide, so a one-off precomputation by a well-funded attacker pays for itself and then decrypts recorded traffic passively. RFC 9325 §4.1 says TLS 1.2 implementations "SHOULD NOT negotiate cipher suites based on ephemeral finite-field Diffie-Hellman key agreement", and it gives its own reason there — "the known fragility of the construction (see [RACCOON]) and the limitation around negotiation, including using [RFC7919], which has seen very limited uptake" — not the precomputation argument above. Logjam is where §4.5 puts it: DH key lengths of at least 2048 bits are REQUIRED, and "The Logjam attack [Logjam] further demonstrates that 1024-bit Diffie-Hellman parameters should be avoided". None of this is specific to the web: SMTP on port 25 negotiates the same key exchange.
RatingThe group is read from our own STARTTLS handshake where that handshake used DHE, and otherwise from the cipher enumeration — a mail server that offers ECDHE to us and DHE only to senders that ask for it would otherwise never be measured at all, and that is the common shape. fail below 1024 bits, warn below 2048, otherwise pass; between 2048 and 3072 the text names the disagreement between sources rather than printing a bare green (SSL Labs 2009r caps only below 2048, NCSC-NL 2025-05 rates ffdhe2048 as insufficient, BSI TR-02102-2 version 2026-01 requires 3000 bit). Weight 1, and deliberately NO grade cap — the same reason forward secrecy on the MX carries none: port-25 STARTTLS is opportunistic security, and RFC 9325 §5.2 notes its own recommendations "might be too strict, since adhering to them could cause fallback to cleartext, a worse outcome". The website module measures the identical property and does hold cap letters for it (F below 1024, B below 2048), because HTTPS is a mandatory TLS channel where nothing degrades to cleartext behind the user's back — though those letters are dormant in practice, for a reason explained under "Diffie-Hellman parameter strength" in the website section: our own handshake refuses a group below 2048 bits outright, so a weak one is only ever visible through the enumeration, and the cap is reserved for the negotiated case. Where that applies, the text says our client refused the group rather than implying the server keeps it for special senders. The finding does not appear at all when no DH group was seen — a server using ECDHE only has nothing to answer for here.
How to fix itRaise the mail server’s DH parameters to at least 2048 bits (3072 or the standard ffdhe3072/4096 groups if you follow the European guidance) — or drop DHE entirely and offer only ECDHE, which avoids the question.
Mail server certificates #
For MTA-STS enforce, the certificate the receiving MX presents has to be usable by the sending MTA: RFC 8461 §4.2 requires that it "MUST not be expired and MUST chain to a root CA that is trusted by the Sending MTA" and that it carry "a subject alternative name (SAN) with a DNS-ID matching the hostname". DANE sets different conditions. With DANE-TA (usage 2), the certificate matched by the TLSA record is itself the trust anchor (RFC 6698 §2.1.1) – RFC 7671 §5.2.2 states there is "no expectation that the client is preconfigured with the TA certificate", so a private CA works and the sender may ignore its own trust store entirely; name checks still apply — RFC 7672 §3.2.2 makes them a MUST for DANE-TA(2), unlike DANE-EE(3) in §3.2.1 — and so does the validity period, but for a different reason: usage 2 still requires the chain to pass PKIX path validation (RFC 6698 §2.1.1, RFC 5280 §6.1.3), which §3.2.2 does not speak about. Unless every DANE-TA record is a "2 0 0" record that publishes the server certificate in full, the server must send the anchor certificate in its chain: RFC 7671 §5.2 requires it "unless all such TLSA records are '2 0 0' records that publish the server certificate in full", and §5.2.3 extends the requirement to "2 1 0" records that publish a full public key. A verified DANE-EE (usage 3) match pins the certificate outright, so the PKIX name and expiry checks do not apply at all (RFC 7672 §3.1.1). With pure opportunistic STARTTLS, an untrusted or self-signed chain is tolerable.
Ratingfail when a certificate is expired or not yet valid – X.509 path validation requires that "the certificate validity period includes the current time" (RFC 5280 §6.1.3(a)(2)) – or when it is issued for a different host. The name requirement has its own sources rather than §6.1.3: MTA-STS wants a SAN DNS-ID matching the MX hostname (RFC 8461 §4.2), DANE-TA has the client check the name against the TLSA base domain (RFC 7672 §3.2.2). The finding is raised for every probed MX regardless of which of the two the domain uses, because a certificate that fails these checks is refused by any sender that validates. warn for a chain problem: an incomplete chain (the certificate is publicly trusted, an intermediate is missing – Postfix states the requirement itself: the remote SMTP client "must receive the issuing CA certificates via the TLS handshake or via public-key infrastructure". The MTAs built on OpenSSL or GnuTLS — Postfix, Exim, Sendmail — take only the first of the two paths: they do no AIA fetching, so on those senders the gap stays open. Browsers do repair it, but not by one mechanism: Chrome fetches the missing intermediate over AIA (chromium/src, net/cert/cert_verify_proc_builtin.cc, read 2026-08-28), while Firefox does no AIA fetching at all and supplies it from a preloaded set (mozilla-firefox/firefox main, security/certverifier/CertVerifier.h, enum IssuerSource, read 2026-08-28). Safari is not named: Apple does not publish the code that would decide it. MTAs on OpenSSL or GnuTLS — Postfix, Exim, Sendmail — do neither. The Windows stack is documented to differ: .NET's chain engine may use the AIA extension to locate unknown issuer certificates unless DisableCertificateDownloads is set, and that defaults to false (dotnet/runtime, X509ChainPolicy.cs, read 2026-08-28); the underlying Win32 CertGetCertificateChain performs AIA retrievals unless CERT_CHAIN_DISABLE_AIA is set. Whether a given Exchange deployment validates the chain at all on port 25 was not measured), a chain that does not validate at all, or a chain ending in a root that is no longer part of the current Mozilla/CCADB set. Certificates pinned by a verified DANE-EE match are exempt (RFC 7672 §3.1.1). warn also inside the renewal window – the threshold is relative to the certificate's own lifetime (a quarter of it, never more than 15 days), the same rule the website module uses; DANE-EE pinned certificates are exempt, because RFC 7672 §3.1.1 has the expiry ignored there. A certificate whose validity dates cannot be read at all produces no verdict about time: the report says "validity unknown" and the renewal window is not applied. The remark about a root outside Mozilla's current set is three-valued in the same way – without a usable CCADB snapshot, no anchor is named at all. No rating cap: with opportunistic STARTTLS delivery still happens. Weight 1. Chain trust is judged against the same combined root store as the website module (OS + Node + CCADB) – because that store only ever adds roots, an anchor outside Mozilla's current set is named instead of silently passing.
How to fix itServe valid certificates that match the MX hostname and chain to a trusted CA (or set up DANE-EE) if you rely on MTA-STS/DANE.
Reverse DNS of the mail servers (FCrDNS) #
Forward-confirmed reverse DNS means each MX IP has a PTR record whose hostname resolves back to that same IP. RFC 1912 §2.1 asks for the underlying consistency – "Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain" – and warns that failing to do so "can cause loss of Internet services similar to not being registered in the DNS at all". That receivers use it as an anti-spam signal, and reject or greylist mail from hosts without it, is widespread operational practice rather than a requirement of that RFC – but the largest receiver publishes it as its own rule: Google's sender guidelines require sending domains or IPs to have valid forward and reverse DNS records and add that the sending IP address must match the address the hostname in the PTR record resolves to, which is forward confirmation in all but the name. That is one receiving provider's policy rather than a standard, and it is written for SENDING hosts. Checked here are the addresses of the MX hosts, because those are the ones a domain publishes; where a domain sends through the same machines, the result describes its outbound reputation as well.
Ratingpass if every checked MX address is forward-confirmed; warn if any lacks a PTR or fails to forward-confirm. An address whose reverse or forward lookup gave no clear answer counts as unchecked – it appears in neither the numerator nor the denominator, and the drill-down marks the row accordingly; a failed query of ours is not a statement about someone else’s DNS. If not a single address could be checked, the finding is skipped and does not affect the grade. Checked are the IPv4 and IPv6 addresses of each probed MX host (up to 4 per family, topped up from the longer list to at most 8 addresses per host; the drill-down notes when only a sample of even more published addresses was checked). Weight 1. (Pure DNS – runs even when port 25 is blocked.)
How to fix itSet up a matching PTR record for each MX IP (via your hosting/ISP) whose hostname resolves back to the same IP.
DANE / TLSA #
DANE binds the mail server certificate to a TLSA record via DNSSEC, protecting against TLS downgrade/MITM. DANE is only secure if the TLSA response is DNSSEC-authenticated.
Ratingpass if the presented certificate matches a DNSSEC-secured TLSA record. fail + Cap C in four cases: no record matches on one of the probed hosts; TLSA records without DNSSEC authentication; a usage-2 (DANE-TA) match on a certificate that does not carry the mail server’s name (RFC 7672 §3.2.2 requires the name check there, and only usage 3 is exempt); and a usage-2 match on an expired certificate – RFC 6698 §2.1.1 has usage 2 pass PKIX path validation with the matched record as the trust anchor, which an expired certificate does not, while the rule that "the expiration date of the server certificate MUST be ignored" belongs to DANE-EE(3) alone (RFC 7671 §5.1, which in the same passage tells DANE-TA operators to "replace certificates prior to their expiration dates"). No TLSA records at all → warn. Records that are present but all unusable — usage 0/1 only, or usage 2/3 with a selector, matching type or digest length that cannot be used — are graded like a domain with no TLSA at all: warn, weight 2. They are not entirely without effect (under RFC 7672 §2.2.3 a secure TLSA record commits sending MTAs to STARTTLS), but they authenticate nothing, and that is said in the text rather than credited to the mark; the DANE-configuration finding then yields its own weight so the same defect is not charged twice. Not graded, because neither a failed measurement of ours nor a defect already marked elsewhere may move the score: no connection, no TLS session, or a scan in which our own port-25 budget ran out before the TLSA-bearing hosts were contacted (info/skip); a TLSA lookup that returned neither an answer nor a definitive “does not exist” (skip); and a reachable host that publishes TLSA yet offers no STARTTLS — a full delivery stop under RFC 7672 §2.2.3, whose mark is carried by the STARTTLS finding (info); and TLSA published only on MX beyond the five hosts this scanner connects to, where no certificate comparison is possible at all (info). A pass that could not cover every MX names the hosts it leaves out. The drill-down table of this finding shows one row per TLSA record; a record that does not match while another one does is the spare key of a rollover and is shown amber, not red. Weight 2.
How to fix itEnable DNSSEC and publish TLSA records under _25._tcp.<mx> (recommended: usage 3, selector 1, matching 1).
DANE configuration #
The certificate usage field encodes two independent choices. PKIX (0/1) still requires the certificate to validate against a public CA – the TLSA record only adds a pin on top; DANE (2/3) replaces the public CA and uses the DNSSEC-signed record itself as the trust anchor, so a private or self-signed certificate works. TA (0/2) pins the issuing CA and lets leaf certificates rotate freely; EE (1/3) pins the certificate itself. For DANE-TA, pin an intermediate rather than the root: the server must include the pinned trust-anchor certificate in its TLS handshake (RFC 7671 §5.2), and roots are normally not sent, so a DANE-TA record pointing at a not-sent root will not validate. PKIX-TA (0) is not the way out on port 25: RFC 7672 §3.1.3 says TLSA records for that service "SHOULD NOT include TLSA RRs with certificate usage PKIX-TA(0) or PKIX-EE(1)", because client MTAs "cannot be expected to be configured with a suitably complete set of trusted public CAs". A 2 0 0 record that carries the whole certificate in DNS avoids sending the anchor, but both specifications advise against it – RFC 7671 §5.2.1: "TLSA records with a matching type of Full(0) are NOT RECOMMENDED", because clients may be unable to augment the chain from DNS. For SMTP, RFC 7672 §3.1 states the recommendation in one sentence: "we RECOMMEND the use of 'DANE-EE(3) SPKI(1) SHA2-256(1)', with 'DANE-TA(2) Cert(0) SHA2-256(1)' TLSA records as a second choice". Note that the selector differs per usage – DANE-TA publishers "SHOULD publish records with a selector of Cert(0)" (§3.1.2), so the anchor's constraints travel with the record – and that an SPKI digest survives certificate renewals only with the same key: a rekey changes the digest, and the record has to be updated with it. DANE also only protects delivery when every MX host is covered: for an MX without a usable TLSA record, RFC 7672 §2.2.1 has delivery proceed "as with pre-DANE opportunistic TLS", which includes cleartext where the server appears not to support TLS – and §2.2.1 forbids a better-preferred MX without TLSA from being skipped in favour of a covered one. For the key rollover, two TLSA records should exist temporarily.
Ratingwarn with PKIX usage (0/1); when some MX hosts publish no usable TLSA record; and when a published parameter combination (usage/selector/matching) contains no record matching the certificate currently served — RFC 7671 §8 requires the publisher to keep every combination current, and a client applying digest agility (RFC 7671 §9, binding for SMTP under RFC 7672 §5) would be left with the stale record alone. info when a parameter combination currently holds a single usable record — the normal RESTING state, not a defect: RFC 7671 §8.1 walks a key change through initial RRset (one record) → transitional RRset (two) → final RRset (one again), so the entry names the moment for the next key change instead of marking the state — and when a TLSA lookup of ours returned no definitive answer — such a host is named as unchecked, never counted as uncovered. The per-record view with the rollover semantics belongs to the DANE / TLSA finding above. Coverage is judged over every MX, not only the five this scanner connects to: whether a host publishes TLSA is a DNS question and does not need a port-25 connection. Its own limit of 15 MX applies to that lookup — it is a total, so the more hosts are contacted the fewer remain for the DNS-only view — and any host past it is named as unchecked in the finding. Weight 0–1, no cap: the stale-combination case always carries weight 1, the coverage gap only where the DANE finding above has not already graded the same defect (with every published record unusable, that finding carries the mark alone).
How to fix itUse usage 3, selector 1, matching 1 on every MX; during a rollover, temporarily publish two TLSA records — and update every published parameter combination in the same step.