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.

Postfix · Enforcement-Roadmap

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.

1 Phase 1 von 4

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

  1. Primärer Postfix-Server: Prüfen Sie, ob smtpd_milters = inet:localhost:8891 korrekt gesetzt ist und OpenDKIM alle ausgehenden Signaturen erzeugt. DMARC-Reports zeigen die sendende IP — vergleichen Sie mit Ihrem SPF-Record
  2. Webserver mit PHP mail() oder Kontaktformular: PHP mail() sendet über /usr/sbin/sendmail — dieser Pfad läuft nicht über smtpd_milters, sondern über non_smtpd_milters. Ohne diesen Parameter in main.cf fehlt die DKIM-Signierung für alle lokalen Mails
  3. Cron-Jobs und Monitoring-Alerts: System-E-Mails von Cron laufen ebenfalls über den lokalen Pfad. Prüfen Sie, ob non_smtpd_milters = $smtpd_milters in Ihrer main.cf gesetzt ist
  4. 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
2–3 Phase 2 + 3

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

  1. milter_protocol = 6: Aktiviert das Milter-Protokoll in Postfix für die Kommunikation mit OpenDKIM
  2. milter_default_action = accept: Bei OpenDKIM-Ausfall werden E-Mails trotzdem zugestellt — fail-open Verhalten verhindert Mailausfall bei Milter-Problemen
  3. smtpd_milters = inet:localhost:8891: Bindet OpenDKIM für eingehende SMTP-Verbindungen — deckt den Hauptpfad ab
  4. 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
  5. 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
  6. 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
Terminal / PowerShell Verifikation
# 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"
Terminal (Linux / macOS) OpenDKIM-Verifikation
# 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.

Wie steht Ihre Domain bei DMARC Enforcement?

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