DMARC Enforcement für Postfix
Schritt-für-Schritt-Roadmap: OpenDKIM prüfen und ALLE ausgehenden Pfade DKIM-signieren — PHP mail(), Cron-Jobs und Backup-MX nicht vergessen — Postfix als DKIM-Relay für Legacy-Systeme nutzen und Policy von p=none über p=quarantine zu p=reject verschärfen.
DMARC Enforcement bei Postfix
Self-Hosted-Mailserver mit Postfix bieten volle Kontrolle über alle E-Mail-Pfade — und damit volle Verantwortung. Beim DMARC Enforcement müssen ALLE ausgehenden Pfade DKIM-signiert sein: der primäre Mailserver, Webserver die direkt E-Mails senden, Cron-Jobs, Monitoring-Alerts und der Backup-MX. Wer einen Pfad vergisst, sieht es in den DMARC-Reports als DKIM fail.
Postfix integriert DKIM-Signierung über OpenDKIM oder rspamd als Milter-Filter. Der entscheidende Konfigurationsparameter ist non_smtpd_milters in der main.cf: Ohne diesen Parameter signiert OpenDKIM nur E-Mails, die über den SMTP-Port eingehen — nicht aber lokale E-Mails von PHP, Cron oder sendmail. Ein weiterer Postfix-Vorteil: Postfix kann als DKIM-Relay für Legacy-Systeme dienen, die keine eigene DKIM-Signierung unterstützen. Der Wolf-Agents Email Security Scanner prüft Ihre DMARC-Policy als Teil der 165 Prüfpunkte und zeigt, ob DKIM konsistent für alle Sendequellen aktiv ist. Falls Sie DMARC noch nicht eingerichtet haben, starten Sie mit der DMARC-Anleitung für Postfix. Nach Erreichen von p=reject ist der nächste Hardening-Schritt MTA-STS für Postfix — Transport-Verschlüsselung erzwingen.
Self-Hosted-Mailserver tragen die vollständige Verantwortung für DMARC-Enforcement. NIS2 Art. 21 fordert Maßnahmen nach dem Stand der Technik — unabhängig davon, ob Sie einen Cloud-Dienst oder Postfix auf eigenem Server nutzen. Das BSI empfiehlt p=reject in TR-03182. Der Vorteil: Mit Postfix haben Sie volle Kontrolle über alle E-Mail-Pfade und können als DKIM-Relay auch Legacy-Systeme absichern. §38 BSIG: Die Geschäftsleitung haftet persönlich.
Beobachtungsphase bei Postfix
Setzen Sie den DMARC-Record zunächst auf p=none und sammeln Sie 2–4 Wochen lang Reports. Die wichtigste Aufgabe in dieser Phase: alle ausgehenden E-Mail-Pfade inventarisieren. Postfix-Installationen haben typischerweise mehrere Pfade, die E-Mails erzeugen — und nicht alle laufen über den konfigurierten Milter. Prüfen Sie mit opendkim-testkey, ob OpenDKIM korrekt konfiguriert ist, bevor Sie mit dem Enforcement-Prozess beginnen.
Postfix-spezifische Quellen in Reports inventarisieren
- Primärer Postfix-Server: Prüfen Sie, ob
smtpd_milters = inet:localhost:8891korrekt gesetzt ist und OpenDKIM alle ausgehenden Signaturen erzeugt. DMARC-Reports zeigen die sendende IP — vergleichen Sie mit Ihrem SPF-Record - Webserver mit PHP mail() oder Kontaktformular: PHP
mail()sendet über/usr/sbin/sendmail— dieser Pfad läuft nicht übersmtpd_milters, sondern übernon_smtpd_milters. Ohne diesen Parameter inmain.cffehlt die DKIM-Signierung für alle lokalen Mails - Cron-Jobs und Monitoring-Alerts: System-E-Mails von Cron laufen ebenfalls über den lokalen Pfad. Prüfen Sie, ob
non_smtpd_milters = $smtpd_miltersin Ihrermain.cfgesetzt ist - Backup-MX (Secondary MX): Wenn Sie einen sekundären Mailserver als Backup betreiben, muss auch dort OpenDKIM konfiguriert sein. Ein Backup-MX ohne DKIM-Signierung erscheint in Reports als separate Fehlerquelle
Quarantäne und Reject bei Postfix
Bevor Sie auf p=quarantine wechseln, müssen alle E-Mail-Pfade DKIM-signiert sein. Prüfen Sie die OpenDKIM-Konfiguration: Mode sv aktiviert Signierung und Verifikation, Canonicalization relaxed/relaxed sorgt für Kompatibilität. KeyTable und SigningTable müssen alle verwendeten Absenderadressen abdecken. Wolf-Agents empfiehlt, mit pct=10 zu starten und jede Stufe mindestens 3–5 Tage zu beobachten. Der große Postfix-Vorteil: Sie können Postfix als DKIM-Relay konfigurieren — Legacy-Systeme senden an Postfix, der signiert und weiterleitet.
Postfix main.cf und OpenDKIM — kritische Parameter
- milter_protocol = 6: Aktiviert das Milter-Protokoll in Postfix für die Kommunikation mit OpenDKIM
- milter_default_action = accept: Bei OpenDKIM-Ausfall werden E-Mails trotzdem zugestellt — fail-open Verhalten verhindert Mailausfall bei Milter-Problemen
- smtpd_milters = inet:localhost:8891: Bindet OpenDKIM für eingehende SMTP-Verbindungen — deckt den Hauptpfad ab
- non_smtpd_milters = $smtpd_milters: KRITISCH — deckt alle lokalen E-Mail-Pfade ab: PHP mail(), Cron, sendmail. Ohne diesen Parameter sind lokale E-Mails nicht DKIM-signiert und scheitern bei p=reject
- KeyTable und SigningTable müssen alle Absender-Domains abdecken: Jede Domain, von der E-Mails gesendet werden, muss einen eigenen Eintrag haben. Fehlende Einträge führen zu unsignierten E-Mails für diese Domain
- Postfix als DKIM-Relay: Legacy-Systeme ohne eigene DKIM-Signierung können über Postfix als Smarthost senden — Postfix signiert dann im Namen der konfigurierten Domain. Dies ist ein wesentlicher Vorteil gegenüber Cloud-Anbietern
# Linux / macOS
dig _dmarc.ihre-domain.de TXT +short
# Windows (PowerShell)
Resolve-DnsName -Name _dmarc.ihre-domain.de -Type TXT | Select-Object -ExpandProperty Strings
# Erwartete Ausgabe nach Phase 3:
# "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@ihre-domain.de; fo=1" # OpenDKIM-Signierung lokal verifizieren
opendkim-testkey -d ihre-domain.de -s mail -vvv
# Erwartete Ausgabe (Schlüssel gefunden und gültig):
# key OK
# DKIM-Record im DNS prüfen
dig mail._domainkey.ihre-domain.de TXT +short Häufige Probleme bei Postfix-Enforcement
Die folgenden drei Probleme treten bei Postfix-DMARC-Enforcement besonders häufig auf. Alle drei sind Konfigurationsfallen, die bei Cloud-Anbietern nicht existieren — bei Self-Hosted-Postfix aber regelmäßig zu DKIM fail in Reports führen, bevor p=quarantine aktiviert wird.
PHP mail() umgeht DKIM-Signierung
Symptom: E-Mails von Webformularen und Kontaktseiten zeigen DKIM fail in den DMARC-Reports, obwohl der primäre Mailserver korrekt signiert.
Ursache: PHP mail() sendet direkt über /usr/sbin/sendmail, nicht über den SMTP-Port. Dieser lokale Pfad wird von smtpd_milters nicht erfasst. Wenn non_smtpd_milters in der main.cf fehlt oder falsch konfiguriert ist, werden diese E-Mails ohne DKIM-Signierung versandt.
Lösung: In main.cf sicherstellen, dass non_smtpd_milters = $smtpd_milters gesetzt ist. Alternativ PHP so konfigurieren, dass es über SMTP an localhost:25 sendet statt direkt über sendmail — dann greift smtpd_milters automatisch.
Cron-Jobs senden mit falschem Absender
Symptom: System-E-Mails von Cron erscheinen in Reports als root@hostname statt als monitoring@ihre-domain.de. DMARC fail, weil die From-Domain nicht mit der DKIM-signierten Domain übereinstimmt.
Ursache: Cron und andere System-Dienste verwenden den lokalen Unix-Nutzernamen als Absender. Der DKIM-Selektor ist nur für Ihre produktive Domain konfiguriert — hostname als Domain ist nicht in der OpenDKIM SigningTable enthalten und wird nicht signiert.
Lösung: In /etc/aliases Root-Mail auf eine korrekte Adresse umleiten und newaliases ausführen. canonical_maps in main.cf konfigurieren, um System-Absender auf die korrekte Domain umzuschreiben, sodass DKIM-Alignment greift.
Backup-MX ohne DKIM-Konfiguration
Symptom: E-Mails, die über den sekundären Mailserver versandt werden, zeigen DKIM fail in Reports. Das Problem tritt nur sporadisch auf und ist schwer zu reproduzieren.
Ursache: Nur der primäre Postfix-Server hat OpenDKIM konfiguriert, der sekundäre Backup-MX nicht. Bei Failover oder Load-Balancing sendet der Backup-MX E-Mails ohne DKIM-Signierung.
Lösung: OpenDKIM auf ALLEN ausgehenden Mailservern konfigurieren — primär und sekundär. Entweder denselben privaten DKIM-Schlüssel auf beiden Servern einsetzen oder separate Selektoren pro Server mit eigenen DNS-Records. Wolf-Agents empfiehlt separate Selektoren für bessere Nachvollziehbarkeit in Reports.
DMARC Enforcement-Roadmap auch für:
Wie steht Ihre Domain bei DMARC Enforcement?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.