Kostenloser MTA-STS Checker

Warum MTA-STS prüfen

Der SMTP-Transport verwendet TLS opportunistisch: Wenn die Verschlüsselung fehlschlägt, fällt die Verbindung stillschweigend auf Klartext zurück. Ein Angreifer in einer Man-in-the-Middle-Position kann das STARTTLS-Banner entfernen und Ihre E-Mails im Klartext über die Leitung erzwingen.

MTA-STS (RFC 8461) schließt diese Lücke. Es veröffentlicht eine über HTTPS bereitgestellte Policy auf Basis öffentlicher PKI, die sendenden MTAs befiehlt, jede Verbindung ohne gültiges TLS abzulehnen. Es ist die fehlende Ebene, die Downgrade-Angriffe und TLS-Spoofing blockiert.

Die Validierung Ihrer Konfiguration vor dem Wechsel zu enforce ist entscheidend:

• Defekte Policy → legitime E-Mails können blockiert werden
• Unvollständige MX-Muster → einige Server bleiben verwundbar
• Abgelaufenes Zertifikat → die Policy wird ungültig, sendende MTAs fallen auf opportunistisches TLS zurück

Häufige Anwendungsfälle:

• Nach der Veröffentlichung → bestätigen, dass DNS, HTTPS-Policy und TLS konsistent sind
• Vor mode: enforce → sicherstellen, dass kein legitimer MX ausgeschlossen ist
• Sicherheitsaudit → den Schutz gegen TLS-Downgrade validieren

So verwenden Sie diesen Checker in 3 Schritten

Schritt 1: Domain zur Analyse eingeben

Geben Sie die Domain genau so ein, wie sie in Ihren E-Mail-Adressen erscheint:

• captaindns.com (Hauptdomain)
• marketing.captaindns.com (Subdomain, wenn Sie von einer Subdomain senden)

Das Tool fragt automatisch _mta-sts.domain ab, ruft https://mta-sts.domain/.well-known/mta-sts.txt ab und vergleicht Muster mit MX-Einträgen.

Schritt 2: Ergebnisse analysieren

Der Checker zeigt an:

Schritt 3: Markierte Probleme beheben

Ergebnisse werden nach Schweregrad klassifiziert:

• Kritisch → die Policy ist unbrauchbar, sendende MTAs ignorieren sie
• Warnung → funktioniert, setzt Sie aber einem Risiko oder Teilschutz aus
• Info → bewährte Praxis, nicht blockierend

Korrigieren Sie DNS oder die Policy-Datei, warten Sie auf die Propagation und starten Sie dann den Checker erneut.

Was ist MTA-STS?

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) ist ein Mechanismus, der:

1. Eine HTTPS-Policy veröffentlicht, die angibt, welche MX-Hosts TLS unterstützen
2. TLS-Verschlüsselung erzwingt zwischen sendenden und empfangenden MTAs
3. Downgrade-Angriffe blockiert, die STARTTLS entfernen

Die Architektur kombiniert drei Elemente:

Beispiel eines DNS-Eintrags:

_mta-sts.captaindns.com. IN TXT "v=STSv1; id=20260501T000000Z"

Beispiel einer Policy:

version: STSv1
mode: enforce
mx: mail.captaindns.com
mx: *.mail.captaindns.com
max_age: 604800

Unterschied zu DANE: MTA-STS stützt sich auf öffentliche PKI (Zertifizierungsstellen), DANE stützt sich auf DNSSEC und TLSA-Einträge. Beide Mechanismen sind kompatibel und können gemeinsam bereitgestellt werden.

Was der Checker prüft

Sieben Dimensionen werden parallel analysiert, um einen 0-100 Score zu erzeugen:

Veröffentlichter DNS-Eintrag

Abruf der Policy-Datei

Policy-Syntax

Abdeckung der MX-Server

Alle aufgelösten MX-Hosts der Domain müssen mindestens einem Muster entsprechen:

• Direkter Treffer: mx: mail.captaindns.com deckt mail.captaindns.com ab
• Wildcard auf ein Label begrenzt: *.mail.captaindns.com deckt eu.mail.captaindns.com ab, jedoch nicht mail.captaindns.com

Gültigkeit des TLS-Zertifikats

Die mta-sts.domain-Subdomain wird über HTTPS abgefragt:

• Zertifikat nicht abgelaufen
• Hostname im SAN vorhanden
• Vollständige Kette zu einer anerkannten CA
• Aktuelle TLS-Version (mindestens 1.2)

Konsistenz von DNS und Policy

Die DNS-ID und die ID der bereitgestellten Policy müssen übereinstimmen. Eine Abweichung deutet auf eine partielle Aktualisierung hin, die für den Cache sendender MTAs gefährlich ist.

Vorhandensein von TLS-RPT

Der Checker meldet das Fehlen eines _smtp._tls-Eintrags (TLS-RPT, RFC 8460). Ohne TLS-RPT erfahren Sie nie, ob die Policy stille Zustellausfälle verursacht.

Häufige Diagnosen und Lösungen

Policy nicht erreichbar (policy_fetch_failed)

Ursache: Die mta-sts.domain-Subdomain antwortet nicht, liefert kein HTTPS oder gibt einen HTTP-Fehler zurück.

Lösungen:

1. Überprüfen, ob mta-sts.domain in DNS aufgelöst wird (A oder CNAME)
2. Sicherstellen, dass ein gültiges TLS-Zertifikat bereitgestellt wird (Let's Encrypt, autocert usw.)
3. Sicherstellen, dass /.well-known/mta-sts.txt mit 200 OK und text/plain antwortet

Ungültiges TLS-Zertifikat (cert_invalid)

Ursache: abgelaufenes Zertifikat, selbstsigniert, Hostname nicht im SAN abgedeckt oder unvollständige Kette.

Lösungen:

1. Zertifikat vor Ablauf erneuern
2. mta-sts.domain in den SAN aufnehmen
3. Vollständige Zwischenkette bereitstellen

Fehlender DNS-Eintrag (missing_record)

Ursache: Kein TXT-Eintrag existiert unter _mta-sts.domain.

Lösung: veröffentlichen

_mta-sts.captaindns.com. IN TXT "v=STSv1; id=20260501T000000Z"

Policy deaktiviert (mode_none)

Ursache: mode: none zeigt an, dass MTA-STS angekündigt, aber wirkungslos ist.

Lösung: nach der Erstveröffentlichung auf mode: testing umstellen, dann auf mode: enforce, sobald TLS-RPT sauber ist.

Unvollständige MX-Abdeckung (mx_partial_match)

Ursache: Ein oder mehrere aufgelöste MX-Hosts entsprechen keinem Muster der Policy.

Lösung: jeden MX-Host explizit auflisten oder ein breiteres Wildcard verwenden, das zu Ihrer Infrastruktur passt.

Fehlendes TLS-RPT (tls_rpt_missing)

Ursache: Kein _smtp._tls.domain-Eintrag ist veröffentlicht.

Lösung: veröffentlichen

_smtp._tls.captaindns.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com"

Fortschritt von testing zu enforce

Phase 1: Erstveröffentlichung im testing-Modus

version: STSv1
mode: testing
mx: mail.captaindns.com
max_age: 86400

• Sendende MTAs melden TLS-Fehler über TLS-RPT, ohne die Zustellung zu blockieren
• Halten Sie max_age kurz (1 bis 7 Tage), um schnell zu iterieren
• Sammeln Sie TLS-RPT-Berichte 2 bis 4 Wochen lang

Phase 2: Stabilisierung und Beobachtung

Überprüfen Sie in dieser Zeit:

• Kein legitimer MX ausgeschlossen (TLS-RPT würde mx-mismatch-Fehler melden)
• Keine Zertifikatsprobleme bei MX-Hosts (TLS-RPT würde certificate-not-trusted melden)
• Kein sendender MTA in Schwierigkeiten (leere oder Null-Berichte)

Phase 3: Wechsel in den enforce-Modus

version: STSv1
mode: enforce
mx: mail.captaindns.com
max_age: 604800

• max_age verlängern (mindestens 7 Tage, bis zu 1 Jahr)
• TLS-RPT kontinuierlich überwachen: Fehler werden nun zu Nicht-Zustellungen
• Rollback-Plan vorbereiten (bei Bedarf schnell zu testing zurückkehren)

Häufige Fallstricke:

• max_age zu kurz → sendende MTAs holen die Policy zu oft erneut, unnötige Last
• max_age zu lang → eine MX-Änderung benötigt Wochen für die Propagation
• Unvollständige MX-Muster → legitime E-Mails werden still abgelehnt

MTA-STS vs DANE

Beide Mechanismen schützen den SMTP-Transport vor Downgrade-Angriffen, aber mit unterschiedlichen Ansätzen.

Wann MTA-STS wählen: Sie haben kein DNSSEC oder wünschen eine schnelle Bereitstellung mit minimalem operativem Aufwand.

Wann DANE wählen: Ihre Domain ist bereits DNSSEC-signiert und Sie wollen die zusätzliche Garantie des kryptografischen Pinning.

Beide sind kompatibel und können parallel bereitgestellt werden. Sendende MTAs wählen den Mechanismus, den sie verarbeiten können.

Ergänzende Tools und Ressourcen

Ressourcen:

• MTA-STS: die Komplettanleitung zur Absicherung Ihres E-Mail-Transports
• MTA-STS Troubleshooting-Anleitung
• MTA-STS von testing zu enforce wechseln
• MTA-STS vs DANE: Vergleich
• TLS-RPT: die Komplettanleitung
• RFC 8461 - SMTP MTA Strict Transport Security
• RFC 8460 - SMTP TLS Reporting