MTA-STS für Postfix einrichten
Schritt-für-Schritt-Anleitung: DNS-Records setzen, nginx-vhost für Policy-Hosting konfigurieren, Let's-Encrypt-Zertifikat einrichten, Policy-Datei erstellen, Postfix-TLS prüfen und optional postfix-mta-sts-resolver für ausgehende MTA-STS-Validierung aktivieren.
MTA-STS bei Postfix einrichten
Postfix unterstützt MTA-STS nicht nativ — die Policy-Datei wird über einen nginx-Webserver mit Let's-Encrypt-Zertifikat gehostet. Die Konfiguration umfasst DNS-Records, einen nginx-vhost für die Subdomain mta-sts, die Policy-Datei und die Postfix-TLS-Einstellungen. Das Plugin postfix-mta-sts-resolver ermöglicht zusätzlich MTA-STS-Validierung beim Senden.
MTA-STS (RFC 8461) schützt eingehende E-Mail-Zustellung vor STRIPTLS-Downgrade-Angriffen. Bei Postfix besteht die Konfiguration aus zwei Teilen: Erstens das Policy-Hosting über nginx, damit sendende Server Ihre MTA-STS-Policy abrufen können. Zweitens die Postfix-TLS-Konfiguration, die sicherstellt, dass Ihr Mailserver TLS korrekt unterstützt und die in der Policy genannten MX-Hosts tatsächlich verschlüsselte Verbindungen akzeptieren. Optional können Sie postfix-mta-sts-resolver installieren — dieses Plugin validiert MTA-STS-Policies beim ausgehenden Mailversand und erzwingt TLS gegenüber Domains, die MTA-STS im Enforce-Modus betreiben. Der Wolf-Agents Email Security Scanner vergleicht Policy-MX und DNS-MX zeichengenau: Er erkennt, wenn der Common Name des Postfix-Zertifikats nicht zum MX-Hostnamen passt (häufige Ursache für certificate-host-mismatch in TLS-RPT-Reports), warnt vor root statt alias in der nginx-Konfiguration und meldet abgelaufene Let's-Encrypt-Zertifikate vor dem nächsten Hard-Fail.
BSI TR-03108 Abschnitt 4.3 fordert TLS-Erzwingung für die E-Mail-Kommunikation. Postfix mit MTA-STS im Enforce-Modus erfüllt diese Anforderung über das nginx-Policy-Hosting: Sendende Server werden angewiesen, TLS zwingend zu verwenden und das Zertifikat zu validieren. DSGVO Art. 32 verlangt Verschlüsselung als technische Maßnahme — Postfix-Logs mit smtp_tls_loglevel = 1 (ausgehend) und smtpd_tls_loglevel = 1 (eingehend) dokumentieren TLS-Version und Cipher pro Zustellung in /var/log/mail.log, was als DSGVO-TOM-Nachweis dient. Wolf-Agents empfiehlt die Kombination aus MTA-STS und DANE für maximalen Schutz auf Self-Hosted-Infrastruktur.
DNS-Records setzen
Legen Sie drei DNS-Records an: einen A-Record für die Subdomain mta-sts.ihre-domain.de, der auf die IP Ihres Webservers zeigt, den _mta-sts TXT-Record und den _smtp._tls TLS-RPT-Record. Der A-Record ist bei Postfix-Setups besonders wichtig, da die Policy-Subdomain typischerweise auf demselben Server läuft wie der Mailserver — aber über einen separaten nginx-vhost auf Port 443 ausgeliefert wird.
# A-Record für Policy-Subdomain
# Host: mta-sts
# Typ: A
# Wert: 203.0.113.10 (IP Ihres Webservers)
# MTA-STS DNS-Record
# Host: _mta-sts
# Typ: TXT
# Wert: v=STSv1; id=20260408
# TLS-RPT DNS-Record
# Host: _smtp._tls
# Typ: TXT
# Wert: v=TLSRPTv1; rua=mailto:tls-reports@ihre-domain.de
# DNS-Records prüfen
dig _mta-sts.ihre-domain.de TXT +short
dig _smtp._tls.ihre-domain.de TXT +short
dig mta-sts.ihre-domain.de A +short nginx für Policy-Hosting konfigurieren
Erstellen Sie einen nginx-vhost für die Subdomain mta-sts.ihre-domain.de. Der vhost muss HTTPS mit einem gültigen Zertifikat bereitstellen und die Policy-Datei unter /.well-known/mta-sts.txt mit dem Content-Type text/plain ausliefern. Alle anderen Pfade sollten mit 404 antworten. Die HTTP-zu-HTTPS-Weiterleitung ist wichtig, da einige MTA-STS-Implementierungen zuerst HTTP versuchen.
server {
listen 443 ssl;
http2 on;
server_name mta-sts.ihre-domain.de;
ssl_certificate /etc/letsencrypt/live/mta-sts.ihre-domain.de/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mta-sts.ihre-domain.de/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
location /.well-known/mta-sts.txt {
alias /var/www/mta-sts/.well-known/mta-sts.txt;
default_type text/plain;
add_header Cache-Control "public, max-age=3600";
}
location / {
return 404;
}
}
server {
listen 80;
server_name mta-sts.ihre-domain.de;
return 301 https://$host$request_uri;
} nginx-Konfiguration aktivieren
- Symlink erstellen:
ln -s /etc/nginx/sites-available/mta-sts /etc/nginx/sites-enabled/ - Konfiguration testen:
nginx -t— musssyntax is okausgeben - nginx neu laden:
systemctl reload nginx - Verzeichnis erstellen:
mkdir -p /var/www/mta-sts/.well-known
Policy-Datei erstellen
Erstellen Sie die Policy-Datei unter /var/www/mta-sts/.well-known/mta-sts.txt. Die mx-Zeilen müssen exakt mit Ihren DNS-MX-Records übereinstimmen. Beginnen Sie mit mode: testing — in diesem Modus werden TLS-Fehler in TLS-RPT-Reports gemeldet, aber E-Mails nicht blockiert. Wechseln Sie auf mode: enforce, sobald die Reports keine Fehler mehr zeigen. Vergessen Sie nicht, die id im DNS-Record bei jeder Policy-Änderung zu aktualisieren.
version: STSv1
mode: enforce
mx: mx1.ihre-domain.de
mx: mx2.ihre-domain.de
max_age: 604800 Postfix-TLS-Konfiguration prüfen
- Eingehend (smtpd):
smtpd_tls_security_level = mayaktiviert opportunistisches TLS — Pflicht für MTA-STS. Das Zertifikat des MX-Hosts muss gültig und zum Hostnamen passend sein - Ausgehend (smtp):
smtp_tls_security_level = mayaktiviert TLS beim Senden. Für MTA-STS-Validierung beim Senden installieren Sie zusätzlichpostfix-mta-sts-resolver - Protokolle: Deaktivieren Sie SSLv2, SSLv3, TLSv1 und TLSv1.1 — nur TLSv1.2 und TLSv1.3 sind sicher
- Zertifikat: Das Let's-Encrypt-Zertifikat des MX-Hosts muss mit dem Hostnamen im MX-Record übereinstimmen — sendende Server validieren dies bei MTA-STS enforce
# Eingehend (smtpd)
smtpd_tls_cert_file = /etc/letsencrypt/live/mx1.ihre-domain.de/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mx1.ihre-domain.de/privkey.pem
smtpd_tls_security_level = may
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
# Ausgehend (smtp)
smtp_tls_security_level = may
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 Let's Encrypt Zertifikat einrichten
Sie benötigen zwei Zertifikate: eines für die MTA-STS-Policy-Subdomain (mta-sts.ihre-domain.de) und eines für Ihren MX-Host (mx1.ihre-domain.de). Das Policy-Zertifikat wird von nginx verwendet, das MX-Zertifikat von Postfix. Beide müssen automatisch erneuert werden — ein abgelaufenes Policy-Zertifikat bedeutet, dass sendende Server keine Policy mehr laden können, ein abgelaufenes MX-Zertifikat führt bei MTA-STS enforce zu Zustellproblemen.
# Zertifikat anfordern (vor nginx-SSL-Konfiguration)
sudo certbot certonly --standalone -d mta-sts.ihre-domain.de
# ODER mit nginx-Plugin (nginx läuft bereits)
sudo certbot --nginx -d mta-sts.ihre-domain.de
# Automatische Erneuerung prüfen
sudo certbot renew --dry-run
# Zertifikat-Ablaufdatum prüfen
sudo certbot certificates postfix-mta-sts-resolver (optional, ausgehend)
- Was es tut: Validiert MTA-STS-Policies beim ausgehenden Mailversand. Wenn eine Empfängerdomain MTA-STS enforce hat, erzwingt Postfix TLS und prüft das Zertifikat
- Installation:
pip3 install postfix-mta-sts-resolver— Python 3.6+ erforderlich; Distributions-Pakete (Debian/Ubuntu) heißen ebenfallspostfix-mta-sts-resolver - Daemon-Konfiguration: Default-Pfad ist
/etc/mta-sts-daemon.yml(laut Snawoot-README) — der Daemon lauscht auf127.0.0.1:8461und antwortet auf Socketmap-Anfragen - Postfix-Integration via Socketmap: In
main.cfden Parametersmtp_tls_policy_maps = socketmap:inet:127.0.0.1:8461:postfixsetzen — falls Sie bereits TLS-Policies haben, hängen Sie den Socketmap an die Liste an, nicht ersetzen - SNI-Pflicht: Ab Postfix 3.4 muss in der Daemon-Config
require_sni: truestehen, damit RFC-8461-konform SNI im TLS-Handshake gesendet wird - Operability-Check:
postmap -q example.com socketmap:inet:127.0.0.1:8461:postfixliefert für MTA-STS-Domains z.B.secure match=mx1.example.comzurück — ohne tatsächlichen Mailversand
# /etc/mta-sts-daemon.yml (Default-Pfad laut Snawoot-README)
host: 127.0.0.1
port: 8461
reuse_port: true
shutdown_timeout: 20
cache:
type: sqlite
options:
filename: /var/lib/mta-sts/cache.db
default_zone:
strict_testing: false
timeout: 10
# Pflicht ab Postfix 3.4: SNI in Policy-Response erzwingen
require_sni: true # /etc/postfix/main.cf — Socketmap-Anbindung an mta-sts-daemon
smtp_tls_policy_maps = socketmap:inet:127.0.0.1:8461:postfix
# Pflicht-Voraussetzung: CA-Bundle für Zertifikats-Validierung
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
# Operability-Test (ohne Mail zu senden):
# postmap -q example.com socketmap:inet:127.0.0.1:8461:postfix
# Erwartete Ausgabe bei MTA-STS-Domain: "secure match=mx1.example.com" MTA-STS-Konfiguration verifizieren
Prüfen Sie alle Komponenten: DNS-Records, nginx-Erreichbarkeit der Policy-Datei, Postfix-TLS-Konfiguration und MX-Abgleich. Der Wolf-Agents Email Security Scanner validiert den MX-Abgleich automatisch — die mx-Einträge in der Policy müssen exakt mit Ihren DNS-MX-Records übereinstimmen. Beginnen Sie mit mode: testing, beobachten Sie die TLS-RPT-Reports 1–2 Wochen und wechseln Sie dann auf mode: enforce.
# Linux / macOS
dig _mta-sts.ihre-domain.de TXT +short
curl -s https://mta-sts.ihre-domain.de/.well-known/mta-sts.txt
dig _smtp._tls.ihre-domain.de TXT +short
# Windows (PowerShell)
Resolve-DnsName -Name _mta-sts.ihre-domain.de -Type TXT | Select-Object -ExpandProperty Strings
Invoke-WebRequest -Uri "https://mta-sts.ihre-domain.de/.well-known/mta-sts.txt" | Select-Object -ExpandProperty Content
Resolve-DnsName -Name _smtp._tls.ihre-domain.de -Type TXT | Select-Object -ExpandProperty Strings
# Postfix TLS-Konfiguration prüfen
postconf | grep smtp_tls_security_level
postconf | grep smtpd_tls_security_level
# nginx Policy-Zugriff testen
curl -I https://mta-sts.ihre-domain.de/.well-known/mta-sts.txt
# Erwartete Ausgaben:
# "v=STSv1; id=20260408"
# version: STSv1 / mode: enforce / mx: ... / max_age: 604800
# "v=TLSRPTv1; rua=mailto:tls-reports@ihre-domain.de" Häufige Probleme bei Postfix MTA-STS
Die folgenden drei Probleme treten bei Postfix MTA-STS-Konfigurationen besonders häufig auf. Alle drei betreffen das nginx-Policy-Hosting — Postfix selbst erfordert keine MTA-STS-spezifische Konfiguration für den Empfang, aber der nginx-Webserver muss fehlerfrei funktionieren.
nginx nicht erreichbar — Port 443 blockiert
Symptom: curl -I https://mta-sts.ihre-domain.de/.well-known/mta-sts.txt liefert Connection refused oder einen Timeout. Die Policy-Datei ist auf dem Server vorhanden, aber von extern nicht abrufbar.
Ursache: Die Firewall (ufw, iptables oder Cloud-Firewall) blockiert eingehenden TCP-Traffic auf Port 443. Alternativ: nginx lauscht nicht auf der richtigen IP oder der vhost ist nicht aktiviert (fehlender Symlink in sites-enabled).
Lösung: Prüfen Sie ufw status und fügen Sie ufw allow 443/tcp hinzu. Verifizieren Sie mit ss -tlnp | grep 443, dass nginx auf Port 443 lauscht. Prüfen Sie den Symlink: ls -la /etc/nginx/sites-enabled/mta-sts.
Policy-Datei unter falschem Pfad
Symptom: curl https://mta-sts.ihre-domain.de/.well-known/mta-sts.txt liefert 404 Not Found. Der nginx-vhost ist erreichbar, aber die Policy-Datei wird nicht gefunden.
Ursache: Die Policy-Datei liegt nicht unter dem in der nginx-Konfiguration definierten alias-Pfad. Typischer Fehler: /var/www/mta-sts/mta-sts.txt statt /var/www/mta-sts/.well-known/mta-sts.txt — oder der .well-known-Ordner fehlt im Dateisystem.
Lösung: Prüfen Sie den Pfad in der nginx-Konfiguration und im Dateisystem: ls -la /var/www/mta-sts/.well-known/mta-sts.txt. Der alias-Pfad in nginx muss exakt mit dem Dateisystem-Pfad übereinstimmen. Beachten Sie: alias ersetzt den gesamten location-Pfad, root hängt ihn an.
Let's Encrypt Zertifikat abgelaufen
Symptom: TLS-RPT-Reports zeigen plötzlich sts-webpki-invalid oder certificate-expired für Ihre Domain. Sendende Server können die Policy-Datei nicht mehr abrufen.
Ursache: Das Let's-Encrypt-Zertifikat für mta-sts.ihre-domain.de ist abgelaufen, weil die automatische Erneuerung fehlgeschlagen ist. Häufige Ursachen: Port 80 blockiert (certbot HTTP-Challenge), DNS-Änderung der Subdomain, oder certbot-Timer deaktiviert.
Lösung: Prüfen Sie den Timer: systemctl status certbot.timer. Erneuern Sie manuell: certbot renew --force-renewal. Stellen Sie sicher, dass Port 80 für die HTTP-Challenge erreichbar ist. Der Wolf-Agents Email Security Scanner erkennt abgelaufene Zertifikate automatisch.
NIS2, BSI TR-03108 und DSGVO Art. 32: Postfix mit MTA-STS enforce
NIS2 Art. 21 Abs. 2 lit. h fordert den Einsatz von Kryptografie und Verschlüsselung — Postfix mit MTA-STS im Enforce-Modus erfüllt diese Anforderung technisch nachweisbar. Sendende Server werden angewiesen, TLS zwingend zu verwenden und das Zertifikat des MX-Hosts zu validieren. Die BSI TR-03108 Abschnitt 4.3 verlangt zusätzlich TLS-Erzwingung für die E-Mail-Kommunikation und empfiehlt die Kombination aus MTA-STS und DANE. DSGVO Art. 32 verlangt Verschlüsselung als technische Maßnahme — Postfix-Logs mit smtp_tls_loglevel = 1 dokumentieren TLS-Version pro Zustellung in /var/log/mail.log, was als DSGVO-TOM-Nachweis dient. In Verbindung mit postfix-mta-sts-resolver erzwingt Ihr Server auch beim Senden TLS gegenüber Domains mit MTA-STS enforce — bidirektionaler Schutz. Cipher-Härtung pro MX-Host und konkrete smtpd_tls_*-Konfiguration siehe SMTP-TLS für Postfix. Der Wolf-Agents Email Security Scanner bewertet MTA-STS mit bis zu 15 Punkten (10 MTA-STS + 5 TLS-RPT).
Postfix Open-Source-Stack — 4 Komponenten (Multimodal)
Postfix + nginx + Let's Encrypt + Snawoot postfix-mta-sts-resolver bilden den vollständigen Open-Source-Stack für MTA-STS. Die Visualisierung zeigt die Komponenten-Verbindungen und Datenflüsse — gültig auch für Exim-basierte Setups (Cross-File-Reuse).
Postfix/Exim + nginx + Lets Encrypt — Self-Hosted MTA-STS-Stack
Multimodales Komponenten-Diagramm mit Server-Box und 4 Komponenten: Postfix oder Exim (Ports 25 / 465 / 587), nginx (Port 443 für Policy-Hosting), certbot (täglicher Cron für Lets Encrypt 90-Tage-Cycle), optional mta-sts-daemon Snawoot (Port 8461 Outbound-Resolver via Socketmap). DNS-Records (A/AAAA/2 TXT) + Verbindungs-Pfeile zu externem Sender.
Outbound MTA-STS Cluster — Snawoot postfix-mta-sts-resolver (Multimodal)
Snawoot postfix-mta-sts-resolver (Port 8461) validiert ausgehende MTA-STS-Policies. Die Visualisierung zeigt den Cluster aus Postfix smtp_tls_policy_maps → Resolver → DNS/HTTPS-Lookup für outbound TLS-Erzwingung. Repository: github.com/Snawoot/postfix-mta-sts-resolver.
Postfix Outbound-MTA-STS-Cluster — Snawoot Resolver via Socketmap
Multimodales Integration-Diagramm: Postfix (Port 25 outbound) verbindet via smtp_tls_policy_maps Socketmap zum mta-sts-daemon (Port 8461 Snawoot). Der Daemon prüft lokal sqlite-Cache nach max_age, bei Cache-Miss DNS-Lookup TXT-Record + HTTPS-GET Policy-Body. Response postfix-kompatibel: 'secure match=mx1.empfaenger.com'.
MTA-STS-Anleitung auch für:
Wie steht Ihre Domain bei MTA-STS?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.