Kurz erklärt
MTA-STS (Mail Transfer Agent Strict Transport Security) ist ein Sicherheitsprotokoll, das verschlüsselte Verbindungen für eingehende E-Mails erzwingt. Ohne MTA-STS können Angreifer E-Mails während der Übertragung abfangen (Man-in-the-Middle-Angriff).
Die Implementierung erfordert:
- Einen DNS TXT-Record (
_mta-sts.example.com)
- Eine Policy-Datei unter
https://mta-sts.example.com/.well-known/mta-sts.txt
- Ein gültiges TLS-Zertifikat für die MTA-STS-Subdomain
MTA-STS ergänzt SPF, DKIM und DMARC um die Verschlüsselungs-Komponente – während die anderen Protokolle die Authentizität prüfen, sichert MTA-STS die Vertraulichkeit des Transports. Für DSGVO-Compliance (Verschlüsselung personenbezogener Daten) ist MTA-STS ein wichtiger Baustein.
Das Problem: Opportunistic TLS
Standard-SMTP-Verhalten: Mailserver versuchen TLS-Verschlüsselung, fallen aber auf unverschlüsselt zurück, wenn TLS fehlschlägt (Opportunistic TLS).
Angriffsszenario:
- Angreifer sitzt zwischen Sender und Empfänger
- Angreifer gibt vor, TLS nicht zu unterstützen
- Mailserver sendet E-Mail unverschlüsselt
- Angreifer liest E-Mail im Klartext mit
MTA-STS verhindert das: Sender wissen im Voraus, dass der Empfänger TLS erzwingt – unverschlüsselter Fallback ist nicht erlaubt.
Wie funktioniert MTA-STS?
1. DNS-Record veröffentlichen
TXT-Record für _mta-sts.example.com:
v=STSv1; id=20250104120000
Felder:
v=STSv1 – MTA-STS-Version (Pflicht)id= – Version-ID der Policy (z. B. Timestamp) – bei Policy-Änderung erhöhen
2. Policy-Datei bereitstellen
Datei unter https://mta-sts.example.com/.well-known/mta-sts.txt:
version: STSv1
mode: enforce
mx: mail.example.com
mx: mail2.example.com
max_age: 604800
Felder:
version: STSv1 – Policy-Version (Pflicht)mode: testing|enforce|none – Policy-Modus (Pflicht)mx: mail.example.com – Autorisierte MX-Server (mind. 1, Wildcards erlaubt)max_age: 604800 – Cache-Dauer in Sekunden (empfohlen: 7 Tage = 604800)
3. Sender prüft vor dem Versand
Ablauf beim Sender:
- DNS-Lookup für
_mta-sts.example.com – existiert MTA-STS?
- Policy-Datei von
https://mta-sts.example.com/.well-known/mta-sts.txt abrufen
- Policy-ID mit gecachter Version vergleichen – hat sich etwas geändert?
- TLS-Verschlüsselung zu einem der autorisierten MX-Server aufbauen
- Zertifikat validieren (gültiger Name, nicht abgelaufen)
- E-Mail versenden
Falls TLS fehlschlägt:
mode: enforce → E-Mail wird NICHT versendetmode: testing → E-Mail wird versendet, Fehler wird geloggt
MTA-STS Policy-Modi
| Modus | Verhalten | Verwendung |
|---|
testing | TLS erzwingen, aber bei Fehler trotzdem senden | Testphase (2-4 Wochen) |
enforce | TLS erzwingen, bei Fehler E-Mail ablehnen | Produktivbetrieb |
none | MTA-STS deaktivieren | Abschaltung |
Empfehlung: Mit testing starten, Logs prüfen, dann auf enforce wechseln.
MTA-STS einrichten – Schritt für Schritt
Voraussetzungen
✅ Gültiges TLS-Zertifikat für mta-sts.example.com
✅ Webserver für Policy-Datei (Nginx, Apache, Cloudflare Pages, etc.)
✅ Zugriff auf DNS-Zone
Phase 1: Subdomain und Zertifikat einrichten (1 Tag)
1. Subdomain erstellen:
- A- oder CNAME-Record für
mta-sts.example.com auf Webserver
- Beispiel:
mta-sts.example.com CNAME webserver.example.com
2. TLS-Zertifikat besorgen:
- Let’s Encrypt (kostenlos, automatisch mit Certbot)
- Wildcard-Zertifikat für
*.example.com funktioniert auch
- Wichtig: Zertifikat muss für
mta-sts.example.com gültig sein
Phase 2: Policy-Datei erstellen (30 Minuten)
1. MX-Records der Domain identifizieren:
dig example.com MX
Ausgabe z. B.:
example.com. 300 IN MX 10 mail.example.com.
example.com. 300 IN MX 20 mail2.example.com.
2. Policy-Datei erstellen:
Datei: /.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: mail.example.com
mx: mail2.example.com
max_age: 86400
Wichtig:
max_age: 86400 (1 Tag) für Testphase- Wildcards erlaubt:
mx: *.example.com
- MX-Namen müssen EXAKT wie im DNS sein (mit/ohne Trailing-Dot beachten)
3. Policy-Datei bereitstellen:
Via Webserver unter: https://mta-sts.example.com/.well-known/mta-sts.txt
Content-Type: text/plain (wichtig!)
Phase 3: DNS-Record veröffentlichen (5 Minuten)
TXT-Record für _mta-sts.example.com:
v=STSv1; id=20250104120000
ID-Format: Beliebig, aber eindeutig – empfohlen: Timestamp im Format YYYYMMDDHHmmss
Propagation: 5 Minuten bis mehrere Stunden (TTL beachten)
Phase 4: Testen (30 Minuten)
1. DNS-Record prüfen:
dig _mta-sts.example.com TXT
Erwartete Ausgabe:
_mta-sts.example.com. 300 IN TXT "v=STSv1; id=20250104120000"
2. Policy-Datei abrufen:
curl https://mta-sts.example.com/.well-known/mta-sts.txt
3. Online-Tools:
Phase 5: Monitoring & Enforcement (2-4 Wochen)
1. Logs beobachten (falls verfügbar):
- Gmail Postmaster Tools
- SMTP TLS Reporting (TLS-RPT, siehe unten)
2. Nach 2-4 Wochen: Auf enforce wechseln
Policy-Datei ändern:
version: STSv1
mode: enforce
mx: mail.example.com
mx: mail2.example.com
max_age: 604800
max_age auf 7 Tage erhöhen (604800 Sekunden)
DNS-Record-ID erhöhen:
v=STSv1; id=20250118120000
TLS-RPT (SMTP TLS Reporting)
Ergänzung zu MTA-STS: TLS-RPT sendet Reports über TLS-Verbindungsfehler.
DNS TXT-Record für _smtp._tls.example.com:
v=TLSRPTv1; rua=mailto:tls-reports@example.com
Vorteile:
- Erfahren, welche Sender TLS-Fehler haben
- Fehlerhafte Zertifikate oder MX-Einträge identifizieren
- Validierung, dass MTA-STS funktioniert
Report-Format: JSON, ähnlich wie DMARC-Reports
Häufige Probleme
❌ TLS-Zertifikat für mta-sts-Subdomain fehlt: HTTPS-Aufruf schlägt fehl, Policy wird ignoriert
❌ MX-Namen stimmen nicht überein: Policy listet mail.example.com, aber DNS zeigt mx1.example.com → TLS-Fehler
❌ Policy-Datei nicht erreichbar: 404-Fehler oder falscher Content-Type
❌ max_age zu hoch in Testphase: Bei Fehlern dauert es Tage, bis Sender neue Policy abrufen
❌ Wildcard-Zertifikat falsch: *.example.com deckt nicht mta-sts.example.com ab (nur Subdomains der ersten Ebene)
MTA-STS vs. DANE
Beide Protokolle erzwingen TLS für E-Mail, nutzen aber verschiedene Ansätze:
| Aspekt | MTA-STS | DANE |
|---|
| Basis | HTTPS + DNS TXT | DNSSEC + TLSA-Records |
| DNSSEC erforderlich? | Nein | Ja |
| Komplexität | Mittel (Webserver + DNS) | Hoch (DNSSEC-Setup) |
| Verbreitung | Hoch (Google, Microsoft, Yahoo) | Niedrig (selten implementiert) |
| Empfehlung | ✅ Ja, für alle | Nur bei bestehendem DNSSEC |
Faustregel: MTA-STS ist praktikabler als DANE – breitere Unterstützung, einfachere Implementierung.
DSGVO-Relevanz
Art. 32 DSGVO verlangt “Stand der Technik” bei der Sicherung personenbezogener Daten.
E-Mails enthalten oft personenbezogene Daten:
- Namen, E-Mail-Adressen
- Vertragsdaten, Rechnungen
- Gesundheitsdaten (bei Ärzten, Kliniken)
MTA-STS erfüllt:
- Verschlüsselung im Transit (Art. 32 Abs. 1 lit. a)
- Schutz vor unbefugtem Zugriff (Art. 32 Abs. 1 lit. b)
Nicht ausreichend: MTA-STS schützt nur den Transport, nicht die Speicherung (zusätzlich: S/MIME oder PGP erforderlich).
Kosten-Nutzen-Analyse
Kosten:
- Setup (DevOps): ~200-500 € einmalig
- TLS-Zertifikat: 0 € (Let’s Encrypt) oder in bestehendem Wildcard-Cert enthalten
- Hosting Policy-Datei: Minimal (bestehender Webserver oder Cloudflare Pages)
- Wartung: ~50-100 €/Jahr (Zertifikats-Renewal, Policy-Updates)
Nutzen:
- DSGVO-Compliance verbessern
- Man-in-the-Middle-Angriffe verhindern
- Bessere E-Mail-Reputation (Mailbox-Provider bevorzugen sichere Absender)
ROI: Risikovermeidung (Datenschutzverstoß) übersteigt Kosten deutlich.
Nächste Schritte
- TLS-Zertifikat für
mta-sts.example.com besorgen (Let’s Encrypt)
- Policy-Datei mit
mode: testing erstellen und unter .well-known bereitstellen
- DNS TXT-Record für
_mta-sts.example.com veröffentlichen
- Mit MTA-STS Validator testen
- TLS-RPT einrichten (optional, aber empfohlen)
- Nach 2-4 Wochen auf
mode: enforce wechseln
- Policy-ID im DNS erhöhen, max_age auf 7 Tage setzen
Siehe auch
HTTPS / TLS – Grundlagen der Transport-VerschlüsselungDMARC – E-Mail-AuthentifizierungSPF – Sender Policy FrameworkDKIM – DomainKeys Identified Mail