Kostenloser MTA-STS Validator

Warum einen Offline-Validator verwenden

Ein MTA-STS-Syntax-Validator analysiert Ihren DNS TXT-Eintrag und Ihre Policy-Datei, ohne sie zu veröffentlichen oder das DNS abzufragen. Dieser Offline-Ansatz deckt drei Schlüssel-Anwendungsfälle ab, die ein Live-Audit nicht abdecken kann.

Typische Anwendungsfälle:

• Vor der Bereitstellung → Validieren Sie einen Policy-Entwurf vor der Veröffentlichung, um Fehlkonfigurationen in der Produktion zu vermeiden.
• Multi-Domain-Vorbereitung → Prüfen Sie mehrere Policies im Batch während einer Migration oder eines internen Audits.
• Offline-Debugging → Reproduzieren und beheben Sie einen Fehler ohne Zugriff auf das öffentliche DNS, z.B. in einer isolierten Umgebung oder Pre-Production.
• Konfigurationsprüfung → Untersuchen Sie einen Eintrag von einem Partner oder ein Export aus einem Drittanbieter-Tool, bevor Sie ihn anwenden.

Der Validator wendet die RFC 8461-Syntaxregeln an: Version, Identifikator, Modus, MX-Muster, max_age, Konsistenz zwischen DNS-Eintrag und Policy. Er verbindet sich mit keinem Server, führt keine DNS-Auflösung durch und lädt keine entfernten Dateien herunter.

So verwenden Sie diesen Validator in 3 Schritten

Schritt 1: Eintrag und Policy einfügen

Sie können drei Kombinationen validieren:

• Nur den _mta-sts TXT-Eintrag (Modus record_only)
• Nur den Inhalt der mta-sts.txt-Policy (Modus policy_only)
• Beides zusammen, um die Konsistenz zu prüfen (kombinierter Modus)

Es wird keine Netzwerkverbindung hergestellt. Ihre Daten bleiben in Ihrem Browser.

Schritt 2: Eine Domain hinzufügen (optional)

Das Hinzufügen einer Domain aktiviert die hybride Validierung: Der Validator löst die MX-Einträge der Domain auf und prüft, ob die in der Policy deklarierten Muster mit den realen Servern übereinstimmen. Dieser Modus hilft, eine zu restriktive Policy oder einen vergessenen MX-Server zu erkennen.

Ohne Domain wird nur die reine Syntax analysiert.

Schritt 3: Das Urteil prüfen

Die Ergebnisse werden nach Schweregrad klassifiziert:

• ❌ Fehler → Blockierendes Problem, die Policy wird von empfangenden MTAs ignoriert
• ⚠️ Warnung → Funktional, aber Verbesserung empfohlen
• ✅ Gültig → Syntax RFC 8461-konform

Beheben Sie jede Warnung, bevor Sie Ihren Eintrag und Ihre Datei in der Produktion veröffentlichen.

Validator oder Record-Check: wann welches Tool

Die beiden Tools ergänzen sich. Sie ersetzen sich nicht: Sie greifen zu unterschiedlichen Zeitpunkten im Lebenszyklus einer MTA-STS-Policy ein.

Empfohlener Workflow:

1. Policy entwerfen → Validator zur Syntaxprüfung
2. DNS + Datei veröffentlichen → Propagation abwarten
3. Record-Check zur Bestätigung des vollständigen Live-Audits

Der Validator erkennt Eingabefehler, bevor sie Ihre Nutzer erreichen. Der Record-Check erkennt Drifts, abgelaufene Zertifikate und HTTPS-Abruf-Probleme, die nur unter realen Bedingungen auftreten.

Validierungsmodi

Der Validator unterstützt vier Modi je nach ausgefüllten Feldern.

Modus record_only

Sie fügen nur den TXT-Eintrag ein. Validierung von:

• v=STSv1-Format
• Vorhandensein und Format des id-Tags
• Unbekannte oder duplizierte Tags

Modus policy_only

Sie fügen nur den Inhalt der Policy-Datei ein. Validierung von:

• version-Direktive
• mode-Direktive (enforce, testing, none)
• mx-Muster (mindestens eines erforderlich)
• max_age-Direktive (Grenzen 0 bis 31557600)

Kombinierter Modus record und policy

Sie fügen beides ein. Vollständige Validierung plus:

• Versionskonsistenz zwischen TXT und Datei
• Intentionskonsistenz (ein mode: none mit einem aktiven id ist verdächtig)

Hybridmodus mit Domain

Fügen Sie eine Domain zum kombinierten Modus hinzu, um zu aktivieren:

• Auflösung der MX-Einträge der Domain
• Prüfung, ob jeder reale MX mit mindestens einem mx:-Muster übereinstimmt
• Erkennung vergessener MX-Server oder zu strikter Muster

Diese MX-Validierung bleibt statisch: Sie vergleicht die Muster mit den deklarierten MX-Hosts, ohne SMTP-Verbindungen zu testen.

Geprüfte Syntaxregeln

DNS-Eintrag

Der Validator wendet die Regeln von RFC 8461 §3.1 auf den TXT-Eintrag _mta-sts.domain an:

Gültiges Beispiel:

v=STSv1; id=20240115120000

Policy-Datei

Der Validator wendet RFC 8461 §3.2 auf mta-sts.txt an:

Gültiges Beispiel:

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

Konsistenz zwischen Eintrag und Policy

Wenn beide bereitgestellt werden:

• Die id im TXT muss einer kohärenten Policy entsprechen (ein Policy-Wechsel impliziert eine neue id).
• mode: none mit einem aktiven TXT wird gemeldet: weist oft auf eine unvollständige Stilllegungsabsicht hin.

MX-Muster und Wildcard-Regeln

RFC 8461 §4.1 definiert ein striktes Format für mx:-Muster. Der Validator wendet folgendes exaktes Matching an.

Exakter Hostname

mx: mail.captaindns.com
mx: smtp.captaindns.com

Passt auf den exakten Hostnamen, ohne Beachtung der Groß-/Kleinschreibung.

Wildcard-Muster

mx: *.mail.captaindns.com

Strikte Regeln:

• Das Wildcard * muss das linkeste Label sein
• Passt auf genau ein Label (server1.mail.captaindns.com passt, a.b.mail.captaindns.com nicht)
• Kein doppeltes Wildcard (**.captaindns.com ist ungültig)
• Kein Wildcard in der Mitte oder am Ende (mail.*.captaindns.com ist ungültig)

Mehrere Muster in einer Policy

Eine Policy kann mehrere mx:-Zeilen enthalten:

mx: mail.captaindns.com
mx: smtp.captaindns.com
mx: *.backup.captaindns.com

Ein realer MX muss zu mindestens einem Muster passen. Der Validator meldet verwaiste reale MX-Hosts, wenn eine Domain angegeben wurde.

Typische ungültige Muster

Häufige Syntaxfehler und Korrekturen

Falsche Version

Ursache: v=sts1, v=STSV1 oder version: stsv1 statt genau STSv1.

Korrektur:

- v=sts1; id=20240115
+ v=STSv1; id=20240115

Fehlender Identifikator

Ursache: Der TXT-Eintrag enthält kein id-Tag.

Korrektur: Fügen Sie eine eindeutige Kennung hinzu (Zeitstempel empfohlen):

v=STSv1; id=20240115120000

Fehlerhaftes id-Format

Ursache: Leerzeichen, Sonderzeichen oder übermäßige Länge in id.

Korrektur: Verwenden Sie nur alphanumerische Zeichen, 1 bis 32 Zeichen.

- id=my policy id
+ id=mypolicyid20240115

Ungültiger Modus

Ursache: mode: strict, mode: ENFORCE oder Tippfehler.

Korrektur: nur einer der drei erlaubten Werte:

- mode: strict
+ mode: enforce

max_age außerhalb der Grenzen

Ursache: negativ, nicht numerisch oder über 31557600.

Korrektur: Ganzzahl in [0, 31557600]. Für Produktion empfohlener Wert: 604800 (1 Woche).

- max_age: 99999999
+ max_age: 604800

Fehlerhaftes Muster

Ursache: falsch platziertes Wildcard oder verbotene Zeichen in einer mx:-Zeile.

Korrektur: siehe Abschnitt MX-Muster oben.

- mx: mail.*.captaindns.com
+ mx: *.mail.captaindns.com

Kein Mailserver-Muster

Ursache: keine mx:-Zeile in einer Policy im Modus enforce oder testing.

Korrektur: Fügen Sie mindestens eine mx:-Zeile hinzu, die zu Ihrer Infrastruktur passt. Im Modus none wird das Fehlen von mx: toleriert.

Ergänzende Tools und Ressourcen

Verwandte Leitfäden

• MTA-STS: Die Komplettanleitung zur Absicherung Ihres E-Mail-Transports - Konfiguration, Bereitstellung und Best Practices.
• MTA-STS-Troubleshooting: häufige Fehler und Lösungen - Policy-Probleme in der Produktion diagnostizieren.
• MTA-STS vom Testing- in den Enforce-Modus überführen - Progressive Migration ohne Beeinträchtigung der Zustellbarkeit.

Spezifikationen

• RFC 8461 - SMTP MTA Strict Transport Security (offizielle Spezifikation)
• MTA-STS DNS-Eintragsformat (§3.1)
• MTA-STS Policy-Dateiformat (§3.2)
• Google MTA-STS-Dokumentation (Workspace-Leitfaden)

FAQ - Häufig gestellte Fragen

F: Was ist der Unterschied zwischen dem Validator und dem MTA-STS-Record-Check?

A: Der Validator analysiert Syntax, die Sie einfügen, vor der Veröffentlichung, ohne das DNS zu berühren. Der Record-Check fragt DNS und HTTPS ab, um die veröffentlichte Konfiguration zu überprüfen. Verwenden Sie den Validator vorgelagert, den Record-Check nachgelagert.

F: Warum MTA-STS-Syntax offline validieren?

A: Um Fehler zu erkennen, bevor sie Ihre Nutzer erreichen. Eine ungültige Policy wird von empfangenden MTAs ignoriert: Ihre Domain bleibt ungeschützt. Besser einen Tippfehler in einem Entwurf beheben, als einen Ausfall in der Produktion diagnostizieren.

F: Was sind häufige Syntaxfehler?

A: Die Klassiker: STSV1 statt STSv1, mode: strict statt enforce, nicht numerisches max_age, falsch platziertes Wildcard (mail.*.captaindns.com), fehlendes id-Tag im TXT oder mehrere version-Zeilen in der Datei.

F: Welche MX-Musterformate sind gültig?

A: Exakter Name (mail.captaindns.com) oder Single-Label-Wildcard in der linkesten Position (*.mail.captaindns.com). Kein nacktes Wildcard, kein doppeltes Wildcard, kein Wildcard in der Mitte eines Namens.

F: Welche max_age-Werte werden empfohlen?

A: RFC 8461 verlangt 0 ≤ max_age ≤ 31557600 (1 Jahr). Gängige Werte: 86400 (1 Tag) für die Testing-Phase, 604800 (1 Woche) für stabile Produktion, 31557600 (1 Jahr) für eine ausgereifte, fixierte Policy.

F: Wie behebe ich einen 'ungültige Version'-Fehler?

A: Die Version muss genau STSv1 sein (Groß-/Kleinschreibung beachten) im TXT (v=STSv1) und in der Policy (version: STSv1). Prüfen Sie Schreibweise, Leerzeichen und das Fehlen von Störzeichen.

F: Wie validiere ich MTA-STS-Syntax für Microsoft 365?

A: Fügen Sie Ihren TXT und Ihre Policy ein. Stellen Sie sicher, dass Ihre MX-Muster *.mail.protection.outlook.com abdecken. Der Validator prüft die RFC 8461-Konformität vor der DNS-Veröffentlichung, danach verwenden Sie den Record-Check nach der Bereitstellung.

F: Wie prüfe ich MTA-STS-Syntax für Google Workspace?

A: Fügen Sie Ihren TXT und Ihre Policy ein. Google MX-Hosts sind unter *.google.com (oder aspmx.l.google.com). Stellen Sie sicher, dass Ihre Muster zu diesen Hostnamen passen, bevor Sie veröffentlichen.