MTA-STS: eine überprüfbare TLS-Policy für Ihren Mailtransport

Die Policy schützt nur, soweit der sendende Mailserver sie unterstützt und eine gültige Policy erhalten hat. Sie ersetzt weder die Absenderauthentifizierung durch SPF, DKIM und DMARC noch eine Ende-zu-Ende-Verschlüsselung des Nachrichteninhalts.

Warum STARTTLS allein eine Lücke lässt

DNS-Hinweis, HTTPS-Policy und SMTP-Prüfung

Für gewöhnliche direkte Zustellung an person@example.com ist example.com die Policy-Domain. Explizite Routingregeln zu einem Smarthost können den nächsten Transportabschnitt und damit die Policyauswahl ändern. Eine Policy für die Hauptdomain wird nicht automatisch für jede Unterdomain gesucht: Für eine andere Policy-Domain gelten eigene Abfragen. RFC 8461 §3.4

Der DNS-Eintrag kündigt einen Stand an

Das folgende synthetische Zonenbeispiel verwendet ausschließlich Beispieldomains. Es wurde nicht veröffentlicht oder praktisch getestet.

_mta-sts.example.com. IN TXT "v=STSv1; id=2026091301"

v=STSv1 steht zuerst. Die id besteht aus 1 bis 32 Buchstaben oder Ziffern und muss die jeweilige Policyversion eindeutig kennzeichnen. Ein Datumsformat ist möglich, aber nicht vorgeschrieben; eine neue Uhrzeit oder eine fortlaufende Kennung kann mehrere Änderungen am selben Tag unterscheiden. Eine größere Zahl hat keine besondere Protokollbedeutung.

Nach dem Verwerfen fachfremder TXT-Records muss genau ein passender, syntaktisch gültiger Record übrig bleiben. Mehrere Zeichenketten innerhalb desselben TXT-Records werden ohne zusätzliche Leerzeichen zusammengesetzt. Die Entdeckung kann auch über einen CNAME delegiert werden. Ein fehlender oder unbrauchbarer Record löscht jedoch keine zuvor gültig gespeicherte Policy. RFC 8461 §3.1

Die Policy kommt von einem festen HTTPS-Ziel

Für diese Beispieldomain lautet die vollständige Adresse:

https://mta-sts.example.com/.well-known/mta-sts.txt

Das Zertifikat dieses HTTPS-Hosts muss zum Namen mta-sts.example.com passen, gültig sein und zu einer vom Sender vertrauten Zertifizierungsstelle führen. Ein CNAME auf einen Hostinganbieter ändert den zu prüfenden Namen nicht. Die Antwort muss direkt HTTP 200 liefern; Weiterleitungen dürfen beim Policyabruf nicht verfolgt werden. Die Datei soll als text/plain ausgeliefert werden; RFC 8461 formuliert die Medientypprüfung durch Sender als SHOULD. Eine HTML-Fehlerseite ist keine Policy. RFC 8461 §3.2–3.3

Synthetisches Dateibeispiel für eine Testphase mit zwei vorgesehenen MX-Hosts:

version: STSv1
mode: testing
mx: mx1.example.com
mx: mx2.example.com
max_age: 86400

mx: *.example.com erfasst genau ein zusätzliches linkes Label, etwa mail.example.com. Es erfasst weder example.com noch a.mail.example.com. Für mehrere Namen verwenden Sie mehrere mx:-Zeilen. Bei internationalisierten Domainnamen erwartet die Policy die ASCII-Darstellung als A-Label. Der Wert 86400 im Beispiel entspricht einem Tag; er ist kein vorgeschriebener Standardwert.

Für den SMTP-MX prüft der Sender gesondert, ob dessen Name zur Policy passt, STARTTLS nutzbar ist und ein gültiges, vertrauenswürdig verkettetes Zertifikat zum tatsächlichen MX-Hostnamen vorliegt. Das HTTPS-Zertifikat der Policy und das SMTP-Zertifikat des MX sind zwei verschiedene Nachweise. RFC 8461 §4–5.1

testing, enforce und none richtig einordnen

enforce ist eine bewusst eingegangene Betriebsbindung. Ein nicht mehr passender MX-Name, ein abgelaufenes Zertifikat oder fehlendes STARTTLS kann die Übertragung verhindern. Das gilt auch für einen selten verwendeten Backup-MX. Unauffälliger Verkehr zum primären MX ist kein Nachweis für alle Ausweichwege. RFC 8461 §8.4

TLS-RPT: Berichte über Transportversuche verstehen

TLS-RPT ist in RFC 8460 getrennt von MTA-STS beschrieben. Unterstützende Sender können zusammengefasste Angaben zu TLS-Verbindungen und Policyproblemen übermitteln. Die empfangende Domain veröffentlicht dafür ein Berichtsziel. Das kann bei der Einführung helfen, ist aber keine vollständige Beobachtung sämtlicher Absender oder Nachrichten.

Ein synthetisches DNS-Beispiel für ein zuvor eingerichtetes Empfangspostfach:

_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

Mehrere Ziele sind möglich, hier als alternative Beispielkonfiguration mit einem eingerichteten HTTPS-Empfänger:

_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com,https://reports.example.com/tlsrpt"

Tragen Sie nur Ziele ein, für deren Empfang und Auswertung Sie zuständig sind oder eine entsprechende Vereinbarung haben. Ein meldender Sender darf bei mehreren Zielen eines auswählen; nicht jedes Ziel erhält zwangsläufig jede Meldung. Eine statisch gehostete Policydatei ist kein HTTPS-Berichtsempfänger. RFC 8460 §3, verifiziertes Erratum 8070

Zeitraum, Zahlen und Übertragung

Ein Report enthält einen Zeitraum, eine Kennung, Angaben zum meldenden Betreiber, die beobachtete Policy und zusammengefasste Ergebnisse. Ein vollständiger UTC-Tag ist die Empfehlung der Norm. Versandverzögerungen und fehlende Berichte sind möglich. Erfolgszahlen beziehen sich auf entsprechende TLS-Sitzungen, nicht auf im Posteingang angekommene Nachrichten. Fehlerkategorien können sich überschneiden; sie lassen sich nicht beliebig zu einer Zahl unabhängiger fehlgeschlagener Nachrichten addieren. RFC 8460 §4

Für den Berichtstransport gelten besondere Regeln: E-Mail-Berichte benötigen eine gültige DKIM-Signatur der meldenden Domain ohne l=-Begrenzung. s=tlsrpt am DKIM-Schlüssel ist in RFC 8460 eine SHOULD-Vorgabe, keine allgemeine zusätzliche MUST-Vorgabe; offene beziehungsweise zurückgestellte Errata betreffen ihre Registrierung. Eine fehlende gültige DKIM-Signatur ist ein anderer Fall. Bei der Übertragung von Fehlerberichten dürfen SMTP-TLS-Probleme den Bericht nicht selbst unterdrücken; dabei kann der Bericht unverschlüsselt übertragen werden. Für HTTPS-Berichte erlaubt die Norm dem Sender, Zertifikatsfehler zu ignorieren. Diese Ausnahme gilt nicht für den HTTPS-Abruf der MTA-STS-Policy. RFC 8460 §3, Erratum 8303, Status Reported

Berichte können als JSON oder gzip-komprimiert ankommen. Ein HTTPS-Empfänger muss eine erfolgreiche Antwort geben, typischerweise 200 oder 201; die Verarbeitung kann später erfolgen. Weder eine erfolgreiche HTTP-Annahme noch ein vorhandener Mailanhang beweist schon eine abgeschlossene Auswertung. TLS-RPT-Berichte sind keine Wolf-Reportdateien.

Ein erfundener Bericht als Lesehilfe

Das folgende JSON-Modell zeigt einen einzelnen Policystand und einen Fehlertyp. Betreibername, Kennung, Zeitraum, Adressen und sämtliche Zahlen sind erfunden. Es ist kein empfangener Report und kein Testnachweis; der E-Mail-/HTTP-Umschlag ist nicht dargestellt.

{
  "organization-name": "Example Sender",
  "date-range": {
    "start-datetime": "2026-09-11T00:00:00Z",
    "end-datetime": "2026-09-12T00:00:00Z"
  },
  "contact-info": "postmaster@sender.example.net",
  "report-id": "example-report-01",
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-string": [
          "version: STSv1",
          "mode: enforce",
          "mx: mx1.example.com",
          "max_age: 604800"
        ],
        "policy-domain": "example.com",
        "mx-host": ["mx1.example.com"]
      },
      "summary": {
        "total-successful-session-count": 120,
        "total-failure-session-count": 2
      },
      "failure-details": [
        {
          "result-type": "certificate-expired",
          "sending-mta-ip": "192.0.2.10",
          "receiving-mx-hostname": "mx1.example.com",
          "receiving-ip": "203.0.113.20",
          "failed-session-count": 2
        }
      ]
    }
  ]
}

Die Meldung beschreibt im Modell ein abgelaufenes Zertifikat bei zwei erfassten Sitzungen. Sie beweist weder die Ursache jeder fehlenden Nachricht noch einen Angriff. Zur Untersuchung gehören der angegebene Zeitraum, der betroffene Host, die damalige Policy und passende Serverlogs.

Fehlerbezeichnungen gezielt zuordnen

Diese Kategorien ersetzen keine Ursachenanalyse. Ein Bericht muss nicht jeden vorübergehenden Netzwerkfehler enthalten. Eine syntaktisch gültige Policy kann außerdem einen benötigten MX ausschließen; dafür reicht ein Syntaxtest nicht aus. RFC 8460 §4.3

Einführung, Änderungen und Rücknahme planen

Die Dauer einer Einführung hängt von Ihrer Infrastruktur und den tatsächlich verfügbaren Beobachtungen ab. Zwei fehlerfreie Kalenderwochen allein belegen weder Senderabdeckung noch einen funktionierenden Backup-MX.

Veröffentlichen Sie bei einer Änderung zuerst die neue HTTPS-Policy und anschließend die neue DNS-id. Ein DNS-Update allein ersetzt nicht alle Sendercaches. Längere max_age-Werte können die Bindung über Abrufstörungen hinweg erhalten, verlängern aber auch die mögliche Wirkung alter Regeln. Eine kürzere neue Laufzeit verkürzt nicht rückwirkend jede zuvor gespeicherte Policy. RFC 8461 §8.1

Für eine geplante Abschaltung sieht die Norm mode: none vor. Veröffentlichen Sie diese gültige Policy mit kleiner Laufzeit und neuer id. Halten Sie DNS und HTTPS-Endpunkt verfügbar, bis alle zuvor ausgelieferten Policies abgelaufen sind. Dazu zählen gegebenenfalls ältere Stände mit längerer Laufzeit. TXT und Datei sofort zu löschen ist keine verlässliche Rücknahme. RFC 8461 §8.3

MTA-STS und DANE verwenden unterschiedliche Vertrauenswege

MTA-STS ist kein Ersatz für DNSSEC und kein Zertifikatspinning. SMTP-DANE ist seinerseits keine Ende-zu-Ende-Verschlüsselung. Welche Variante ein Anbieter für eingehende beziehungsweise ausgehende Nachrichten unterstützt, ist getrennt zu prüfen. Prüfen Sie die konkrete Dokumentation Ihres Versanddienstes einschließlich der verwendeten Connector- und Routingfälle. RFC 8461 §2, RFC 7672 §3

Aussagegrenzen: Transport, Recht und Prüfergebnis

MTA-STS kann einen abgegrenzten Beitrag zum Schutz des Transportwegs leisten. Es authentisiert nicht den sichtbaren Absender und bewertet keinen Nachrichteninhalt. Ein verschlüsselter Transport macht eine Phishingmail nicht ungefährlich. Mehr zum Zusammenhang: E-Mail-Bedrohungen und DNS-Sicherheit.

Rechtliche Anforderungen hängen vom Anwendungsbereich und Risiko ab. Art. 21 NIS2 nennt für erfasste Einrichtungen angemessene Risikomanagementmaßnahmen einschließlich Kryptografie; Art. 32 DSGVO behandelt risikogerechte Sicherheit der Verarbeitung. Daraus ergibt sich keine pauschale Aussage, dass jede Domain gerade MTA-STS einsetzen muss. Die BSI TR-03108 richtet sich an E-Mail-Diensteanbieter und beschreibt eigene Anforderungen an sicheren Transport. Eine einzelne Policy oder ein Scan ist keine Bescheinigung der Einhaltung dieser Regelwerke. Diese Einordnung betrifft die genannten EU-/deutschen Bezüge, nicht eine weltweite Rechtsbewertung. NIS2 Art. 21, DSGVO Art. 32, BSI TR-03108

Der kostenlose E-Mail Security Check untersucht veröffentlichte DNS-Einträge, die abrufbare MTA-STS-Policy und deren Abdeckung der im Check bekannten DNS-MX-Namen. Das beweist weder die tatsächliche Durchsetzung bei allen Sendern noch TLS-Verbindungen zu sämtlichen MX-Adressen oder den Zustand fremder Sendercaches. Der TLS-RPT-DNS-Check liest Reporting-Ziele; er empfängt oder analysiert keine JSON-Berichte und bestätigt keine Reportzustellung. Ein Abruf- oder Messfehler ist von einer bestätigten Fehlkonfiguration zu unterscheiden.

Ein kostenloser Befund kann für Ihre nächste Korrektur genügen. Für die Abnahme einer Änderung ergänzen Sie die konkret benötigten Betriebsnachweise; DNS-Sicht, Policyabruf, SMTP-Verbindung und empfangener Bericht bleiben getrennte Belege.

Verwandte Grundlagen

Vorheriges Kapitel: DMARC-Enforcement. Nächstes Kapitel: SMTP-TLS und Zertifikate.