MTA-STS & TLS-RPT Guide: STRIPTLS-Schutz einrichten

Email Security · Transport

Das Problem: STRIPTLS-Angriffe auf die E-Mail-Verschlüsselung

SMTP wurde 1982 ohne Verschlüsselung entworfen. STARTTLS wurde nachgerüstet, ist aber optional — ein Angreifer im Netzwerkpfad kann das STARTTLS-Kommando entfernen und die gesamte E-Mail-Kommunikation im Klartext mitlesen. Dieser STRIPTLS-Angriff ist trivial durchführbar und auf nationaler Netzwerkebene dokumentiert. MTA-STS (RFC 8461) schließt diese Lücke, indem es TLS-Verschlüsselung erzwingt.

Ohne MTA-STS hat ein sendender Mailserver keine Möglichkeit zu wissen, dass Ihr Server TLS erfordert. Er kann nur hoffen, dass STARTTLS angeboten wird. MTA-STS mit TLS-RPT bringt bis zu 15 von 165 Punkten im Wolf-Agents Email Security Check — und ist eine direkte Anforderung aus NIS2 Art. 21 Abs. 2 lit. h (Kryptografie und Verschlüsselung).

STRIPTLS Nation-State-Angriffe dokumentiert — Tunesien und Thailand entfernten STARTTLS auf Netzwerkebene (EFF 2014) EFF STARTTLS Everywhere

Opportunistic STARTTLS ist optional — ohne MTA-STS hat kein sendender Server eine Garantie, dass TLS erzwungen wird RFC 3207

15 Punkte MTA-STS (10) + TLS-RPT (5) im Wolf-Agents Email Security Check — 165 Punkte gesamt Wolf-Agents Scanner

RFC 8461

Wie MTA-STS funktioniert: Drei Komponenten erzwingen TLS

MTA-STS besteht aus drei Komponenten, die zusammenwirken: Ein DNS-TXT-Record unter _mta-sts signalisiert die Existenz einer Policy, eine HTTPS-gehostete Policy-Datei definiert die erlaubten MX-Hosts und den Enforcement-Modus, und ein TLS-RPT-Record aktiviert das Reporting über TLS-Verbindungsprobleme. Der sendende Mailserver prüft den DNS-Record, holt die Policy per HTTPS und erzwingt TLS bei der Zustellung.

1

DNS-TXT-Record

_mta-sts.ihre-domain.de. IN TXT "v=STSv1; id=20260408120000"

Signalisiert sendenden Servern, dass eine MTA-STS-Policy existiert. Der id-Wert muss sich bei jeder Policy-Änderung ändern — Timestamp empfohlen.

2

HTTPS Policy-Datei

version: STSv1
mode: testing
mx: mx1.ihre-domain.de
mx: mx2.ihre-domain.de
max_age: 86400

Die eigentliche Policy — über HTTPS mit gültigem Zertifikat ausgeliefert. Definiert MX-Hosts, Modus und Cache-Dauer. Die MX-Einträge müssen exakt mit Ihren DNS-MX-Records übereinstimmen.

3

TLS-RPT DNS-Record

_smtp._tls.ihre-domain.de. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@ihre-domain.de"

Aktiviert tägliche JSON-Reports über TLS-Verbindungsprobleme. Ohne TLS-RPT wissen Sie nicht, ob MTA-STS Zustellungen blockiert.

Ablauf bei eingehender E-Mail

Sendender MTA prüft:
    |
    v
1. DNS-Lookup: _mta-sts.example.com TXT
    |
    +--> Kein Record? --> Normales Verhalten (opportunistic TLS)
    |
    +--> Record gefunden: "v=STSv1; id=20260215120000"
         |
         v
2. HTTPS-Abruf: https://mta-sts.example.com/.well-known/mta-sts.txt
         |
         v
3. Policy lesen: mode=enforce, mx=mx1.example.com, max_age=604800
         |
         v
4. TLS erzwingen + Zertifikat prüfen + MX validieren
         |
         +--> TLS erfolgreich? --> E-Mail zustellen
         |
         +--> TLS fehlgeschlagen? --> E-Mail NICHT zustellen (bei enforce)
                                      Report senden (bei TLS-RPT)

Policy

MTA-STS-Modi: Von Testing zu Enforce — wie bei DMARC

MTA-STS kennt drei Modi, die unterschiedliche Enforcement-Stufen darstellen. Der Testing-Modus beobachtet ohne Risiko für die Zustellung, Enforce erzwingt TLS und lehnt unverschlüsselte Verbindungen ab. Die Analogie zu DMARC ist direkt: testing entspricht p=none, enforce entspricht p=reject. Starten Sie immer im Testing-Modus und wechseln Sie erst nach 2-4 fehlerfreien Wochen zu Enforce.

mode: testing

Beobachten

Sendende Server prüfen TLS, stellen aber auch bei Fehlern zu. TLS-Probleme werden per TLS-RPT gemeldet. Kein Risiko für die E-Mail-Zustellung — ideal zum Start.

5 von 10 Punkten

mode: enforce

Maximaler Schutz

Sendende Server müssen TLS verwenden. Bei TLS-Fehlern wird die E-Mail nicht zugestellt — temporärer Fehler mit Retry. Zertifikat des empfangenden Servers wird validiert.

10 von 10 Punkten

mode: none

Deaktiviert

Deaktiviert MTA-STS explizit. Wird verwendet, um eine zuvor veröffentlichte Policy zurückzuziehen. Sendende Server löschen ihren Cache nach max_age.

0 Punkte

Policy-Parameter im Detail

Parameter	Pflicht	Werte	Beschreibung
`version`	Ja	`STSv1`	Protokollversion — immer STSv1
`mode`	Ja	`testing` \| `enforce` \| `none`	Policy-Modus — testing zum Start, dann enforce
`mx`	Ja	Hostname oder Wildcard	Autorisierte MX-Hosts — muss exakt mit DNS-MX-Records übereinstimmen
`max_age`	Ja	Sekunden	Cache-Dauer: 86400 (1 Tag) für Testing, 604800 (1 Woche) für Enforce

RFC 8460

TLS-RPT: Reporting über Transport-Verschlüsselungsprobleme

TLS-RPT (TLS Reporting, RFC 8460) ist das Monitoring-Werkzeug für MTA-STS. Sendende Mailserver senden tägliche JSON-Reports, die zeigen, wie viele TLS-Verbindungen erfolgreich waren und welche Fehler auftraten. Ohne TLS-RPT fliegen Sie blind — im Enforce-Modus bedeutet ein TLS-Fehler, dass E-Mails nicht zugestellt werden, und Sie erfahren davon erst durch Beschwerden.

DNS-Record einrichten (zwei rua-Optionen)

_smtp._tls.ihre-domain.de. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@ihre-domain.de"

RFC 8460 erlaubt zwei Reporting-Methoden: mailto: (Reports per SMTP) und https: (Reports per POST mit HTTP 200/201). Beide können kombiniert werden — kommagetrennt:

_smtp._tls.ihre-domain.de. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@ihre-domain.de,https://tlsrpt.ihre-domain.de/v1"

Bei mailto:-Reports verlangt RFC 8460 eine DKIM-Signatur des Reports mit Service-Type s=tlsrpt im DKIM-Key. Bei https:-Reports dürfen Submitter Zertifikatsfehler ignorieren (RFC 8460 § 3) — der Server muss HTTP 200 oder 201 zurückgeben.

JSON-Report Beispiel (vereinfacht)

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-02-14T00:00:00Z",
    "end-datetime": "2026-02-15T00:00:00Z"
  },
  "policies": [{
    "policy": {
      "policy-type": "sts",
      "policy-string": ["version: STSv1", "mode: enforce", "mx: mx1.example.com", "max_age: 604800"],
      "policy-domain": "example.com"
    },
    "summary": {
      "total-successful-session-count": 1247,
      "total-failure-session-count": 3
    },
    "failure-details": [{
      "result-type": "certificate-expired",
      "sending-mta-ip": "209.85.220.41",
      "receiving-mx-hostname": "mx1.example.com",
      "failed-session-count": 3
    }]
  }]
}

1.247 erfolgreiche TLS-Verbindungen, 3 Fehlschläge durch abgelaufenes Zertifikat. Ohne TLS-RPT wären diese 3 fehlgeschlagenen Zustellungen unbemerkt geblieben.

Wichtige Fehlertypen

Die fünf Result Types unten kommen aus zwei RFC-8460-Sektionen: Negotiation Failures (§ 4.3.1) erfassen TLS-Handshake-Probleme zum MX-Host, Policy Failures (§ 4.3.2) speziell MTA-STS- und DANE-Probleme beim Policy-Abruf. Negotiation-Result-Types werden in SMTP-TLS-Kapiteln vertieft, Policy-Result-Types sind MTA-STS-spezifisch.

Fehlertyp	RFC 8460 § 4.3	Bedeutung	Handlung
`starttls-not-supported`	§ 4.3.1 Negotiation	MX-Server bietet kein STARTTLS	TLS auf dem Mailserver aktivieren
`certificate-expired`	§ 4.3.1 Negotiation	Zertifikat abgelaufen	Zertifikat erneuern
`certificate-host-mismatch`	§ 4.3.1 Negotiation	Hostname stimmt nicht	Zertifikat für korrekten MX-Hostnamen ausstellen
`sts-policy-fetch-error`	§ 4.3.2 Policy	Policy-Datei nicht abrufbar	HTTPS-Erreichbarkeit prüfen
`sts-webpki-invalid`	§ 4.3.2 Policy	Zertifikat der Policy-Datei ungültig	Zertifikat für mta-sts-Subdomain erneuern

Roadmap

Deployment-Roadmap: Von Null auf Enforce in 5 Wochen

Die sichere MTA-STS-Einführung folgt einem bewährten 5-Wochen-Plan: Zuerst TLS-RPT für Sichtbarkeit, dann MTA-STS im Testing-Modus, Reports auswerten, auf Enforce umschalten und abschließend max_age erhöhen. Überspringen Sie keine Phase — der Enforce-Modus ohne vorheriges Testing kann dazu führen, dass E-Mails abgelehnt werden, wenn TLS-Probleme existieren.

1

Woche 1: TLS-RPT zuerst

_smtp._tls IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@ihre-domain.de"

TLS-RPT funktioniert auch ohne MTA-STS und liefert sofort Daten über TLS-Verbindungen zu Ihrem Mailserver.

2

Woche 2: MTA-STS im Testing-Modus

mode: testing, max_age: 86400 (1 Tag)

E-Mails werden weiterhin zugestellt, auch wenn TLS fehlschlägt. Sie erhalten Reports über Probleme.

3

Woche 3-4: Reports auswerten

TLS-RPT-Reports auf starttls-not-supported, certificate-host-mismatch prüfen

Fehler beheben, bevor Sie auf Enforce umschalten. Keine Fehler nach 2 Wochen? Weiter zu Woche 5.

4

Woche 5: Enforce umschalten

mode: enforce, max_age: 604800 (1 Woche), id aktualisieren!

Policy-Datei auf enforce ändern, DNS-Record id aktualisieren. Sendende Server erzwingen jetzt TLS.

5

Danach: max_age erhöhen

max_age: 2592000 (30 Tage) → optional 31557600 (1 Jahr)

Wenn Enforce stabil läuft: max_age schrittweise erhöhen. Längere Cache-Dauer = weniger Policy-Abrufe, aber langsameres Rollback im Notfall.

Vergleich

MTA-STS vs. DANE: Zwei Wege zur TLS-Erzwingung

MTA-STS und DANE sind keine Konkurrenten — sie ergänzen sich. MTA-STS nutzt DNS und HTTPS zur Policy-Verteilung und funktioniert ohne DNSSEC. DANE nutzt TLSA-Records mit DNSSEC als kryptografischer Grundlage und bietet stärkeren Schutz. Die BSI TR-03108 empfiehlt beide Standards als komplementäre Maßnahmen — MTA-STS als pragmatischen ersten Schritt, DANE als kryptografisch stärkere Lösung. Vollständige DANE-TLSA-Konfiguration pro Provider und die DNSSEC-Voraussetzungen werden im Kapitel 09 DNS-Sicherheit (DNSSEC + DANE + CAA) vertieft.

Eigenschaft	MTA-STS (RFC 8461)	DANE (RFC 6698)
DNSSEC erforderlich	Nein	Ja (zwingende Voraussetzung)
Sicherheitsmodell	TOFU + HTTPS PKI	Kryptografische DNS-Validierung
Deployment-Aufwand	Gering (DNS + HTTPS-Datei)	Hoch (DNSSEC + TLSA-Records)
Zertifikats-Pinning	Nein	Ja (über TLSA-Records)
Verbreitung (2026)	Wachsend (~7.400 Domains)	Stabil (~2-3%, v.a. DACH)
Microsoft 365	MTA-STS: Ja (seit 2022)	DANE: GA seit 10/2024
Google Workspace	MTA-STS bevorzugt	Partiell (smtp.goog)

Compliance

MTA-STS als Compliance-Nachweis: NIS2, BSI und DSGVO

MTA-STS im Enforce-Modus ist der prüfbare Nachweis, dass Ihre Organisation die Verschlüsselung der E-Mail-Übertragung erzwingt. Die BSI TR-03108 fordert explizit TLS-Erzwingung für den E-Mail-Transport, NIS2 Art. 21 Abs. 2 lit. h verlangt Maßnahmen zur Kryptografie und Verschlüsselung, und die DSGVO Art. 32 fordert technische Schutzmaßnahmen bei der Datenübertragung.

NIS2 Art. 21 Abs. 2 lit. h

MTA-STS ist eine direkte technische Maßnahme zur Kryptografie und Verschlüsselung der E-Mail-Kommunikation. Die Erzwingung von TLS für eingehende E-Mails erfüllt die NIS2-Anforderung an sichere Kommunikationskanäle.

BSI TR-03108

Die BSI Technische Richtlinie für sicheren E-Mail-Transport fordert explizit TLS-Erzwingung. Bei der Rezertifizierung werden sowohl DANE als auch MTA-STS als komplementäre Maßnahmen verlangt — nicht als Entweder-Oder.

DSGVO Art. 32 Abs. 1 lit. a

Verschlüsselung als technische Maßnahme zum Schutz personenbezogener Daten bei der Übertragung. MTA-STS verhindert, dass E-Mails mit personenbezogenen Daten unverschlüsselt über das Internet transportiert werden.

MTA-STS adressiert konkrete Bedrohungen: Email-Spoofing via STRIPTLS-Downgrade — ein MitM-Angreifer kann ohne durchgesetzte Transport-Verschlüsselung den 220-Banner manipulieren, die Verbindung auf Klartext zwingen und in den Klartext-Mailfluss eingreifen. Vertiefung im Bedrohungs-Cluster.

NIS2 Art. 23 Meldepflichten: Eine erfolgreich exekutierte STRIPTLS-Manipulation, die zu Klartext-Mitlesen oder Datenabfluss aus E-Mails mit personenbezogenen oder geschäftskritischen Inhalten führt, kann als „erheblicher Sicherheitsvorfall“ im Sinne der Richtlinie qualifizieren — es greifen die 24-Stunden-Frühwarnung an die zuständige nationale CSIRT-Stelle, die 72-Stunden-Vorfallsmeldung und der Abschlussbericht innerhalb eines Monats. TLS-RPT-Reports und MTA-STS-Policy-Logs sind im Vorfall-Bewältigungs-Prozess die zentrale Forensik-Quelle.

Der Wolf-Agents Email Security Check prüft alle 165 Kriterien inklusive der 15 MTA-STS/TLS-RPT-Punkte — kostenlos und ohne Registrierung. Das Monitoring überwacht Ihre Konfiguration alle 6 Stunden und alarmiert bei Änderungen. Ergänzend nutzt das Attack-Surface-Monitoring CT-Log-Monitoring via Certstream-Integration, das neu ausgestellte TLS-Zertifikate für Ihre MX-Hosts und für _mta-sts.*/mta-sts.*-Subdomains erkennt — Frühwarn-Signal für nicht-autorisierte Cert-Ausstellungen, die einen Spoofing-Angriff vorbereiten.

MTA-STS-Anleitung für Ihren Provider:

Microsoft 365 Google Workspace IONOS Strato All-Inkl Hetzner Netcup Postfix Exim Mailcow Cloudflare DNS Generisch

Wie steht Ihre Domain bei MTA-STS?

Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.

E-Mail Security Check starten

Häufig gestellte Fragen

Was ist MTA-STS und wozu brauche ich es?

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) ist das HSTS-Äquivalent für E-Mail. Es signalisiert sendenden Mailservern über einen DNS-Record und eine HTTPS-gehostete Policy-Datei, dass Ihre Domain ausschließlich TLS-verschlüsselte E-Mail-Zustellung akzeptiert. Ohne MTA-STS können STRIPTLS-Angriffe die Verschlüsselung entfernen — E-Mails werden dann im Klartext übertragen. Im Wolf-Agents Email Security Check ist MTA-STS mit bis zu 15 Punkten (10 MTA-STS + 5 TLS-RPT) bewertet.

Was ist der Unterschied zwischen MTA-STS und DANE?

MTA-STS nutzt DNS + HTTPS zur Policy-Verteilung und funktioniert ohne DNSSEC — der Deployment-Aufwand ist gering. DANE nutzt TLSA-Records im DNS mit DNSSEC als kryptografischer Grundlage und bietet stärkeren Schutz, erfordert aber eine vollständige DNSSEC-Kette. Die BSI TR-03108 empfiehlt beide Standards als komplementäre Maßnahmen. MTA-STS ist der pragmatische erste Schritt, DANE die kryptografisch stärkere Lösung.

Wo hoste ich die MTA-STS Policy-Datei?

Die Policy-Datei muss unter https://mta-sts.ihre-domain.de/.well-known/mta-sts.txt per HTTPS erreichbar sein. Kostenlose Optionen: Cloudflare Pages (empfohlen, automatisches SSL und CDN), GitHub Pages oder Netlify. Bei Self-Hosted-Servern (Postfix, Exim) hosten Sie die Policy über nginx oder Apache mit Let's-Encrypt-Zertifikat direkt auf dem Server.

Brauche ich MTA-STS, wenn ich bereits DANE konfiguriert habe?

Ja, idealerweise beides. Nicht alle sendenden Mailserver validieren DANE — insbesondere Server ohne DNSSEC-Resolver. MTA-STS bietet einen Fallback für diese Server, da es ohne DNSSEC funktioniert. Google bevorzugt MTA-STS, Microsoft unterstützt beide Standards. Die BSI TR-03108 empfiehlt explizit die parallele Implementierung.

Was ist TLS-RPT und warum brauche ich es?

TLS-RPT (TLS Reporting, RFC 8460) liefert tägliche JSON-Reports über TLS-Verbindungsprobleme bei der E-Mail-Zustellung an Ihre Domain. Ohne TLS-RPT wissen Sie nicht, ob MTA-STS Zustellungen blockiert oder ob es TLS-Fehler gibt. Ein TLS-RPT-Record ist ein einfacher DNS-TXT-Eintrag unter _smtp._tls und bringt 5 Punkte im Wolf-Agents Scanner.

Wie teste ich meine MTA-STS-Konfiguration?

Prüfen Sie drei Dinge: Erstens den DNS-Record mit dig _mta-sts.ihre-domain.de TXT +short, zweitens die Policy-Datei mit curl https://mta-sts.ihre-domain.de/.well-known/mta-sts.txt, drittens den TLS-RPT-Record mit dig _smtp._tls.ihre-domain.de TXT +short. Der Wolf-Agents Email Security Check validiert alle drei Komponenten automatisch und prüft den MX-Abgleich zwischen Policy und DNS.

Was passiert bei abgelaufenem HTTPS-Zertifikat der Policy-Subdomain?

Sendende Server können die Policy-Datei nicht mehr abrufen. Nach Ablauf der max_age-Cache-Periode fällt MTA-STS aus — Ihr Schutz gegen TLS-Downgrade ist dann nicht mehr aktiv. Im Enforce-Modus ist das kritisch: Neue Sender können keine Policy laden und fallen auf opportunistic TLS zurück. Richten Sie automatische Zertifikatserneuerung via Let's Encrypt ein und überwachen Sie das Zertifikat.

MTA-STS & TLS-RPT: Transport-Verschlüsselung für E-Mail erzwingen