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.

Postfix · MTA-STS-Anleitung

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.

1 Schritt 1 von 5

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.

DNS-Konfiguration DNS-Records
# 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
2 Schritt 2 von 5

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.

/etc/nginx/sites-available/mta-sts nginx-vhost
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

  1. Symlink erstellen: ln -s /etc/nginx/sites-available/mta-sts /etc/nginx/sites-enabled/
  2. Konfiguration testen: nginx -t — muss syntax is ok ausgeben
  3. nginx neu laden: systemctl reload nginx
  4. Verzeichnis erstellen: mkdir -p /var/www/mta-sts/.well-known
3 Schritt 3 von 5

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.

/var/www/mta-sts/.well-known/mta-sts.txt Policy
version: STSv1
mode: enforce
mx: mx1.ihre-domain.de
mx: mx2.ihre-domain.de
max_age: 604800

Postfix-TLS-Konfiguration prüfen

  1. Eingehend (smtpd): smtpd_tls_security_level = may aktiviert opportunistisches TLS — Pflicht für MTA-STS. Das Zertifikat des MX-Hosts muss gültig und zum Hostnamen passend sein
  2. Ausgehend (smtp): smtp_tls_security_level = may aktiviert TLS beim Senden. Für MTA-STS-Validierung beim Senden installieren Sie zusätzlich postfix-mta-sts-resolver
  3. Protokolle: Deaktivieren Sie SSLv2, SSLv3, TLSv1 und TLSv1.1 — nur TLSv1.2 und TLSv1.3 sind sicher
  4. 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
/etc/postfix/main.cf — TLS-Einstellungen Postfix-TLS
# 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
4 Schritt 4 von 5

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.

Terminal (certbot) Let's Encrypt
# 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)

  1. 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
  2. Installation: pip3 install postfix-mta-sts-resolver — Python 3.6+ erforderlich; Distributions-Pakete (Debian/Ubuntu) heißen ebenfalls postfix-mta-sts-resolver
  3. Daemon-Konfiguration: Default-Pfad ist /etc/mta-sts-daemon.yml (laut Snawoot-README) — der Daemon lauscht auf 127.0.0.1:8461 und antwortet auf Socketmap-Anfragen
  4. Postfix-Integration via Socketmap: In main.cf den Parameter smtp_tls_policy_maps = socketmap:inet:127.0.0.1:8461:postfix setzen — falls Sie bereits TLS-Policies haben, hängen Sie den Socketmap an die Liste an, nicht ersetzen
  5. SNI-Pflicht: Ab Postfix 3.4 muss in der Daemon-Config require_sni: true stehen, damit RFC-8461-konform SNI im TLS-Handshake gesendet wird
  6. Operability-Check: postmap -q example.com socketmap:inet:127.0.0.1:8461:postfix liefert für MTA-STS-Domains z.B. secure match=mx1.example.com zurück — ohne tatsächlichen Mailversand
/etc/mta-sts-daemon.yml Daemon-Config
# /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 Postfix-Integration
# /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"
5 Schritt 5 von 5

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.

Terminal / PowerShell Verifikation
# 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).

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.

Wie steht Ihre Domain bei MTA-STS?

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