MTA-STS funktioniert nicht? Der komplette Fehlerbehebungs-Guide

Q: Warum wird meine MTA-STS-Policy nicht abgerufen?

Die Datei mta-sts.txt muss unter der exakten URL https://mta-sts.captaindns.com/.well-known/mta-sts.txt erreichbar sein. Überprüfe, ob die Subdomain mta-sts korrekt aufgelöst wird (CNAME- oder A-Eintrag), ob das TLS-Zertifikat gültig ist und ob der Server mit dem Code 200 und dem Content-Type text/plain antwortet. HTTP-zu-HTTPS-Weiterleitungen werden nicht von allen Clients akzeptiert.

Q: Was bedeutet der Fehler ‚MX nicht durch die Policy abgedeckt'?

Dein tatsächlicher MX-Server stimmt mit keinem mx: -Pattern in der Policy-Datei überein. Wenn dein MX zum Beispiel captaindns-com.mail.protection.outlook.com lautet, die Policy aber mx: mail.protection.outlook.com (ohne Wildcard) enthält, betrachtet der sendende Server den MX als nicht autorisiert. Füge den Wildcard hinzu: mx: *.mail.protection.outlook.com .

Q: Warum blockiert der Enforce-Modus E-Mails?

Im Modus enforce lehnen sendende Server den Versand ab, wenn die MTA-STS-Policy nicht erfüllt werden kann (ungültiges Zertifikat, MX nicht abgedeckt, Policy nicht erreichbar). Stelle sofort auf den Modus testing um, aktualisiere das Feld id im DNS-Eintrag und analysiere die TLS-RPT-Berichte, um die genaue Ursache zu identifizieren, bevor du wieder auf Enforce umstellst.

Von CaptainDNS
Veröffentlicht am 9. Februar 2026

MTA-STS-Fehlerbehebung: Diagnose und Lösung häufiger Fehler

TL;DR

Überprüfe zuerst die drei Grundlagen: DNS-Eintrag _mta-sts, Policy-Datei per HTTPS erreichbar und gültiges TLS-Zertifikat auf der Subdomain mta-sts
Der Fehler sts-policy-fetch-error bedeutet, dass die Datei mta-sts.txt nicht erreichbar ist — überprüfe Hosting, DNS und das Zertifikat der Subdomain
TLS-RPT-Berichte identifizieren den genauen Fehlertyp (certificate-expired, validation-failure, sts-webpki-invalid) und leiten die Diagnose
Im Notfall mit dem Modus enforce: Stelle sofort auf testing um und aktualisiere das Feld id im DNS-Eintrag

Du hast MTA-STS auf deiner Domain bereitgestellt und alle Schritte befolgt: DNS-Eintrag veröffentlicht, Policy-Datei gehostet, TLS-RPT aktiviert. Trotzdem melden die Berichte Fehler, der Prüfer zeigt Probleme an oder — schlimmer noch — E-Mails werden im Modus enforce abgelehnt.

MTA-STS umfasst mehrere Komponenten, die zusammenarbeiten müssen: ein DNS-TXT-Eintrag, eine Policy-Datei, die per HTTPS auf einer bestimmten Subdomain ausgeliefert wird, gültige TLS-Zertifikate und MX-Patterns, die exakt mit deinen Servern übereinstimmen. Ein einziges schwaches Glied reicht aus, um die gesamte Kette zu unterbrechen.

Dieser Fehlerbehebungs-Guide behandelt die häufigsten Fehler, ihre Ursachen und die Befehle zur Diagnose. Egal ob du Microsoft 365, Google Workspace oder Cloudflare für das Hosting verwendest — du findest hier die Lösung für dein Problem. Falls du MTA-STS noch nicht eingerichtet hast, lies zuerst unsere MTA-STS-Komplettanleitung.

Schnelldiagnose: Deine MTA-STS-Konfiguration überprüfen

Bevor du nach einem spezifischen Problem suchst, überprüfe diese drei Grundlagen in der richtigen Reihenfolge. Die meisten MTA-STS-Probleme lassen sich auf einen dieser drei Punkte zurückführen.

Schritt 1: DNS-Eintrag _mta-sts überprüfen

Der TXT-Eintrag bei _mta-sts.captaindns.com muss existieren und einen gültigen Wert enthalten:

dig TXT _mta-sts.captaindns.com +short
# Erwartetes Ergebnis: "v=STSv1; id=20260208120000"

Häufige Probleme:

Kein Ergebnis → Der Eintrag existiert nicht oder ist noch nicht propagiert
v=STS1 statt v=STSv1 → Tippfehler in der Version
Fehlendes Feld id → Pflichtfeld nicht vorhanden

Schritt 2: Policy-Datei überprüfen

Die Datei muss unter der exakten URL https://mta-sts.captaindns.com/.well-known/mta-sts.txt erreichbar sein:

curl -v https://mta-sts.captaindns.com/.well-known/mta-sts.txt

Prüfpunkte:

HTTP-Code 200 (nicht 301, 302, 403 oder 404)
Content-Type text/plain (nicht text/html)
Gültiger Inhalt mit version: STSv1, mode:, mx: und max_age:
Keine Weiterleitung von HTTP zu HTTPS (der Server muss direkt per HTTPS antworten)

Schritt 3: TLS-Zertifikat überprüfen

Die Subdomain mta-sts.captaindns.com muss ein gültiges TLS-Zertifikat besitzen:

openssl s_client -connect mta-sts.captaindns.com:443 -servername mta-sts.captaindns.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subject

Prüfpunkte:

Das Zertifikat ist nicht abgelaufen (notAfter liegt in der Zukunft)
Das Zertifikat deckt mta-sts.captaindns.com ab (im CN oder SAN)
Die Zertifikatskette ist vollständig (kein Fehler unable to verify)

MTA-STS-Diagnose-Checkliste: DNS-Eintrag, Policy-Datei und TLS-Zertifikat

Häufige Fehler und Lösungen

Fehler „Policy not found" (sts-policy-fetch-error)

Dies ist der häufigste Fehler in TLS-RPT-Berichten. Er bedeutet, dass der sendende Server deine Policy-Datei nicht abrufen konnte.

Ursache	Diagnosebefehl	Lösung
Datei fehlt	`curl -I https://mta-sts.captaindns.com/.well-known/mta-sts.txt`	Datei erstellen und hosten
DNS falsch konfiguriert	`dig A mta-sts.captaindns.com +short`	CNAME- oder A-Eintrag überprüfen
HTTP-Weiterleitung	`curl -v http://mta-sts.captaindns.com/.well-known/mta-sts.txt`	HTTPS direkt konfigurieren
Ungültiges Zertifikat	`curl -vI https://mta-sts.captaindns.com/`	Zertifikat erneuern oder korrigieren
Cloudflare pausiert	Cloudflare-Dashboard prüfen	Proxy oder Worker reaktivieren

Fehler „Certificate mismatch" (certificate-host-mismatch)

Das TLS-Zertifikat eines MX-Servers stimmt nicht mit dem MX-Hostnamen überein. Das betrifft nicht das Zertifikat der Subdomain mta-sts, sondern das des MX-Servers selbst.

# Zertifikat eines MX-Servers überprüfen
openssl s_client -connect captaindns-com.mail.protection.outlook.com:25 -starttls smtp -servername captaindns-com.mail.protection.outlook.com </dev/null 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

Bei Microsoft 365 oder Google Workspace: Dieses Problem sollte nicht auftreten, da Microsoft und Google die Zertifikate ihrer MX-Server selbst verwalten. Falls du den Fehler dennoch siehst, überprüfe, ob die MX-Patterns in deiner Policy mit deinen tatsächlichen MX-Servern übereinstimmen.

Fehler „MX not covered by policy"

Der MX-Server deiner Domain stimmt mit keinem mx:-Pattern in der Policy-Datei überein. Häufig handelt es sich um einen Wildcard-Fehler.

# Deine MX-Server auflisten
dig MX captaindns.com +short

# Mit der Policy vergleichen
curl -s https://mta-sts.captaindns.com/.well-known/mta-sts.txt | grep "^mx:"

Häufige Ursachen:

Situation	Falsches Pattern	Richtiges Pattern
Microsoft 365	`mx: mail.protection.outlook.com`	`mx: *.mail.protection.outlook.com`
Google Workspace	`mx: *.google.com` (allein)	`mx: .google.com` + `mx: .googlemail.com`
Benutzerdefinierter MX	Wildcard-Pattern zu restriktiv	Jeden MX einzeln überprüfen

Fehler „Certificate expired" (certificate-expired)

Ein TLS-Zertifikat ist auf einem deiner MX-Server oder auf der Subdomain mta-sts abgelaufen.

# Ablaufdatum des mta-sts-Zertifikats überprüfen
echo | openssl s_client -connect mta-sts.captaindns.com:443 -servername mta-sts.captaindns.com 2>/dev/null | openssl x509 -noout -enddate

Wenn es die Subdomain mta-sts betrifft: Erneuere das Zertifikat über deinen Hoster (Cloudflare macht das automatisch). Wenn es einen MX-Server betrifft: Bei Microsoft 365 oder Google Workspace erfolgt die Erneuerung automatisch. Für einen selbst gehosteten MX erneuere das Zertifikat über Let's Encrypt oder deine Zertifizierungsstelle.

Fehler „Validation failure" (validation-failure)

Die Zertifikatskette ist unvollständig: Das Root-Zertifikat oder ein Zwischenzertifikat fehlt.

# Vollständige Kette testen
openssl s_client -connect mta-sts.captaindns.com:443 -servername mta-sts.captaindns.com </dev/null 2>&1 | grep "Verify return code"
# Erwartetes Ergebnis: Verify return code: 0 (ok)

Wenn der Rückgabecode nicht 0 ist, installiere die fehlenden Zwischenzertifikate auf deinem Server.

Anbieterspezifische Probleme

Microsoft 365

Problem	Ursache	Lösung
MX nicht abgedeckt	Pattern ohne Wildcard	`mx: *.mail.protection.outlook.com` verwenden
Leere TLS-RPT-Berichte	M365 sendet Berichte verzögert	48–72 Stunden nach Aktivierung abwarten
MX-Zertifikat fehlerhaft	Selten (wird von Microsoft verwaltet)	Microsoft-Support kontaktieren

Google Workspace

Problem	Ursache	Lösung
MX nur teilweise abgedeckt	Nur ein `mx:`-Pattern	`mx: .google.com` UND `mx: .googlemail.com` hinzufügen
Unvollständige TLS-RPT-Berichte	Google aggregiert über 24 Stunden	Den vollständigen Bericht am nächsten Tag abwarten
Google-MX-Änderung	Migration auf neue MX-Server	Aktuelle MX-Einträge mit `dig MX` überprüfen

Cloudflare Pages / Workers

Problem	Ursache	Lösung
404 auf mta-sts.txt	Falscher Pfad im Repository	Die Datei muss unter `.well-known/mta-sts.txt` liegen
TLS-Zertifikat fehlt	Custom Domain nicht konfiguriert	`mta-sts.captaindns.com` in Custom Domains hinzufügen
Worker antwortet nicht	Route falsch konfiguriert	Überprüfen, ob die Route `mta-sts.captaindns.com/*` aktiv ist
Falscher Content-Type	Worker gibt `text/html` zurück	`Content-Type: text/plain` in der Response erzwingen
DNS nicht aufgelöst	CNAME fehlt	CNAME zum Pages-Projekt oder AAAA `100::` für Workers hinzufügen

TLS-RPT-Berichte lesen und interpretieren

Die TLS-RPT-Berichte, die von E-Mail-Anbietern gesendet werden, enthalten die Details zu TLS-Fehlern. So liest du sie.

Aufbau eines TLS-RPT-Berichts

Ein typischer JSON-Bericht enthält:

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-02-08T00:00:00Z",
    "end-datetime": "2026-02-08T23:59:59Z"
  },
  "policies": [{
    "policy": {
      "policy-type": "sts",
      "policy-domain": "captaindns.com"
    },
    "summary": {
      "total-successful-session-count": 150,
      "total-failure-session-count": 2
    },
    "failure-details": [{
      "result-type": "certificate-host-mismatch",
      "sending-mta-ip": "209.85.220.41",
      "receiving-mx-hostname": "captaindns-com.mail.protection.outlook.com",
      "failed-session-count": 2
    }]
  }]
}

Zuordnungstabelle der TLS-RPT-Fehler

TLS-RPT-Code	Bedeutung	Schweregrad	Maßnahme
`starttls-not-supported`	Der MX unterstützt kein STARTTLS	Kritisch	TLS auf dem MX-Server aktivieren
`certificate-host-mismatch`	Das Zertifikat stimmt nicht mit dem MX überein	Hoch	SAN des Zertifikats überprüfen
`certificate-expired`	Zertifikat abgelaufen	Hoch	Sofort erneuern
`certificate-not-trusted`	Selbstsigniertes Zertifikat oder unbekannte CA	Hoch	Zertifikat einer anerkannten CA verwenden
`validation-failure`	Zertifikatskette unvollständig	Hoch	Zwischenzertifikate installieren
`sts-policy-fetch-error`	Datei mta-sts.txt nicht erreichbar	Hoch	Hosting überprüfen
`sts-policy-invalid`	Inhalt der Policy ungültig	Hoch	Syntax korrigieren
`sts-webpki-invalid`	Zertifikat der Subdomain mta-sts ungültig	Hoch	Zertifikat erneuern

Diagnoseablauf für TLS-RPT-Fehler: Vom Fehler zur Lösung

Der Enforce-Modus blockiert E-Mails: Was tun?

Wenn du auf den Modus enforce umgestellt hast und legitime E-Mails abgelehnt werden, handle sofort:

1. Sofort auf den Testing-Modus zurückwechseln

Ändere die Policy-Datei:

version: STSv1
mode: testing
mx: *.mail.protection.outlook.com
max_age: 86400

2. DNS-Eintrag aktualisieren

Ändere das Feld id, um die sendenden Server zu zwingen, die Policy erneut herunterzuladen:

_mta-sts.captaindns.com. 300 IN TXT "v=STSv1; id=20260208180000"

3. Propagationszeit

Sendende Server cachen deine Policy für die Dauer des vorherigen max_age. Wenn du max_age: 2592000 (30 Tage) hattest, laden manche Server die Policy möglicherweise 30 Tage lang nicht erneut herunter. Deshalb wird empfohlen, max_age schrittweise zu erhöhen:

Phase	max_age	Dauer	Verwendung
Anfängliches Testing	`86400`	24 Stunden	Ermöglicht schnelle Rücknahme
Fortgeschrittenes Testing	`604800`	7 Tage	Nach 2 Wochen ohne Fehler
Vorsichtiger Enforce-Modus	`604800`	7 Tage	Erste Wochen im Enforce-Modus
Stabiler Enforce-Modus	`2592000`	30 Tage	Nach 1 Monat im Enforce-Modus ohne Probleme

Wichtige Diagnosebefehle

Hier sind die Befehle, die du für die Diagnose aller MTA-STS-Probleme griffbereit haben solltest:

# 1. MTA-STS-DNS-Eintrag überprüfen
dig TXT _mta-sts.captaindns.com +short

# 2. TLS-RPT-Eintrag überprüfen
dig TXT _smtp._tls.captaindns.com +short

# 3. Policy-Datei abrufen
curl -s https://mta-sts.captaindns.com/.well-known/mta-sts.txt

# 4. HTTP-Header der Policy-Datei überprüfen
curl -I https://mta-sts.captaindns.com/.well-known/mta-sts.txt

# 5. MX-Server auflisten
dig MX captaindns.com +short

# 6. Zertifikat der Subdomain mta-sts überprüfen
echo | openssl s_client -connect mta-sts.captaindns.com:443 -servername mta-sts.captaindns.com 2>/dev/null | openssl x509 -noout -dates -subject

# 7. STARTTLS-Verbindung auf einem MX testen
openssl s_client -connect captaindns-com.mail.protection.outlook.com:25 -starttls smtp -servername captaindns-com.mail.protection.outlook.com </dev/null 2>/dev/null | openssl x509 -noout -dates

Empfohlener Aktionsplan

Problem identifizieren: Verwende den MTA-STS-Prüfer von CaptainDNS für eine automatische Komplettdiagnose
Die drei Grundlagen überprüfen: DNS-Eintrag, Policy-Datei, TLS-Zertifikat (in dieser Reihenfolge)
TLS-RPT-Berichte auswerten: Das Feld result-type zeigt dir genau, was fehlschlägt
Identifiziertes Problem beheben: Folge den Lösungen im entsprechenden Abschnitt oben
Korrektur validieren: Verwende den MTA-STS-Syntax-Prüfer, um zu bestätigen, dass die Policy korrekt ist
48 Stunden überwachen: Überprüfe, ob die TLS-RPT-Berichte den Fehler nicht mehr melden

Überprüfe jetzt deine MTA-STS-Konfiguration: Verwende unseren MTA-STS-Prüfer, um deine Domain in wenigen Sekunden zu diagnostizieren.

FAQ

Warum wird meine MTA-STS-Policy nicht abgerufen?

Die Datei mta-sts.txt muss unter der exakten URL https://mta-sts.captaindns.com/.well-known/mta-sts.txt erreichbar sein. Überprüfe, ob die Subdomain mta-sts korrekt aufgelöst wird (CNAME- oder A-Eintrag), ob das TLS-Zertifikat gültig ist und ob der Server mit dem Code 200 und dem Content-Type text/plain antwortet. HTTP-zu-HTTPS-Weiterleitungen werden nicht von allen Clients akzeptiert.

Was bedeutet der Fehler ‚MX nicht durch die Policy abgedeckt'?

Dein tatsächlicher MX-Server stimmt mit keinem mx:-Pattern in der Policy-Datei überein. Wenn dein MX zum Beispiel captaindns-com.mail.protection.outlook.com lautet, die Policy aber mx: mail.protection.outlook.com (ohne Wildcard) enthält, betrachtet der sendende Server den MX als nicht autorisiert. Füge den Wildcard hinzu: mx: *.mail.protection.outlook.com.

Wie behebe ich einen TLS-Zertifikatsfehler bei MTA-STS?

Identifiziere zunächst, welches Zertifikat betroffen ist. Wenn es das Zertifikat der Subdomain mta-sts ist: Erneuere es über deinen Hoster (Cloudflare erneuert automatisch). Wenn es das Zertifikat eines MX-Servers ist: Bei Microsoft 365 oder Google Workspace wird das automatisch verwaltet. Für einen selbst gehosteten MX überprüfe die vollständige Zertifikatskette und das Ablaufdatum.

Warum blockiert der Enforce-Modus E-Mails?

Im Modus enforce lehnen sendende Server den Versand ab, wenn die MTA-STS-Policy nicht erfüllt werden kann (ungültiges Zertifikat, MX nicht abgedeckt, Policy nicht erreichbar). Stelle sofort auf den Modus testing um, aktualisiere das Feld id im DNS-Eintrag und analysiere die TLS-RPT-Berichte, um die genaue Ursache zu identifizieren, bevor du wieder auf Enforce umstellst.

Wie wechsle ich im Notfall zurück zum Testing-Modus?

Ändere die Datei mta-sts.txt, indem du mode: enforce durch mode: testing ersetzt. Aktualisiere anschließend das Feld id im DNS-TXT-Eintrag _mta-sts mit einem neuen Zeitstempel. Die sendenden Server laden die Policy erneut herunter und hören auf, E-Mails abzulehnen. Die Verzögerung hängt vom vorherigen max_age ab.

Wie lese ich einen TLS-RPT-Bericht?

TLS-RPT-Berichte sind JSON-Dateien, die täglich an die im Eintrag _smtp._tls angegebene Adresse gesendet werden. Das Feld result-type gibt den Fehlertyp an (certificate-expired, sts-policy-fetch-error usw.), receiving-mx-hostname identifiziert den betroffenen MX-Server und failed-session-count gibt die Anzahl der Fehlversuche an.

MTA-STS funktioniert nicht mit Cloudflare Workers: Was ist zu überprüfen?

Überprüfe, ob die Route mta-sts.captaindns.com/* im Worker konfiguriert ist, ob das DNS einen AAAA-Eintrag mta-sts enthält, der auf 100:: zeigt (proxied), und ob der Worker den Content-Type text/plain; charset=utf-8 zurückgibt. Teste mit curl -I https://mta-sts.captaindns.com/.well-known/mta-sts.txt, um den Code 200 und die Header zu bestätigen.

Wie lange dauert es, bis Korrekturen wirksam werden?

Sendende Server cachen deine Policy für die Dauer des max_age. Wenn du max_age: 86400 (24 Stunden) hattest, wird die Korrektur innerhalb von maximal 24 Stunden wirksam. Wenn du max_age: 2592000 (30 Tage) hattest, sehen einige Server die Korrektur möglicherweise 30 Tage lang nicht. Deshalb wird empfohlen, in der Testphase einen kurzen max_age zu verwenden.

Glossar

MTA-STS: Mail Transfer Agent Strict Transport Security. Standard RFC 8461, der TLS-Verschlüsselung für den E-Mail-Empfang erzwingt.
TLS-RPT: SMTP TLS Reporting (RFC 8460). Mechanismus für tägliche Berichte über Erfolge und Fehlschläge bei der TLS-Aushandlung.
sts-policy-fetch-error: TLS-RPT-Fehlercode, der angibt, dass die Policy-Datei mta-sts.txt vom sendenden Server nicht abgerufen werden konnte.
max_age: Direktive der MTA-STS-Policy, die die Cache-Dauer in Sekunden angibt. Bestimmt die Propagationszeit von Änderungen.
STARTTLS: SMTP-Erweiterung zur Verschlüsselung der Verbindung zwischen E-Mail-Servern. MTA-STS erzwingt dessen Verwendung mit einem gültigen Zertifikat.