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: September 2026 · 13 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 (4xx-Begrüßung, etwa ein Ratenlimit), 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; warn, wenn TLS ≤ 1.1 angeboten wird; fail + Cap C, wenn ein schwacher Cipher akzeptiert wird. Gewicht 2. 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. Das Cap ist der Stärke-Deckel dieses Moduls: eine veraltete Version allein deckelt nicht, ein schwacher Cipher schon.
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 je 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.
Bewertungpass, wenn keine der enumerierten Suites schwach ist; warn, wenn eine schwache Suite angeboten wird (das Stärke-Cap selbst liegt beim Check „TLS-Version & Cipher-Stärke“). Gewicht 1 – das Finding zählt wie jedes andere mit diesem Gewicht in die Modulnote; good, info und skip bleiben ganz aus der Rechnung. 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 der Satz über fehlende schwache Suites entfällt. Eine gefundene schwache Suite zählt trotzdem – Vorhandensein braucht keine Vollständigkeit, Abwesenheit schon. skip, wenn gar nichts enumeriert werden konnte; 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.
BehebungAEAD-Suites (AES-GCM, ChaCha20-Poly1305) mit ECDHE-Schlüsselaustausch bevorzugen; reine CBC- und Static-RSA-Suites (keine Forward Secrecy) deaktivieren, wo die Kompatibilität es zulässt.
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 dass Cipher-Suites mit RSA-Schlüsseltransport („static RSA“) SHOULD NOT ausgehandelt werden.
Bewertungwarn, wenn eine geprüfte Verbindung einen Cipher ohne Forward Secrecy ausgehandelt hat, sonst pass. 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.
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 (EC)DHE — 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.
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. fail unter 1024 Bit, warn unter 2048, sonst pass; zwischen 2048 und 3072 benennt der Text die Uneinigkeit der Quellen, statt ein bloßes Grün zu drucken (SSL Labs 2009r deckelt erst unter 2048, NCSC-NL 2025-05 stuft ffdhe2048 als unzureichend ein, BSI TR-02102-2 in der Fassung 2026-01 verlangt 3000 Bit). 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, B unter 2048), 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 keine DH-Gruppe zu sehen war — ein Server, der ausschließlich ECDHE nutzt, hat hier nichts zu verantworten.
BehebungDie DH-Parameter des Mailservers auf mindestens 2048 Bit anheben (3072 bzw. die Standardgruppen ffdhe3072/4096, wenn man den europäischen Vorgaben folgt) — oder DHE ganz abschalten und nur ECDHE anbieten, womit sich die Frage erübrigt.
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 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.
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.
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.