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: Juli 2026 · 9 Checks dokumentiert
Ohne MX-Records empfängt die Domain keine E-Mail; die Mailserver-Tests werden dann übersprungen.
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).
STARTTLS verschlüsselt die SMTP-Verbindung zwischen Mailservern. Ein MX, der nur Klartext akzeptiert, überträgt Mail ungeschützt.
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 (RC4, 3DES, DES, Export, NULL) noch angeboten wird – ein Angreifer könnte sonst einen Downgrade erzwingen. Die Downgrade-Probes laufen auf der primären Verbindung jedes Hosts (die TLS-Konfiguration gilt je Server, nicht je Adressfamilie).
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 erreichbare Host mit der niedrigsten Preference. Die übrigen erreichbaren MX 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.
Für MTA-STS enforce und PKIX-verankertes DANE-TA müssen die MX-Zertifikate gültig sein, zum Hostnamen passen und eine Kette zu einer öffentlich vertrauenswürdigen CA bilden. (Bei rein opportunistischem STARTTLS ist eine nicht vertrauenswürdige/selbstsignierte Kette tolerierbar; ein verifizierter DANE-EE-Match pinnt das Zertifikat via TLSA, PKIX-Prüfungen greifen dann nicht – RFC 7672 §3.1.1.)
Forward-confirmed Reverse DNS bedeutet: Jede MX-IP hat einen PTR-Record, dessen Hostname wieder auf dieselbe IP auflöst. Empfangende Mailserver setzen das verbreitet als Anti-Spam-Signal voraus; ohne dieses wird Mail von diesen Hosts eher abgewiesen oder per Greylisting verzögert.
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.
_25._tcp.<mx> veröffentlichen (empfohlen: Usage 3, Selector 1, Matching 1).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. Um die Root zu pinnen, PKIX-TA (0) verwenden, das über den Truststore des Clients validiert (Ausnahme: ein 2 0 0-Record, der die vollständige Root im DNS trägt). Für SMTP-DANE werden Usage 3 (DANE-EE) oder 2 (DANE-TA), Selector 1 (SPKI, übersteht Zertifikatswechsel) und Matching 1 (SHA-256) empfohlen – RFC 7672 §3.1.3 empfiehlt, PKIX-Usages (0/1) für den Port-25-SMTP-Dienst nicht zu veröffentlichen, und Clients dürfen sie als unbrauchbar behandeln. DANE schützt die Zustellung außerdem nur, wenn jeder MX-Host abgedeckt ist: Bei MX ohne TLSA fallen Absender auf unauthentifiziertes TLS zurück (RFC 7672 §2.2.1). Für den Key-Rollover sollten vorübergehend zwei TLSA-Records existieren.