Eingaben
Beispiel
example.com -> _mta-sts TXT id, https://mta-sts.example.com/.well-known/mta-sts.txt, MX-Abdeckung und Starter-Policy.
MTA-STS-Prüfer/Generator
Bewertet MTA-STS-TXT und HTTPS-Policy, vergleicht MX-Abdeckung und zeigt Konformitätsbefunde mit Korrekturhinweisen.
Nutze es vor DNS- oder Policy-Änderungen, damit MTA-STS-TXT, HTTPS-Policy, MX-Abdeckung und Rollout-Modus zusammenpassen.
Warum MTA-STS drei Wahrheiten gleichzeitig braucht
MTA-STS schließt eine echte Lücke: SMTP fällt per Default auf Klartext oder nicht authentifiziertes TLS zurück, und genau diesen Downgrade kann ein Netzwerkangreifer ausnutzen. Der Mechanismus ist einfach zu beschreiben und leicht falsch zu deployen, weil er an drei Orten lebt, die übereinstimmen müssen: ein _mta-sts-TXT-Record, dessen id Policy-Änderungen ankündigt, eine HTTPS-Policy-Datei unter fester Well-Known-URL auf der mta-sts-Subdomain und mx-Einträge in dieser Policy, die die Hosts abdecken müssen, auf die deine MX-Records tatsächlich zeigen. Driftet einer der drei, wird aus der Sicherheitskontrolle ein Zustellrisiko.
Dieser Checker liest alle drei Flächen einer Domain und berichtet sie als ein Deployment: TXT-Syntax und id, Policy-Mode und max-age, MX-Abdeckung gegen das reale MX-Set und optional den TLS-RPT-Kontext. Zusätzlich erzeugt er einen konservativen Starter-Entwurf für einen gestaffelten Rollout — die erste veröffentlichte Policy soll beobachten, nicht erzwingen.
Gestaffelter Rollout ohne Zustellrisiko
Arbeite beim Entwerfen mit eingefügten Werten: TXT-Record, Policy-Text und bekannte MX-Hosts lassen sich lokal prüfen, bevor irgendetwas veröffentlicht ist. Die Abdeckungsprüfung ist der Teil, den man ernst nehmen muss — Enforce-Mode mit einem MX-Host, der in der Policy fehlt, ist der klassische selbstgebaute Ausfall, und genau diesen Fehler fängt ein Diff vor der Publikation.
Rolle in der bewährten Reihenfolge aus: in Testing-Mode mit TLS-RPT veröffentlichen, die Reports so lange beobachten, bis legitime Sender nachweislich abgedeckte Hosts über verifizierbares TLS erreichen, dann auf Enforce wechseln und max-age schrittweise anheben. Jede Policy-Änderung braucht eine neue TXT-id — Sender cachen die Policy für max-age, und die id ist das einzige Signal zum Neuladen. Prüfe nach jedem Schritt erneut; der Live-Modus zeigt, was Sender aktuell auflösen und abrufen.
Lookup-Wege und bewusste Grenzen
Eingefügte Records und Policy-Texte bleiben lokal. Live-Checks lösen DNS zuerst über Cloudflare DNS-over-HTTPS im Browser auf, mit dem Same-Origin-DNS-Fallback, falls dieser Pfad scheitert, und holen die Policy ausschließlich von der festen URL mta-sts.<domain>/.well-known/mta-sts.txt über den Same-Origin-Helper. Es wird keine SMTP-Session geöffnet und kein Zustelltest durchgeführt — geprüft werden die veröffentlichten Policy-Flächen, nicht der TLS-Handshake deines Mailservers; das ist die Aufgabe des SMTP-TLS-Readiness-Checkers.
Häufige Fragen
Was macht die TXT-id genau?
Sie ist ein Cache-Busting-Versionsmarker. Sender cachen die HTTPS-Policy für max-age Sekunden und laden nur bei geänderter id früher nach — eine Policy-Änderung ohne neue id kann deshalb unbemerkt bleiben, bis Caches auslaufen.
Mit welchem Mode sollte die erste Policy live gehen?
Testing. Er bittet Sender, die Policy auszuwerten und Fehler zu melden, ohne das Zustellverhalten zu ändern — Fehlkonfigurationen werden zu Reportzeilen statt zu abgewiesener Mail.
Warum ist die MX-Abdeckung der kritische Check?
Weil die mx-Einträge der Policy definieren, welche Empfangshosts legitim sind. Sind die realen MX-Hosts nicht abgedeckt, wertet ein enforcender Sender die Zustellung dorthin als Policy-Verstoß — im Enforce-Mode bleibt diese Mail liegen.
Wie wählt man max-age?
Anfangs kurz — lang genug, um respektiert zu werden, kurz genug, dass eine kaputte Policy schnell altert. Läuft Enforce stabil, härtet ein höheres max-age die Domain gegen Downgrade-Fenster zwischen zwei Abrufen.
Ist TLS-RPT für MTA-STS Pflicht?
Nein, aber MTA-STS ohne TLS-RPT heißt blind erzwingen. TLS-RPT liefert aggregierte Fehlerreports — der einzige routinemäßige Rückkanal, der zeigt, dass Sender an deiner Policy scheitern, bevor Nutzer fehlende Mails bemerken.
Wie verhält sich MTA-STS zu DANE?
Beide verhindern SMTP-Downgrade-Angriffe. DANE verankert Vertrauen in DNSSEC-signierten TLSA-Records, MTA-STS in HTTPS und der Web-PKI. Beides kann koexistieren — DANE-fähige Sender bevorzugen typischerweise DANE, MTA-STS deckt die große Senderpopulation ohne DANE ab.