Was das Mail-Modul über Port 25 gegen Ihre MX-Hosts prüft: STARTTLS, ausgehandeltes TLS und Cipher, Zertifikate, FCrDNS und DANE/TLSA – mit Bewertung und Behebung.
Jetzt Domain prüfen →
Sie brauchen einen DANE-Record? Der kostenlose TLSA/DANE-Generator holt Ihr Live-Zertifikat und erzeugt daraus den empfohlenen 3 1 1-Record.
Stand: November 2026 · 16 Checks dokumentiert
Mailserver vorhanden #
Kein MX-Record heißt nicht „keine 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.“ Eine Domain mit A/AAAA-Record und ohne MX empfängt Mail also auf genau diesem Host, und jeder sendende Server klopft dort auf Port 25 an — dieser Host wird deshalb wie ein MX geprüft. Nur eine Domain ohne MX UND ohne Adress-Records kann überhaupt keine Mail empfangen; ausdrücklich erklärt das allein ein Null-MX-Record (RFC 7505).
BewertungInformativ (Gewicht 0) — ein fehlender MX-Record ist eine gültige Konfiguration, kein Mangel. Drei Fälle: kein MX, aber Adress-Records vorhanden → der implizite MX wird geprüft (alle Findings unten gelten für ihn); kein MX und keine Adress-Records → es kann nichts zugestellt werden, das Modul gilt als nicht anwendbar; die MX- oder Adress-Abfrage lieferte keine eindeutige Antwort → übersprungen, und die Antwort wird nur kurz statt eine Stunde zwischengespeichert. Ein vierter Weg ist kein weiteres Urteil, sondern ein früher Ausstieg: Liegt jede Adresse des impliziten MX in einem von drei CDN-Edge-Netzen (Cloudflare, Fastly, Amazon CloudFront), wird auf Port 25 nichts kontaktiert und die Mailserver-Tests unten laufen gar nicht — auch die reinen DNS-Prüfungen nicht —, weil eine Adresse, die als eigener A-/AAAA-Record der Domain in einem CDN-Edge-Bereich steht, für die Website veröffentlicht wurde und nicht für Mail. Nicht etwa, weil in diesen Bereichen keine Mail liefe: Die MX-Hosts von Cloudflare Email Routing lösen in Cloudflares veröffentlichte Liste auf. Erreichbar sind sie nur über einen ausdrücklichen MX-Record, und dieses Gate greift ausschließlich dort, wo es keinen gibt. Dieses Gate ist alles-oder-nichts: Eine einzige Adresse, die wir nicht als eines dieser drei Netze erkennen (eine eigene Adresse oder schlicht ein Bereich, den unsere Anbieterdaten nicht abdecken), macht den Host zum ganz normalen Prüfziel.
BehebungEinen ausdrücklichen MX-Record veröffentlichen, damit das Mail-Routing nicht an der Website-Adresse hängt — oder einen Null MX („0 .“, RFC 7505), wenn die Domain gar keine Mail empfangen soll.
Null MX (Mail explizit abgelehnt) #
Ein Null-MX-Record (MX 0 ., RFC 7505) erklärt, dass eine Domain überhaupt keine Mail annimmt. Absender erhalten sofort einen sauberen Bounce statt langer Timeouts, und die Domain lässt sich schwerer als gefälschter Absender missbrauchen (zusammen mit SPF -all und DMARC p=reject).
Bewertungpass – eine bewusste „keine Mail“-Erklärung ist eine korrekte, sichere Konfiguration, und sie gilt nur für einen Null MX, der allein in der RRset steht. STARTTLS-/DANE-Probes werden für den Null-MX-Pseudoeintrag übersprungen. warn in zwei Fällen. Erstens: ein Null MX neben irgendeinem weiteren MX-Record – RFC 7505 §3 verbietet diese Kombination („A domain that advertises a null MX MUST NOT advertise any other MX RR“), und was ein sendender Server mit einer solchen RRset tut, legt RFC 7505 selbst nicht fest — RFC 5321 §5.1 entscheidet es trotzdem: Ein MX, dessen Ziel keinen Adress-Record liefert, ist unbrauchbar, und ist kein MX der Menge brauchbar, MUSS ein Sender die Lage als Fehler melden. Das Verbot gilt für jeden weiteren MX-Record, auch für einen fehlerhaften. Zweitens: ein Record, dessen Ziel die DNS-Wurzel ist, dessen Priorität aber nicht 0 lautet – RFC 7505 §3 definiert den Null MX als einzelnen MX-Record, dessen RDATA-Abschnitt aus „preference number 0 and a zero-length label“ besteht; ein Record mit anderer Priorität ist damit weder diese Erklärung noch der Name eines Hosts. Was Absender damit tun sollen, sagt die RFC nicht – unsere Lesart ist, dass sie nichts aussagt, und dieser Scanner kontaktiert einen solchen Record nie. Gewicht 1, wo das Finding erscheint; eine RRset ganz ohne Root-Ziel erzeugt es nicht.
BehebungKeine Maßnahme erforderlich. Falls die Domain doch Mail empfangen SOLL, den Null MX durch echte MX-Records auf die eigenen Mailserver ersetzen.
Adressen der MX-Hosts (A/AAAA) #
Ein MX-Record nennt nur einen Host; dieser Host muss immer noch auf eine Adresse auflösen, zu der ein Absender eine Verbindung aufbauen kann. RFC 5321 §5.1 verlangt, dass der MX-Hostname mindestens einen A- oder AAAA-Record liefert, und hält fest: Sind MX-Records vorhanden, aber keiner davon nutzbar, MUSS das als Fehler gemeldet werden. Zwei Varianten kommen in der Praxis vor: Der MX-Name hat gar keinen Adress-Record (Tippfehler, entfernter Host), oder er löst ausschließlich auf Adressen auf, die im öffentlichen Internet nicht nutzbar sind – ein privater oder Loopback-Bereich aus einem internen Aufbau, aber auch Dokumentations-, Benchmarking-, Multicast- oder sonst reservierte Bereiche. Das Finding nennt den Grund je Adresse.
Bewertungfail, Gewicht 2. Wird nur bei einer EINDEUTIGEN DNS-Antwort erhoben: ein SERVFAIL oder ein Fehler auf unserer Seite wird nie als „dieser Host hat keine Adresse“ gemeldet — das wäre unsere eigene fehlgeschlagene Messung als Tatsache über Ihre Domain. Erhoben wird es für die MX-Hosts, die dieser Scanner tatsächlich kontaktiert — die fünf bestpriorisierten —, ein Host jenseits dieser Grenze steht also im Bericht, löst dieses Finding aber nicht aus.
BehebungFür jeden MX-Host einen A- und/oder AAAA-Record mit öffentlich routbarer Adresse veröffentlichen — oder den MX-Record entfernen, wenn der Host nicht mehr existiert.
Nicht kontaktierte Adressen #
Eine Domain ohne MX-Record empfängt trotzdem Mail: RFC 5321 §5.1 lässt den Absender auf die eigene Adresse der Domain zurückfallen („impliziter MX“). Diese Adressen wurden aber für eine Website veröffentlicht, und wenn eine davon in einem Content-Delivery-Netzwerk liegt — Cloudflare, Fastly, Amazon CloudFront —, ist eine Verbindung auf Port 25 dorthin Verkehr, um den niemand gebeten hat, und sie sagt nichts über die Mail-Konfiguration der Domain aus. Dieser Scanner stellt sie nicht her. Das Finding gibt es, damit die Auslassung sichtbar bleibt: Die Mailserver-Tests darunter beschreiben nur die tatsächlich kontaktierten Adressen.
BewertungInformativ, Gewicht 0, ohne Einfluss auf die Note — das ist eine Entscheidung des Scanners, kein Mangel der Domain. Es erscheint nur beim impliziten MX; eine CDN-Adresse hinter einem echten, veröffentlichten MX-Record ist eine bewusste Wahl des Betreibers und wird normal geprüft. Liegen alle Adressen des impliziten MX in einem dieser Netze, läuft gar keine Probe, und das Finding „Mailserver vorhanden“ sagt das stattdessen.
BehebungEinen ausdrücklichen MX-Record auf den Mailhost veröffentlichen, damit das Mail-Routing nicht an der Website-Adresse hängt — oder einen Null MX („0 .“, RFC 7505), wenn die Domain gar keine Mail empfangen soll.
STARTTLS auf dem MX #
STARTTLS verschlüsselt die SMTP-Verbindung zwischen Mailservern. Ein MX, der nur Klartext akzeptiert, überträgt Mail ungeschützt.
BewertungJeder MX wird über jede veröffentlichte Adressfamilie (IPv4 und IPv6) getestet – eine Verbindung je Familie, und das Finding nennt die Stichprobengröße, wenn ein Host mehr Adressen veröffentlicht. Bewertet werden die Verbindungen, die tatsächlich eine EHLO-Antwort erbracht haben: Eine Verbindung, die der Server vorher abgewiesen hat (eine 4xx-Begrüßung wie ein Ratenlimit, ein dauerhaftes 5xx oder eine 521-Begrüßung — die RFC 7504 §3 für einen Host reserviert, der unter keinen Umständen Mail annimmt, und die der Text als solche benennt, statt sie als mögliches Greylisting zu relativieren), erscheint als „nicht ermittelt“ und nie als Klartext. pass, wenn jede gemessene Verbindung STARTTLS anbietet und kein Host auf allen Verbindungen scheitert, auf denen er es angekündigt hat; warn, wenn eine veröffentlichte Adressfamilie nicht erreichbar ist, während die andere funktioniert – eine Familie, die an uns oder an jedem geprüften MX scheitert, zählt nicht; fail + Cap C in zwei Fällen – eine gemessene Verbindung, auf der STARTTLS nicht nutzbar ist (in EHLO nicht angekündigt, oder das Kommando danach abgelehnt), und ein Host, der STARTTLS ankündigt, bei dem aber jede Verbindung mit dieser Ankündigung scheitert, bevor eine TLS-Sitzung besteht, und zwar aus einem Grund, der nicht bei uns liegt (unsere eigene Zeitüberschreitung oder eine fehlende Egress-Route deckeln nie) – eine Ankündigung, die ein Absender nicht nutzen kann, ist kein Schutz. Der Bericht nennt, welcher der beiden Fälle die Note gedeckelt hat. Gewicht 3. skip, wenn gar keine Verbindung eine STARTTLS-Antwort erbracht hat: Port 25 nicht erreichbar, alle Server weisen vor dem EHLO ab, oder unser eigenes Verbindungsbudget hat die Proben gestoppt – und wo diese Lücke eine vorübergehende auf unserer Seite ist (unser Verbindungsbudget oder eine fehlende Egress-Route), wird die Antwort eine Minute statt eine Stunde zwischengespeichert.
BehebungSTARTTLS auf allen MX-Hosts aktivieren.
Mailserver-TLS-Version & Cipher-Stärke #
Auch für den Mailtransport sollten nur moderne TLS-Versionen (1.2/1.3) und starke Cipher zum Einsatz kommen. Neben dem Best-Case-Handshake (separat über IPv4 und IPv6, sofern veröffentlicht) prüfen zwei Downgrade-Probes pro MX, ob veraltetes TLS ≤ 1.1 oder ein schwacher Cipher noch angeboten wird – ein Angreifer könnte sonst einen Downgrade erzwingen. Welche schwachen Familien die Probe überhaupt anbieten kann, hängt vom TLS-Build dieses Scanners ab, und das ist eine echte Grenze und keine Formalie: Auf dem aktuellen Build (Node 24, OpenSSL 3.5) gemessen lassen sich nur NULL- und anonyme Suites anbieten, während RC4, 3DES, DES und Export-Suites gar nicht einkompiliert sind und deshalb nicht geprüft werden können. Das Finding sagt das dort, wo es zutrifft, statt eine Prüfung zu suggerieren, die nicht stattgefunden hat. Die Downgrade-Probes laufen auf der primären Verbindung jedes Hosts (die TLS-Konfiguration gilt je Server, nicht je Adressfamilie).
Bewertungpass bei TLS 1.2+ ohne veralteten Fallback; fail + Cap C, wenn ein schwacher Cipher akzeptiert wird, und ebenso, wenn die BESTE erreichbare Version eines MX TLS 1.0/1.1 ist – kein Rahmenwerk lässt einen MX ohne TLS 1.2 zu (TR-03116-4 §2.1.1 MUSS, NIST SP 800-52r2 §3.1 shall, NCSC-NL insufficient, User-Entscheid B1); warn ohne Deckel, wenn TLS 1.2+ ausgehandelt wird und TLS ≤ 1.1 daneben lediglich geduldet wird – der nachrangige Fallback, den TR-03108 §4.3.2 im opportunistischen Verkehr erlaubt und den NIST bei Interoperabilitätsbedarf zulässt. Gewicht 2. Die Stufe „beste Version“ ist eine aufgeschriebene Regel und eine nicht genommene Messung: Unser eigener STARTTLS-Client bietet nichts unterhalb von TLS 1.2 an; ein Host, der nur TLS 1.0/1.1 spricht, bringt mit uns also gar keinen Handshake zustande und landet im Zustand „keine TLS-Sitzung“ weiter unten statt auf dieser Stufe. Zwei Zustände gehören zu keinem der drei: Wurde STARTTLS angekündigt, kam aber nirgends eine TLS-Sitzung zustande, gilt das Finding als übersprungen und trägt kein Gewicht – über eine nie ausgehandelte Version lässt sich nichts sagen. Und wo eine Downgrade-Probe nicht gelaufen ist (unser Verbindungsbudget, ein Transportfehler, ein Ratenlimit auf der Zusatzverbindung), wird die Entwarnung für diesen Host zurückgenommen und das Finding benennt ihn. Beide fail-Fälle vergeben den Stärke-Deckel dieses Moduls, und sie vergeben ihn einmal.
BehebungTLS 1.2/1.3 auf den MX-Hosts erzwingen, 1.0/1.1 deaktivieren und RC4-/3DES-/DES-/Export-/NULL-Cipher-Suites entfernen.
Cipher-Suites pro TLS-Version #
Listet die Cipher Suites auf, die der Mailserver tatsächlich akzeptiert, gruppiert nach TLS-Version (TLS 1.3 / 1.2 / 1.1 / 1.0) – dieselbe Sicht, gegen die ein sendender MTA verhandelt. Um den ausgehenden Port-25-Footprint klein zu halten (Blacklist-Schutz), wird nur ein repräsentativer MX enumeriert: der erste Host in Preference-Reihenfolge, auf dem tatsächlich eine TLS-Sitzung zustande kam – erreichbar zu sein genügt nicht. Die übrigen MX mit TLS-Sitzung werden über Zertifikats-Fingerprint und ausgehandelte Suite verglichen – sind sie identisch, gilt die Liste auch für sie; unterscheiden sie sich, wird das genannt statt enumeriert. Seit Welle MAILTLS-NCSC (2026-09) ist die Einstufung die von Internet.nl, also die der TLS-Sicherheitsrichtlinien 2025-05 von NCSC-NL (Anhang B): eine Positivliste der good- und sufficient-Suites, eine phase-out-Liste, und alles Übrige insufficient. Seit Welle BEWERTUNGSBASIS-1 (2026-09) führt BSI TR-02102-2 dieses Urteil, mit den Internet.nl-Stufen und NIST SP 800-52r2 daneben als Vergleichsspalten.
BewertungDer Status folgt der Regel der Welle BEWERTUNGSBASIS-1 über die akzeptierten Suites UND die Treffer der Familien-Sonden (die insufficient-Familie, die phase-out-Familie, die Static-RSA-Nachsonde und die namentlich abgefragten TLS-1.3-Suites — jede Familie in einer Verbindung angeboten: Static RSA, CBC mit SHA-1, CCM8, NULL-Verschlüsselung, anonyme und PSK/SRP-Suites, auf der phase-out-Seite jede DHE-Suite, ECDHE mit CBC-SHA256/384, Camellia, ARIA): BSI TR-02102-2 führt, Internet.nl und NIST SP 800-52r2 vergleichen — fail, wenn alle drei die schlechteste bewertete Suite verwerfen (die schwachen Familien und die TLS_PSK_WITH_*-Suites, die das BSI als nicht empfohlen führt, während keines der beiden anderen Rahmenwerke sie trägt), warn, wenn das BSI sie als nicht empfohlen führt oder keine Liste sie trägt (Static-RSA-Schlüsseltransport, die übrigen PSK-Suites, die auf keiner Liste stehen, Camellia/ARIA und CBC-Kombinationen, die ebenfalls auf keiner stehen), pass, wenn das BSI sie empfiehlt — jede DHE- und ECDHE-Suite mit AES-GCM, AES-CCM oder AES-CBC-SHA256/384 sowie die AES-Suites von TLS 1.3; ChaCha20-Poly1305 und CBC-SHA1 mit ECDHE bestehen, weil die Liste von Internet.nl oder von NIST sie trägt, „nicht gelistet“ allein kostet also nichts. Die CBC-Suites der Tabellen 1–3 empfiehlt das BSI nur mit Encrypt-then-MAC (RFC 7366), und dieser Scanner misst die Erweiterung nicht: Die Suite-Spalte markiert eine solche Suite mit „nur mit EtM“, und das Finding trägt den Vorbehaltssatz — das pass setzt sie voraus. Sonden und Liste werden zusammen gelesen, und die schlechteste Suite aus beidem entscheidet: Ein Treffer jenseits der Stichprobe zählt, und eine in der Stichprobe gesehene Suite zählt auch dort, wo eine Stufen-Sonde nicht lief. Nicht ermittelt (skip, als nicht gemessen ausgewiesen), wenn eine Stufen-Sonde nicht lief und nichts Bewertetes schlechter als pass ausfiel — nie eine Entwarnung aus der Stichprobe allein. Gewicht 1 und kein Deckel: Das Finding zählt wie jedes andere mit diesem Gewicht in die Modulnote, das Stärke-Cap selbst liegt beim Check „TLS-Version & Cipher-Stärke“, und good, info und skip bleiben ganz aus der Rechnung. Die gelisteten Suites sind eine gedeckelte Stichprobe — 14 Sonden für TLS 1.2, 8 für TLS 1.1/1.0 und die 5 nach Namen abgefragten Suites von TLS 1.3 —, jede mit ihrem BSI-, Internet.nl- und NIST-Urteil in den drei Spalten des Drill-downs, während der Wert des Findings weiterhin die Internet.nl-Zusammenfassung trägt („insufficient: …; phase out: …“). Von dieser Engine nicht anbietbar und deshalb nicht sondiert: 3DES, RC4, DES, EXPORT, statisches DH/ECDH. Eine Enumeration kann auch an unserem eigenen Deckel, an der Frist oder an einem Transportfehler enden, und dann darf sie keine Abwesenheit behaupten: Die Zahlen tragen ein „≥“, und die Liste darf nicht als vollständig gelesen werden. Eine gefundene schwache Suite zählt trotzdem – Vorhandensein braucht keine Vollständigkeit, Abwesenheit schon. skip, wenn gar nichts enumeriert werden konnte und keine Stufen-Sonde geantwortet hat — eine beantwortete Sonde behält ihr Urteil und ihr Gewicht auch ohne Liste; die Liste je Version gibt es nur dort, wo eine Enumeration eine erbracht hat. Dieselbe Form „nicht gemessen“ gilt, absichtlich, für einen Host, der die meisten Verbindungen warten lässt: Brauchten mindestens zwei unserer drei Verbindungen zu ihm (die erste und die zwei Downgrade-Sonden, jede in ihrem eigenen Port-25-Slot gemessen) länger als ein Viertel des Zeitbudgets des Sweeps, wird der Sweep gar nicht gestartet – das Finding nennt jede gemessene Zeit und sagt, dass damit nichts über die Liste des Servers entschieden ist. War das Zeitbudget dieses Scans schon aufgebraucht, bevor die Enumeration überhaupt starten konnte, wird der Check als „nicht gemessen“ ausgewiesen: Sein Gewicht fällt aus dem Nenner, statt als Mangel zu zählen, und der Bericht zeigt, wie viel Abdeckung dadurch fehlt. Mit welchem Hash der MX seinen TLS-1.2-Schlüsselaustausch signiert, messen bis zu zwei zusätzliche Handshakes separat unter „Hash-Funktion für den Schlüsselaustausch (MX)“.
BehebungDen Mailserver auf die von BSI TR-02102-2 empfohlenen Suites beschränken — TLS 1.3 plus ECDHE oder DHE mit AES-GCM, AES-CCM oder AES-CBC-SHA256/384 — oder auf solche, die Internet.nl oder NIST trägt, etwa ChaCha20-Poly1305 mit ECDHE; Static RSA, die PSK-Suites, CCM8, Camellia und ARIA abschalten.
Cipher-Suite-Reihenfolge auf dem MX (TLS ≤ 1.2) #
Internet.nl verlangt von einem Server, der noch phase-out-Suites akzeptiert, dass er good- und sufficient-Suites ihnen vorzieht, damit ein Sender, der beides anbietet, die bessere bekommt. Gemessen, wie Internet.nl es misst: Die phase-out-Familie wird zuerst angeboten, zusammen mit den sufficient-Suites, in einer Verbindung (Sonde A) – ein Server, der der Client-Reihenfolge folgt, wählt eine phase-out-Suite und fällt durch, ein Server, der seine eigene Reihenfolge erzwingt, wählt eine sufficient-Suite. Eine zweite Verbindung (Sonde B), die die sufficient-Suites anbietet, die die enumerierte Liste nicht schon gezeigt hat, wird nur dort aufgebaut, wo sie gebraucht wird: wenn Sonde A eine phase-out-Suite gewählt hat und die Liste keine sufficient-Suite enthält, die sich als die eigentlich fällige benennen ließe, oder wenn die Liste am Deckel dieses Scanners endete, bevor nach jeder sufficient-Suite gefragt war. Geltungsbereich: Gemessen wird die Einstellung unter TLS 1.2 – ein einziger serverweiter Schalter für 1.0/1.1/1.2, weshalb dieser Check „TLS ≤ 1.2“ heißt. Ob er auch die Suite von TLS 1.3 steuert, hängt vom Stack ab: OpenSSL wendet ihn auch dort an, BoringSSL nur mit seiner Server-Präferenz-Option, und Go setzt unabhängig davon seine eigene Reihenfolge durch.
Bewertungwarn mit dem Paar [bevorzugt, erwartet] – der phase-out-Suite, die der Server gewählt hat, und der sufficient-Suite, die er ebenfalls akzeptiert (User-Entscheid E10: Ein Reihenfolgeverstoß auf einem opportunistischen MX ist eine Warnung, kein Durchfallen – die BSI TLS-Checkliste 2.3.5 macht die Server-Priorität zu einem MUSS, der hier gemessene Verstoß betrifft aber die Internet.nl-Reihenfolge good > sufficient > phase out); pass, wenn jede akzeptierte sufficient-Suite über den phase-out-Suites steht; nicht anwendbar (info, Gewicht 0) bei nur TLS 1.3, ohne akzeptierte phase-out-Suite oder wenn der Server überhaupt keine sufficient-Suite anbietet – das Finding nennt, welchen der drei Fälle es gemessen hat, denn „keine phase-out-Suite akzeptiert“ wäre über einen Server, der eine akzeptiert hat, eine falsche Aussage; „nicht entscheidbar“ (info, Gewicht 0), wenn die gedeckelte Suite-Liste die Reihenfolge verbirgt, der Server seine Reihenfolge also erzwingt und unterhalb des Deckels eine weitere sufficient-Suite akzeptiert wird, während oberhalb keine phase-out-Suite erschien; nicht ermittelt (skip, als nicht gemessen ausgewiesen), wenn die Order-Sonde oder die Stufen-Sonde für phase-out nicht lief oder der Cipher-Sweep gar nicht lief. Gewicht 1, wo die Reihenfolge beurteilt wurde, und Gewicht 1, wo eine Sonde von uns sie offen ließ – ein skip gibt dieses Gewicht an die Note zurück, statt null zu zählen, weniger Messung kann die Note also nie heben. Kein Deckel.
BehebungDie phase-out- und insufficient-Suites entfernen – dann ist die Reihenfolge gegenstandslos. Sonst die Server-Cipher-Präferenz einschalten (Postfix: tls_preempt_cipherlist = yes; OpenSSL: SSL_OP_CIPHER_SERVER_PREFERENCE).
Forward Secrecy auf dem MX #
Forward Secrecy bedeutet, dass jede Sitzung ihren eigenen kurzlebigen Schlüssel bekommt — ein heute mitgeschnittener Datenstrom bleibt damit auch dann unlesbar, wenn der private Schlüssel des Servers Jahre später abhandenkommt. Ohne sie — bei einem Static-RSA-Schlüsselaustausch — wird jede aufgezeichnete Sitzung lesbar, sobald dieser eine Schlüssel kompromittiert ist. RFC 9325 §4.1 verlangt, dass Implementierungen Forward-Secrecy-Suites unterstützen und bevorzugen, und RFC 10015 §4 (2026, aktualisiert RFC 9325) verbietet RSA-Schlüsseltransport in TLS 1.2 ganz — Clients dürfen diese Suites nicht anbieten und Server sie nicht auswählen (MUST NOT); §3 tut dasselbe für Finite-Field-DHE, das nur noch als TLS-1.3-Gruppe erlaubt bleibt.
Bewertungwarn, wenn eine geprüfte Verbindung einen Cipher ohne Forward Secrecy ausgehandelt hat oder Finite-Field-DHE auf TLS 1.2 (forward-secret, aber eine Konstruktion, die RFC 10015 §3 als veraltet einstuft — kein Deckel, wie bei statischem RSA); warn auch, wenn der Server eine Suite ohne Forward Secrecy für TLS ≤ 1.2 bloß ANBIETET – gesehen in der gedeckelten Suite-Liste oder gewählt von einer der Stufen-, Order- und Static-RSA-Sonden, wobei eine Nachsonde mit ausschließlich Static-RSA den Fall entscheidet, in dem die Stufen-Sonde eine forward-secrete Suite gewählt hat; sonst pass. „Kein Static RSA“ steht erst dort, wo ein Angebot, das die Static-RSA-Suites enthielt – die ganze insufficient-Familie oder eben jene Nachsonde –, abgelehnt wurde: Eine gedeckelte Liste allein beweist keine Abwesenheit, die Zahl der Suites ohne Forward Secrecy trägt deshalb ein „≥“, wenn die Liste gedeckelt war, und wo keines der beiden Angebote gemacht wurde, sagt das Finding, die Frage sei nicht ermittelt, statt Entwarnung zu geben. Gewicht 1, und bewusst KEIN Notendeckel: Mail auf Port 25 ist opportunistische Sicherheit, und RFC 9325 §5.2 hält fest, dass die eigenen Empfehlungen dort „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“. Das Website-Modul behandelt dieselbe Eigenschaft strenger, weil HTTPS ein Pflicht-TLS-Kanal ist: Ein Client, dem das Angebot nicht passt, kann die Verbindung schlicht ablehnen, und nichts fällt unbemerkt auf Klartext zurück. Es deckelt dort auf B, wo unsere eigene Verbindung gar keine Forward Secrecy bekam, und warnt ohne Deckel, wo der Server lediglich zusätzlich Static-RSA-Suites anbietet. Die Suite-Liste wird nur auf dem primären MX enumeriert; ein Backup-MX, der Static RSA aushandelt, erscheint hier über den Handshake dieser Verbindung (warn), nicht über das Suite-Urteil – eine dokumentierte Grenze (User-Entscheid B2). Norm-Pills: BSI TR-03108-03-M (MUSS: TLS nach TR-03116-4), Internet.nl required, NIST SP 800-52r2 §3.3.1 (may).
BehebungAuf dem Mailserver ECDHE-Suites bevorzugen und die Static-RSA-Suites abschalten — IANA TLS_RSA_WITH_*, in OpenSSL die Namen für TLS ≤ 1.2 ganz ohne Schlüsselaustausch-Präfix (z. B. AES256-GCM-SHA384). Die Regel endet bei TLS 1.2: RFC 9846 §1.3 hat den Schlüsselaustausch aus der Cipher-Suite herausgelöst, TLS_AES_256_GCM_SHA384 und TLS_CHACHA20_POLY1305_SHA256 nennen also gar keinen — jeder vollständige TLS-1.3-Handshake bezieht seine Forward Secrecy aus der getrennt ausgehandelten ephemeren Schlüsselvereinbarung, (EC)DHE oder einer PQ/T-Hybridgruppe (RFC 10024) — und sie müssen aktiviert bleiben.
Stärke der Diffie-Hellman-Parameter (MX) #
Wo ein Mailserver den Schlüsselaustausch über endliche Körper (DHE) statt über elliptische Kurven (ECDHE) fährt, entscheidet die Größe der DH-Gruppe darüber, was die Forward Secrecy tatsächlich wert ist. Logjam hat zwei getrennte Probleme gezeigt: Eine Gruppe unter 1024 Bit lässt sich unmittelbar angreifen, und das Downgrade zwingt eine Verbindung auf Export-Parameter; bei 1024–2047 Bit liegt das Problem anders — weltweit sind nur eine Handvoll Standardprimzahlen im Umlauf, eine einmalige Vorberechnung durch einen finanzstarken Angreifer lohnt sich also und entschlüsselt anschließend aufgezeichneten Verkehr passiv. RFC 9325 §4.1 hält fest, Implementierungen von TLS 1.2 „SHOULD NOT negotiate cipher suites based on ephemeral finite-field Diffie-Hellman key agreement“, und nennt dort eine eigene Begründung — „the known fragility of the construction (see [RACCOON]) and the limitation around negotiation, including using [RFC7919], which has seen very limited uptake“ —, nicht das Vorberechnungs-Argument von oben. Logjam steht in §4.5: DH-Schlüssellängen von mindestens 2048 Bit sind REQUIRED, und „The Logjam attack [Logjam] further demonstrates that 1024-bit Diffie-Hellman parameters should be avoided“. Nichts davon ist auf das Web beschränkt: SMTP auf Port 25 handelt denselben Schlüsselaustausch aus. RFC 10015 §3 (2026, aktualisiert RFC 9325) hat aus diesem SHOULD NOT inzwischen ein MUST NOT für TLS 1.2 gemacht — unabhängig von der Gruppengröße —, lässt ffdhe-Gruppen in TLS 1.3 aber weiterhin zu; auf TLS 1.2 ist die Abhilfe deshalb ECDHE, nicht eine größere Gruppe, und diese Veraltung wird einmal bewertet, im Forward-Secrecy-Finding.
BewertungDie Gruppe wird aus unserem eigenen STARTTLS-Handshake gelesen, wenn dieser DHE benutzt hat, sonst aus der Cipher-Enumeration — ein Mailserver, der uns ECDHE anbietet und DHE nur Sendern, die danach fragen, wäre sonst überhaupt nie gemessen worden, und das ist der häufige Fall. EINE Leiter für Web und Mail seit Welle BEWERTUNGSBASIS-1: pass ab 3000 Bit (BSI TR-02102-2 Tabelle 14; ffdhe3072 und ffdhe4096 stehen namentlich in Tabelle 6 für TLS 1.2 und in Tabelle 10 für TLS 1.3), warn bei 2048–2999 Bit (unter der BSI-Mindestlänge, Internet.nl insufficient, NIST zulässig), fail unter 2048 Bit, was alle drei Rahmenwerke verwerfen. Ob eine Gruppe ab 3072 Bit eine RFC-7919-Gruppe ist, wird nicht beobachtet – dieser Scanner sieht die Größe, nicht die Primzahl –, deshalb steht die „phase out“-Hälfte von Internet.nl unter Vorbehalt (NCSC-NL 2025-05 §3.3.3.1: nur die RFC-7919-Gruppen sind phase out, eine eigene Primzahl derselben Größe ist insufficient). Die ECDH-Kurve unseres eigenen Handshakes wird an derselben Tabelle beurteilt (X25519, X448, P-256/384/521, Brainpool good; secp224r1 phase out; andere Kurven fail): Eine Kurve, die nicht good ist, ergänzt einen Satz in diesem Finding oder wird selbst zum Finding, wo nirgends eine DH-Gruppe zu sehen war, während eine gute Kurve gar nichts erzeugt. Gewicht 1, und bewusst KEIN Notendeckel — aus demselben Grund, aus dem die Forward Secrecy auf dem MX keinen trägt: STARTTLS auf Port 25 ist opportunistische Sicherheit, und RFC 9325 §5.2 hält fest, dass die eigenen Empfehlungen dort „might be too strict, since adhering to them could cause fallback to cleartext, a worse outcome“. Das Website-Modul misst dieselbe Eigenschaft und hält dafür sehr wohl Cap-Buchstaben bereit (F unter 1024 Bit, B bei 1024–2047 Bit), weil HTTPS ein Pflicht-TLS-Kanal ist, in dem nichts hinter dem Rücken des Nutzers auf Klartext zurückfällt — in der Praxis ruhen diese Buchstaben allerdings, aus einem Grund, der unter „Stärke der Diffie-Hellman-Parameter“ im Website-Abschnitt steht: Unser eigener Handshake lehnt eine Gruppe unter 2048 Bit rundweg ab, eine schwache ist also nur über die Enumeration sichtbar, und der Deckel bleibt dem ausgehandelten Fall vorbehalten. Wo das zutrifft, sagt der Text, dass unser Client die Gruppe abgelehnt hat, statt zu suggerieren, der Server halte sie für besondere Sender bereit. Das Finding erscheint gar nicht, wenn weder eine DH-Gruppe noch eine nicht-gute Kurve zu sehen war — ein Server, der ECDHE auf einer guten Kurve nutzt, hat hier nichts zu verantworten.
BehebungAuf TLS 1.2 DHE zugunsten von ECDHE abschalten — RFC 10015 §3 stuft Finite-Field-DHE dort unabhängig von der Gruppengröße als veraltet ein. Bleibt DHE für Sender mit TLS 1.3, die RFC-7919-Gruppen ab ffdhe3072 verwenden – BSI TR-02102-2 Tabelle 6/10 führt ffdhe3072 und ffdhe4096 namentlich, während eine Finite-Field-Gruppe auf der Internet.nl-Skala höchstens „phase out“ erreicht. Die elliptischen Kurven auf X25519 und P-256/384/521 einstellen (OpenSSL: Groups/Curves).
Hash-Funktion für den Schlüsselaustausch (MX) #
Unter TLS 1.2 signiert der Mailserver den ephemeren Schlüsselaustausch (ServerKeyExchange) jeder Forward-Secrecy-Suite, und welcher Hash dabei verwendet wird, handelt die signature_algorithms-Liste des Clients aus. RFC 9155 §4 (2021, aktualisiert RFC 5246) verbietet die gebrochenen rundweg: „Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages“, und ein Client, der eine solche Nachricht erhält, MUSS mit einem illegal_parameter-Alert abbrechen. Die Website-Prüfung misst das unter „Hash-Funktion für den Schlüsselaustausch“; der Mailpfad hatte bis zum 2026-09-14 keinen Zwilling dieser Probe, weil jeder zusätzliche STARTTLS-Handshake einen Port-25-Slot kostet und der Port-25-Footprint das ist, was diesen Scanner von Blacklists fernhält. Jetzt hat er einen, zum Preis von höchstens zwei Verbindungen: ein STARTTLS-Handshake gegen den repräsentativen MX (den Host, den auch die Cipher-Enumeration nutzt), auf TLS 1.2 gepinnt und mit nichts als den SHA-1-Signaturschemata (ECDSA+SHA1, RSA+SHA1) im Angebot, und — nur dort, wo dieser nicht zustande kam — ein zweiter gepinnter Handshake mit nichts als den SHA-224-Schemata (ECDSA+SHA224, RSA+SHA224). Kommt ein Handshake zustande, hat der Server seinen Schlüsselaustausch mit diesem Hash signiert, als ihm nichts anderes angeboten wurde. Ein sendender MTA fragt nie nach SHA-1: Gemessen am 2026-09-14 (Node 24, OpenSSL 3.5.6, Loopback) bringt ein Client mit den Standardeinstellungen von OpenSSL 3 keinen Handshake mit einem Server zustande, der nur mit SHA-1 signieren kann — das OpenSSL-Handbuch verbietet SHA-1- und MD5-Signaturen ab Sicherheitslevel 1, dem Standard —, und unser eigener erster Handshake, der SHA-224 und stärker akzeptiert, ist der Beleg dafür, dass der Server für einen solchen Sender mit einem modernen Hash signiert, sofern er mit uns TLS 1.2 mit einer Forward-Secret-Suite ausgehandelt hat (eine static-RSA-Suite trägt keine Schlüsselaustausch-Signatur und belegt nichts). Seit Welle MAILTLS-NCSC (2026-09) wird die Antwort benotet statt nur angemerkt: NCSC-NL 2025-05 §3.3.5 legt an den Signatur-Hash dieselben drei Stufen an, die die Cipher-Findings dieser Welle schon tragen — SHA-1 insufficient, SHA-224 phase out, SHA-256 und stärker good —, und RFC 9155 §4 ist ein MUST NOT; ein toleriertes SHA-1 ist deshalb ein fail und ein toleriertes SHA-224 ein warn, während der Notendeckel aus demselben Grund ausbleibt, aus dem die Forward Secrecy auf dem MX keinen trägt: opportunistisches STARTTLS. Ein toleriertes SHA-1 ist der Regelfall, nicht die Ausnahme: Gemessen am 2026-09-14 an sieben bekannten Mail-Domains tolerierten fünf repräsentative MX (Google, Microsoft 365, GMX, Posteo, Hornetsecurity) SHA-1, wenn ihnen nichts anderes angeboten wurde; bei den anderen zwei (mailbox.org, internet.nl) blieb das Ergebnis nicht ermittelt — ihr handshake_failure-Alert beweist für sich nicht, dass sie SHA-1 ablehnen. Eine kleine Stichprobe, hier genannt, damit die Entscheidung daran gelesen werden kann. Und genau das ist der Kern der zweiten Hälfte: KEIN Alert des Servers beweist, dass er SHA-1 abgelehnt hat. Ein handshake_failure kann einem signierten Schlüsselaustausch folgen (etwa bei einer späteren Ablehnung des Client-Zertifikats, RFC 5246 §7.4.6), ein empfangener Alert wird deshalb genannt, ohne dass daraus eine Ablehnung gefolgert wird; eine Probe, die in unserem Idle-Timeout, einem Reset, fehlendem STARTTLS oder einem fehlenden Port-25-Slot endete, ist überhaupt keine Antwort, und ein Schweigen auf unserer Seite belegt keine Stärke. Das Finding sagt also nie, ein Server lehne SHA-1 ab — wo der Server beide gepinnten Handshakes mit einem eigenen, benannten Alert beantwortet hat, keinen davon zustande brachte und unser eigener erster Handshake wirklich einen TLS-1.2-Schlüsselaustausch signiert hat, sagt es, dass der Hash über beiden geprüften Stufen liegt, und nennt beide Alerts; überall dort, wo ein Schweigen auf unserer Seite mit im Bild ist, sagt es „nicht ermittelt“. Der eine sachliche Sonderfall: Ein protocol_version-Alert bei einem Server, dessen erster Handshake TLS 1.3 ausgehandelt hat, bietet gar kein TLS 1.2 an, die Regel greift also nicht — eine Aussage über die Version, gegengeprüft, kein Urteil über SHA-1. MD5 lässt sich aus diesem Build heraus nicht anbieten (OpenSSL 3.5 lehnt das Schema ab), die MD5-Hälfte der Regel wird also nicht gemessen, und der Text sagt das.
BewertungGewicht 1 und kein Deckel. fail, wenn der Server den TLS-1.2-Schlüsselaustausch mit SHA-1 signiert, sobald ihm nichts anderes angeboten wird (RFC 9155 §4 MUST NOT; NCSC-NL 2025-05 §3.3.5 unzureichend; Internet.nl: fail) – der SHA-224-Handshake wird dann nicht mehr angefragt, weil diese Antwort bereits die unterste Stufe der Skala ist. warn, wenn er nur mit SHA-224 signiert („phase out“), gemessen mit dem zweiten gepinnten Handshake, der nur dort läuft, wo der SHA-1-Handshake nicht zustande kam; was die SHA-1-Hälfte geantwortet hätte, bleibt dann offen, und der Text nennt, woran jener Handshake endete. pass nur mit positivem Beleg: Unser eigener TLS-1.2-Handshake, dessen Angebot SHA-224 und stärker umfasst, kam mit einem signierten Schlüsselaustausch (ECDHE/DHE) zustande, UND der Server hat beide gepinnten Handshakes mit einem eigenen, benannten Alert beantwortet und keinen davon zustande gebracht. Ein Alert allein beweist nie eine Ablehnung, das Finding nennt deshalb beide Alerts und sagt, was zustande kam, statt etwas darüber zu behaupten, was der Server abgelehnt habe – und ein Schweigen auf unserer Seite bei einer der beiden Sonden (Idle-Timeout, Transportfehler, kein STARTTLS) hält das pass zurück, denn ein Schweigen belegt keine Stärke. info mit Gewicht 0 in zwei Fällen: „nicht anwendbar – kein TLS 1.2“, wenn der Server den zusätzlichen Handshake mit einem protocol_version-Alert beantwortet und auf unserer ersten Verbindung TLS 1.3 ausgehandelt hat, und „nicht ermittelt“ für jeden anderen Zustand, der keine Lücke auf unserer Seite ist – ein einzelner benannter Alert ohne Vergleichsgröße, ein Fehler auf unserer Seite im TLS-Upgrade (unser Idle-Timeout, ein Egress-Fehler) oder kein STARTTLS auf dieser Verbindung. skip, als nicht gemessen ausgewiesen und mit erhaltenem Gewicht, überall dort, wo die zusätzliche Verbindung gar nicht erst zustande kam: kein freier Port-25-Slot in dem Moment, kein Raum im Zeitbudget des Scans, ein Transportfehler oder eine SMTP-Ablehnung eben dieser zusätzlichen Verbindung – eine Messung, die wir schulden und nicht genommen haben, darf den Betreiber weder eine Note kosten noch ihm eine einbringen. Einmal je Scan gemessen, nur am repräsentativen MX, nachdem der erste Handshake gelungen ist; die Sonden laufen nach der Cipher-Enumeration und nehmen einen Slot nur, wenn gerade einer frei ist, sie warten nie, können also weder ein benotetes Finding verzögern noch den Mailbericht über das Timeout des Browsers hinausschieben. Norm-Pills: BSI TLS-Checkliste 2.4.2 (MUSS), Internet.nl required, NIST SP 800-52r2 §3.3.3 (shall).
BehebungDie TLS-1.2-Signaturalgorithmen des Mailservers auf SHA-256 und stärker beschränken — OpenSSL: SignatureAlgorithms ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512. Ein Server auf OpenSSL 3 mit seinem Standard-Sicherheitslevel signiert nicht mit SHA-1, auch wenn das Schema gelistet ist (gemessen auf OpenSSL 3.5); diese Hälfte betrifft also vor allem ältere TLS-Stacks und bewusst abgesenkte Sicherheitslevel. SHA-224 signiert er, anders als SHA-1, auf diesem Standardlevel weiterhin, die Liste muss die SHA-256+-Schemata deshalb ausdrücklich nennen.
Mailserver-Zertifikate #
Für MTA-STS enforce muss das Zertifikat, das der empfangende MX vorzeigt, für den sendenden MTA brauchbar sein: RFC 8461 §4.2 verlangt, dass es „MUST not be expired and MUST chain to a root CA that is trusted by the Sending MTA“ und „a subject alternative name (SAN) with a DNS-ID matching the hostname“ trägt. DANE stellt andere Bedingungen. Bei DANE-TA (Usage 2) ist das vom TLSA-Record getroffene Zertifikat selbst der Trust-Anchor (RFC 6698 §2.1.1) – RFC 7671 §5.2.2 hält fest, es gebe „no expectation that the client is preconfigured with the TA certificate“; eine private CA funktioniert also, und der Absender darf seinen eigenen Truststore ganz ignorieren. Der Name wird trotzdem geprüft — RFC 7672 §3.2.2 macht das für DANE-TA(2) zur Pflicht, anders als für DANE-EE(3) in §3.2.1 —, und der Gültigkeitszeitraum ebenfalls, aber aus einem anderen Grund: Usage 2 verlangt weiterhin, dass die Kette die PKIX-Pfadvalidierung besteht (RFC 6698 §2.1.1, RFC 5280 §6.1.3), wovon §3.2.2 gar nicht spricht. Sofern nicht jeder DANE-TA-Record ein "2 0 0"-Record ist, der das Serverzertifikat vollständig veröffentlicht, muss der Server das Anker-Zertifikat in seiner Kette mitsenden: RFC 7671 §5.2 verlangt das, „unless all such TLSA records are ‚2 0 0‘ records that publish the server certificate in full“, und §5.2.3 dehnt die Pflicht auf "2 1 0"-Records mit vollem Public Key aus. Ein verifizierter DANE-EE-Treffer (Usage 3) pinnt das Zertifikat unmittelbar; die PKIX-Prüfungen auf Name und Ablauf entfallen dort vollständig (RFC 7672 §3.1.1). Bei rein opportunistischem STARTTLS ist eine nicht vertrauenswürdige oder selbstsignierte Kette hinnehmbar.
Bewertungfail, wenn ein Zertifikat abgelaufen oder noch nicht gültig ist – die X.509-Pfadvalidierung verlangt, dass „the certificate validity period includes the current time“ (RFC 5280 §6.1.3(a)(2)) –, oder wenn es für einen anderen Host ausgestellt ist. Die Namensanforderung hat andere Quellen als §6.1.3: MTA-STS verlangt eine SAN-DNS-ID passend zum MX-Hostnamen (RFC 8461 §4.2), bei DANE-TA prüft der Client den Namen gegen die TLSA-Basisdomain (RFC 7672 §3.2.2). Erhoben wird das Finding für jeden geprüften MX, unabhängig davon, welches der beiden Verfahren die Domain nutzt — ein Zertifikat, das diese Prüfungen nicht besteht, weist jeder validierende Absender ab. warn ohne Deckel, wenn der Name nur über den commonName passt, weil das Zertifikat keinen Subject Alternative Name trägt: RFC 8461 §4.2 verlangt die SAN-DNS-ID, ein Sender, der MTA-STS nach dem Wortlaut durchsetzt, weist es also ab, während DANE den commonName-Rückfall behält (RFC 7672 §3.2.3) und opportunistische Sender ohnehin zustellen; öffentlich werden solche Zertifikate nicht mehr ausgestellt (CA/Browser-Forum-BR §7.1.2.7.12). warn bei einem Kettenproblem: eine unvollständige Kette (das Zertifikat selbst ist öffentlich vertrauenswürdig, es fehlt ein Intermediate – Postfix formuliert die Anforderung selbst: Der entfernte SMTP-Client "must receive the issuing CA certificates via the TLS handshake or via public-key infrastructure". Die MTAs auf OpenSSL oder GnuTLS — Postfix, Exim, Sendmail — gehen nur den ersten der beiden Wege: Sie laden nichts per AIA nach, bei diesen Absendern bleibt die Lücke also offen. Browser reparieren sie zwar, aber nicht auf einem Weg: Chrome lädt das fehlende Intermediate per AIA nach (chromium/src, net/cert/cert_verify_proc_builtin.cc, gelesen 2026-08-28), Firefox kennt gar kein AIA-Nachladen und nimmt es aus einer vorgeladenen Menge (mozilla-firefox/firefox main, security/certverifier/CertVerifier.h, enum IssuerSource, gelesen 2026-08-28). Safari wird nicht genannt: Apple veröffentlicht den Code nicht, der darüber entscheiden würde. MTAs über OpenSSL oder GnuTLS — Postfix, Exim, Sendmail — tun weder das eine noch das andere. Für den Windows-Stack ist das Gegenteil dokumentiert: Die Kettenmaschine von .NET darf die AIA-Erweiterung nutzen, um unbekannte Aussteller-Zertifikate zu finden, sofern DisableCertificateDownloads nicht gesetzt ist — der Default ist false (dotnet/runtime, X509ChainPolicy.cs, gelesen 2026-08-28); das darunterliegende Win32-CertGetCertificateChain führt AIA-Abrufe durch, solange CERT_CHAIN_DISABLE_AIA nicht gesetzt ist. Ob eine konkrete Exchange-Installation auf Port 25 überhaupt eine Kette prüft, ist nicht gemessen), eine Kette, die gar nicht validiert, oder eine Kette, die in einer Root endet, die nicht mehr zur aktuellen Mozilla/CCADB-Menge gehört. Zertifikate, die ein verifizierter DANE-EE-Treffer pinnt, sind ausgenommen (RFC 7672 §3.1.1). warn auch im Erneuerungsfenster – die Schwelle richtet sich nach der eigenen Laufzeit des Zertifikats (ein Viertel davon, höchstens 15 Tage), dieselbe Regel wie im Website-Modul; DANE-EE-gepinnte Zertifikate sind ausgenommen, weil RFC 7672 §3.1.1 den Ablauf dort ignoriert. Ein Zertifikat, dessen Gültigkeitsdaten sich gar nicht lesen lassen, ergibt kein Zeit-Urteil: Der Bericht sagt „Gültigkeit unbekannt“, und das Erneuerungsfenster wird nicht angewendet. Ebenso dreiwertig ist der Hinweis auf eine Root außerhalb der aktuellen Mozilla-Menge — ohne brauchbaren CCADB-Stand wird gar kein Anker benannt. Kein Notendeckel: Bei opportunistischem STARTTLS wird trotzdem zugestellt. Gewicht 1. Das Kettenvertrauen wird gegen denselben kombinierten Root-Store geprüft wie im Website-Modul (OS + Node + CCADB) – und weil dieser Store nur hinzufügt, wird ein Anker außerhalb von Mozillas aktueller Menge benannt statt stillschweigend durchgewunken. Seit Welle BEWERTUNGSBASIS-1 trägt der Drill-down eine Spalte „Schlüssel“, und die Schlüsselstärke ist ein eigener Grund: RSA/DSA mit 2048–2999 Bit → warn-Grund (BSI TR-02102-2 Tabelle 14: 3000 Bit; Internet.nl phase out; NIST zulässig), RSA/DSA mit 1024–2047 Bit → warn-Grund, unter 1024 Bit oder EC unter 250 Bit → fail; ein DANE-EE-Pin nimmt den Schlüssel nicht aus, denn ein Pin ändert seine Stärke nicht. Diese fail-Stufe ist aufgeschrieben, nicht erreicht: Auf dem aktuellen Build gemessen lehnt unser eigener Client ein solches Zertifikat rundweg ab – einen RSA-Schlüssel unter 1024 Bit auf seiner Sicherheitsstufe, einen P-224-Schlüssel mangels Signaturalgorithmus –, es kommt also keine Sitzung zustande, in der wir ihn sehen könnten. Die EC-Hälfte: Vermessen werden die NIST-P-Kurven und die Brainpool-Familie (Welle BRAINPOOL-CRASH, 2026-09-21); ein Zertifikat auf jeder anderen Kurve (secp256k1, die binären sect-Kurven) liest sich als „unbekannt“ statt als Urteil, und auch ein Brainpool-Schlüssel unter 250 Bit kommt in keinen Handshake — RFC 8734 definiert Verfahren für TLS 1.3 nur für brainpoolP256r1, P384r1 und P512r1. Norm-Pills: BSI TLS-Checkliste 2.1.1 (MUSS), Internet.nl required, NIST SP 800-52r2 §3.3.3 (shall).
BehebungGültige Zertifikate ausliefern, die zum MX-Hostnamen passen und eine Kette zu einer vertrauenswürdigen CA bilden (oder DANE-EE einrichten), sofern MTA-STS/DANE genutzt wird.
Wildcard-MX-Zertifikat #
Ein Mailserver-Zertifikat mit Wildcard-Namen (*.example.com) deckt mit einem Schlüssel jede direkte Subdomain ab. BSI TR-03116-4 §6.1.2 — über TR-03108-03-M verbindlich für den Mailtransport von Bundesprojekten — verbietet Wildcards im CommonName und SubjectAltName; das CA/Browser Forum erlaubt sie (BR §3.2.2.6). Die Rahmenwerke gehen auseinander, deshalb nennt der Bericht die Wildcard je MX und bewertet nichts.
Bewertunginfo, Gewicht 0 — ohne Einfluss auf die Note. Ob ein Wildcard-Eintrag zum MX-Hostnamen passt, bleibt bei „Mailserver-Zertifikate“.
BehebungFür eine gewöhnliche Mail-Domain nichts zu tun. Wer BSI TR-03108 folgt, stellt je MX-Hostname ein eigenes Zertifikat aus.
Reverse DNS der Mailserver (FCrDNS) #
Forward-Confirmed Reverse DNS bedeutet, dass jede MX-IP einen PTR-Record hat, dessen Hostname wieder auf dieselbe IP auflöst. RFC 1912 §2.1 verlangt die zugrunde liegende Konsistenz – „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“ – und warnt, dass ihr Fehlen „can cause loss of Internet services similar to not being registered in the DNS at all“ bewirken kann. Dass Empfänger es als Anti-Spam-Signal verwenden und Mail von Hosts ohne dieses Signal abweisen oder greylisten, ist verbreitete Betriebspraxis und keine Vorgabe dieser RFC – der größte Empfänger veröffentlicht es allerdings als eigene Regel: Googles Absender-Richtlinien verlangen für sendende Domains oder IPs gültige Vorwärts- und Reverse-DNS-Records und ergänzen, dass die sendende IP-Adresse mit der Adresse übereinstimmen muss, auf die der Hostname im PTR-Record auflöst – das ist Forward-Bestätigung, nur ohne den Namen. Das ist die Richtlinie eines einzelnen empfangenden Anbieters und keine Norm, und sie ist für SENDENDE Hosts geschrieben. Geprüft werden hier die Adressen der MX-Hosts, weil eine Domain genau diese veröffentlicht; versendet eine Domain über dieselben Maschinen, beschreibt das Ergebnis zugleich ihren ausgehenden Ruf.
Bewertungpass, wenn jede geprüfte MX-Adresse forward-confirmed ist; warn, wenn einer der PTR fehlt oder die Forward-Bestätigung scheitert. Eine Adresse, deren Reverse- oder Vorwärts-Abfrage keine eindeutige Antwort lieferte, gilt als ungeprüft – sie steht weder im Zähler noch im Nenner, und der Drill-down kennzeichnet die Zeile entsprechend; eine gescheiterte Abfrage von uns ist keine Aussage über fremdes DNS. Konnte keine einzige Adresse geprüft werden, wird das Finding übersprungen und beeinflusst die Note nicht. Geprüft werden die IPv4- und IPv6-Adressen jedes getesteten MX-Hosts (bis zu 4 je Familie, aus der längeren Liste aufgefüllt bis höchstens 8 Adressen je Host; der Drill-down vermerkt, wenn nur eine Stichprobe noch mehr veröffentlichter Adressen geprüft wurde). Gewicht 1. (Reines DNS – läuft auch, wenn Port 25 blockiert ist.)
BehebungFür jede MX-IP einen passenden PTR-Record einrichten (über den Hoster/ISP), dessen Hostname wieder auf dieselbe IP auflöst.
DANE / TLSA #
DANE bindet das Mailserver-Zertifikat per DNSSEC an einen TLSA-Record und schützt so vor TLS-Downgrade/MITM. DANE ist nur sicher, wenn die TLSA-Antwort DNSSEC-authentifiziert ist.
Bewertungpass, wenn das vorgezeigte Zertifikat zu einem DNSSEC-gesicherten TLSA-Record passt. fail + Cap C in vier Fällen: auf einem der geprobten Hosts passt kein Record; TLSA-Records ohne DNSSEC-Authentifizierung; ein Usage-2-Treffer (DANE-TA) auf ein Zertifikat, das den Namen des Mailservers nicht trägt (RFC 7672 §3.2.2 verlangt die Namensprüfung dort, ausgenommen ist allein Usage 3); und ein Usage-2-Treffer auf ein abgelaufenes Zertifikat – nach RFC 6698 §2.1.1 muss Usage 2 die PKIX-Pfadvalidierung bestehen, wobei der getroffene Record der Vertrauensanker ist, und ein abgelaufenes Zertifikat besteht sie nicht; dass „the expiration date of the server certificate MUST be ignored“ gilt allein für DANE-EE(3) (RFC 7671 §5.1, der im selben Abschnitt von DANE-TA-Betreibern verlangt, Zertifikate „prior to their expiration dates“ zu ersetzen). Gar keine TLSA-Records → warn. Vorhandene, aber durchweg unbrauchbare Records — nur Usage 0/1, oder Usage 2/3 mit einem Selector, Matching-Typ oder einer Digest-Länge, die sich nicht verwenden lässt — werden wie eine Domain ganz ohne TLSA bewertet: warn, Gewicht 2. Ganz ohne Wirkung sind sie nicht (nach RFC 7672 §2.2.3 verpflichtet ein sicherer TLSA-Record sendende MTAs auf STARTTLS), authentifizieren aber nichts; das steht im Text, statt der Note gutgeschrieben zu werden — das DANE-Konfigurations-Finding gibt dafür sein eigenes Gewicht ab, damit derselbe Mangel nicht doppelt zählt. Nicht benotet, weil weder eine gescheiterte Messung von uns noch ein anderswo bereits vermerkter Mangel die Note bewegen darf: keine Verbindung, keine TLS-Sitzung oder ein Scan, in dem unser eigenes Port-25-Budget vor den TLSA-tragenden Hosts endete (info/skip); eine TLSA-Abfrage, die weder eine Antwort noch ein eindeutiges „existiert nicht“ ergab (skip); ein erreichbarer Host, der TLSA veröffentlicht, aber kein STARTTLS anbietet — ein vollständiger Zustellstopp nach RFC 7672 §2.2.3, dessen Note das STARTTLS-Finding trägt (info); und TLSA nur auf MX jenseits der fünf Hosts, die dieser Scanner kontaktiert, wo gar kein Zertifikatsvergleich möglich ist (info). Ein pass, das nicht jeden MX abdecken konnte, nennt die ausgelassenen Hosts. Die Drilldown-Tabelle dieses Findings zeigt eine Zeile je TLSA-Record; ein Record, der nicht passt, während ein anderer passt, ist der Ersatzschlüssel eines Rollovers und wird gelb dargestellt, nicht rot. Gewicht 2.
BehebungDNSSEC aktivieren und TLSA-Records unter _25._tcp.<mx> veröffentlichen (empfohlen: Usage 3, Selector 1, Matching 1).
DANE-Konfiguration #
Das Certificate-Usage-Feld kodiert zwei unabhängige Entscheidungen. PKIX (0/1) verlangt weiterhin, dass das Zertifikat gegen eine öffentliche CA validiert – der TLSA-Record ist nur ein zusätzlicher Pin; DANE (2/3) ersetzt die öffentliche CA und nutzt den DNSSEC-signierten Record selbst als Trust-Anchor, damit funktioniert auch ein privates oder selbstsigniertes Zertifikat. TA (0/2) pinnt die ausstellende CA, Leaf-Zertifikate lassen sich frei erneuern; EE (1/3) pinnt das Zertifikat selbst. Für DANE-TA ein Intermediate statt der Root pinnen: Der Server muss das gepinnte Trust-Anchor-Zertifikat im TLS-Handshake mitsenden (RFC 7671 §5.2), und Roots werden normalerweise nicht gesendet, ein DANE-TA-Record auf eine nicht gesendete Root validiert daher nicht. PKIX-TA (0) ist auf Port 25 nicht der Ausweg: RFC 7672 §3.1.3 sagt, TLSA-Records für diesen Dienst „SHOULD NOT include TLSA RRs with certificate usage PKIX-TA(0) or PKIX-EE(1)“, weil Client-MTAs „cannot be expected to be configured with a suitably complete set of trusted public CAs“. Ein 2 0 0-Record, der das ganze Zertifikat im DNS trägt, erspart das Mitsenden des Ankers, aber beide Spezifikationen raten davon ab – RFC 7671 §5.2.1: „TLSA records with a matching type of Full(0) are NOT RECOMMENDED“, weil Clients die Kette womöglich nicht aus dem DNS ergänzen können. Für SMTP nennt RFC 7672 §3.1 die Empfehlung in einem Satz: „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“. Zu beachten: Der Selector hängt an der Usage – DANE-TA-Veröffentlicher „SHOULD publish records with a selector of Cert(0)“ (§3.1.2), damit die Einschränkungen des Ankers mit dem Record mitreisen – und ein SPKI-Digest übersteht Zertifikatserneuerungen nur mit demselben Schlüssel: Bei einem Schlüsselwechsel ändert sich der Digest, und der Record muss mitgezogen werden. DANE schützt die Zustellung außerdem nur, wenn jeder MX-Host abgedeckt ist: Für einen MX ohne nutzbaren TLSA-Record läuft die Zustellung nach RFC 7672 §2.2.1 „as with pre-DANE opportunistic TLS“ weiter, was Klartext einschließt, wo der Server kein TLS zu unterstützen scheint – und §2.2.1 verbietet, einen bestpriorisierten MX ohne TLSA zugunsten eines abgedeckten zu überspringen. Für den Key-Rollover sollten vorübergehend zwei TLSA-Records existieren.
Bewertungwarn bei PKIX-Usage (0/1); wenn einzelne MX-Hosts keinen nutzbaren TLSA-Record veröffentlichen; und wenn eine veröffentlichte Parameterkombination (Usage/Selector/Matching) keinen Record enthält, der zum aktuell ausgelieferten Zertifikat passt — RFC 7671 §8 verlangt vom Veröffentlicher, jede Kombination aktuell zu halten, und ein Client mit Digest-Agilität (RFC 7671 §9, für SMTP verbindlich nach RFC 7672 §5) bliebe allein mit dem veralteten Record zurück. info, wenn eine Parameterkombination derzeit einen einzigen nutzbaren Record enthält — der normale RUHEZUSTAND und kein Mangel: RFC 7671 §8.1 führt einen Schlüsselwechsel über Initial-RRset (ein Record) → Übergangs-RRset (zwei) → finale RRset (wieder einer), der Eintrag benennt also den Zeitpunkt für den nächsten Schlüsselwechsel, statt den Zustand zu bemängeln — und wenn eine TLSA-Abfrage von uns keine eindeutige Antwort ergab; ein solcher Host wird als ungeprüft benannt und nie als unabgedeckt gezählt. Die Record-Ansicht mit der Rollover-Semantik gehört zum Finding DANE / TLSA darüber. Die Abdeckung wird über jeden MX beurteilt, nicht nur über die fünf, die dieser Scanner kontaktiert: Ob ein Host TLSA veröffentlicht, ist eine DNS-Frage und braucht keine Port-25-Verbindung. Für diese Abfrage gilt eine eigene Grenze von 15 MX — sie ist eine Gesamtgrenze, je mehr Hosts kontaktiert werden, desto weniger bleiben für die reine DNS-Sicht —, und jeder Host darüber hinaus wird im Finding als ungeprüft benannt. Gewicht 0–1, kein Cap: Der Fall der veralteten Kombination trägt immer Gewicht 1, die Abdeckungslücke nur dort, wo das DANE-Finding darüber denselben Mangel nicht bereits benotet hat (sind sämtliche veröffentlichten Records unbrauchbar, trägt jenes Finding die Note allein).
BehebungAuf jedem MX Usage 3, Selector 1, Matching 1 verwenden; während eines Rollovers vorübergehend zwei TLSA-Records veröffentlichen — und jede veröffentlichte Parameterkombination im selben Zug nachziehen.