DMARC Enforcement für Mailcow

Schritt-für-Schritt-Roadmap: vom Beobachtungs-Modus (p=none) über Quarantäne zu Reject. Bei Mailcow ist die volle Kontrolle Vorteil — parsedmarc, Rspamd-Logs und Wolf-Agents Stack-Detection liefern die Datenbasis für sichere Verschärfung.

DMARC-Policy prüfen Plattform entdecken
Mailcow · Enforcement-Roadmap
Von Wolf-Agents Security Team · Aktualisiert: 13. Mai 2026

DMARC Enforcement bei Mailcow (Self-Hosted Docker)

Mailcow bietet beim Enforcement zwei Vorteile gegenüber Managed-Providern: Sie haben die volle Sender-Kontrolle (alle ausgehenden Mails laufen durch Postfix/Rspamd) und Sie haben mit Rspamd ein integriertes DMARC-Modul, das eingehende Mails gegen die Absender-DMARC-Policy prüft. Für Aggregate-Reports ausgehender Mails empfangen Sie XML-Daten im Mailcow-Postfach und werten sie mit parsedmarc, dmarc-parser oder einem externen Tool aus.

Wegen der vollständigen Sender-Kontrolle können Mailcow-Betreiber DMARC direkt mit p=reject aktivieren (siehe DMARC-Anleitung für Mailcow). Diese Roadmap richtet sich an komplexere Setups: mehrere Mailcow-Domains, externe sendende Subdienste (Newsletter, Transaktions-Mail über Mailgun/SES), Mehrfach-MX oder eine vorsichtigere Migration aus einer bestehenden DMARC-p=none-Konfiguration.

Der Wolf-Agents Email Security Scanner prüft Ihre aktuelle DMARC-Policy-Stufe, erkennt einen veralteten pct-Teil-Rollout und bewertet ihn als Schwächung, markiert den fehlenden sp=-Subdomain-Override als Risiko-Punkt und erkennt SPF/DKIM-Drift nach Mailcow-Updates. Stack Detection findet zudem Provider-Wechsel beim Lieferanten oder eigenen Sub-Dienst — verlinkt zu VEC (Vendor Email Compromise) und SubdoMailing.

Für NIS2-pflichtige Unternehmen mit Mailcow-Infrastruktur gehört die DMARC-Policy in das Risikomanagement. NIS2 verlangt Maßnahmen zur Bewältigung von Sicherheitsvorfällen sowie Konzepte und Verfahren für den Einsatz von Kryptografie und gegebenenfalls Verschlüsselung — in Deutschland umgesetzt in § 30 BSIG. Eine bestimmte DMARC-Policy-Stufe nennt der Gesetzestext nicht; Enforcement ist für diese Maßnahmenbereiche eine etablierte technische Maßnahme: Die XML-Reports zeigen den Spoofing-Vorfall, p=reject beendet ihn und macht die SPF-/DKIM-Authentifizierung erst durchsetzbar. BSI TR-03108 empfiehlt p=reject. NIS2 Art. 23 (24h-Frühwarnung, 72h-Vorfallsmeldung) wird durch DMARC-Aggregate-Reports forensisch belegbar.

Ausführliche DMARC Enforcement Roadmap

1 Phase 1 von 4

Beobachtungsphase mit parsedmarc

Starten Sie mit p=none und richten Sie parsedmarc als IMAP-Client für das Mailcow-rua-Postfach ein. 1-2 Wochen Reports zeigen, welche externen Sender mit Ihrer Domain im Header-From auftauchen — Spoofing-Versuche und vergessene legitime Sender werden gleichermaßen sichtbar.

parsedmarc Setup (Phase 1) Beobachtung 
# DMARC-Record (Phase 1)
_dmarc.ihre-domain.de.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@ihre-domain.de; fo=1"

# parsedmarc installieren (Python 3.8+)
pip3 install parsedmarc

# parsedmarc.ini erstellen
cat > /etc/parsedmarc/parsedmarc.ini <<'EOF'
[general]
save_aggregate = True
save_forensic = True

[mailbox]
host = mail.ihre-domain.de
port = 993
ssl = True
user = dmarc-reports@ihre-domain.de
password = <das-passwort-aus-Mailcow-UI>

[elasticsearch]
hosts = http://elasticsearch:9200
EOF

# systemd-Service für tägliche Auswertung
parsedmarc -c /etc/parsedmarc/parsedmarc.ini

# Optional ohne Elasticsearch: HTML-Report
parsedmarc --imap-host mail.ihre-domain.de --imap-user dmarc-reports@... -o report.html
2 Phase 2 von 4

Quarantäne-Phase

Nach 1-2 Wochen sauberer Reports (alle Sender identifiziert, alle DKIM-Signaturen valide) wechseln Sie auf p=quarantine. Beobachten Sie die rua-Reports weiter — bleibt die Pass-Rate legitimer Sender stabil bei rund 100 %, gehen Sie eine Stufe weiter. Mit Mailcow können Sie diese Beobachtungsphase deutlich kürzer halten als bei Managed-Providern — Sie kennen alle Sender und können bei Problemen sofort intervenieren.

DMARC-Record Phase 2 Quarantäne 
# Quarantäne aktivieren, dann die rua-Reports beobachten
_dmarc  IN  TXT  "v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:dmarc-reports@ihre-domain.de; fo=1"

# Optional als vorsichtiger Start: t=y behandelt Fehler eine Stufe milder (wie p=none),
# die Aggregate-Reports laufen dabei normal weiter
_dmarc  IN  TXT  "v=DMARC1; p=quarantine; sp=quarantine; t=y; rua=mailto:dmarc-reports@ihre-domain.de; fo=1"

Mailcow-Vorteile in Phase 2

  1. Rspamd-Logs zeigen interne DMARC-Anomalien sofort: docker compose logs rspamd-mailcow | grep dmarc
  2. Bei Subdomain-Sendern (z.B. Newsletter-Container) sofort separate DKIM in Mailcow generieren
  3. Kein Provider-Lock-in beim Reporting — XML-Daten bleiben in Ihrer Hand
3 Phase 3 von 4

Reject-Phase und Full-Enforcement

Nach 1-2 Wochen p=quarantine ohne neue Anomalien wechseln Sie auf p=reject. Empfänger lehnen nicht-konforme Mails direkt mit SMTP-Status 550 DMARC policy ab. Wollen Sie die schärfste Stufe zunächst testen, setzen Sie p=reject; t=y — Fehler werden dann eine Stufe milder (wie Quarantäne) behandelt, während die Reports die reale Wirkung zeigen; nach stabiler Beobachtung entfernen Sie t=y. Auch wenn alles sauber aussieht, hat Phase 3 ein höheres Risiko-Profil als Phase 2.

DMARC-Record Phase 3 Reject 
# Reject aktivieren (volle Durchsetzung)
_dmarc  IN  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@ihre-domain.de; fo=1; ri=86400"

# Optional vorsichtiger Start: t=y behandelt Fehler eine Stufe milder (wie Quarantäne),
# nach stabiler Beobachtung t=y wieder entfernen
_dmarc  IN  TXT  "v=DMARC1; p=reject; sp=reject; t=y; rua=mailto:dmarc-reports@ihre-domain.de; fo=1; ri=86400"

Mit p=reject; sp=reject ist Ihre Mailcow-Domain auf die strengste DMARC-Policy gestellt: nicht authentifizierte E-Mails in Ihrem Namen sollen von empfangenden Servern abgewiesen werden. Der ri=86400-Tag setzt das Reporting-Intervall auf 24 Stunden.

4 Phase 4 von 4

Monitoring etablieren

Mailcow-Updates können (selten) das SPF/DKIM-Verhalten ändern. Externe Sender (Marketing-Tools, Cron-Skripte, vergessene Mail-Skripte) können DMARC fehlschlagen. Kontinuierliches Monitoring fängt das früh ab.

Monatliche Monitoring-Aufgaben

  1. parsedmarc Trend-Analyse: Anteil dmarc=pass vs. fail graphisch trenden — neue Sender im source_ip-Feld identifizieren
  2. Mailcow-Update-Check: Nach jedem ./update.sh die DKIM-Selektoren prüfen (manche Mailcow-Releases verändern den Default-Selektor)
  3. Rspamd-Version nach Mailcow 2025-10: Mit Release 2025-10 (PR #6830) ist Rspamd auf 3.13.2 — das verbesserte DMARC-Modul nutzt seit Version 3.0 das native rspamadm dmarc_report-CLI. Quelle: mailcow.email/posts/2025/release-2025-10/
  4. Redis-CVE-Fix 2025-10: Mailcow 2025-10 (PR #6829) updated Redis auf 7.4.6 — schließt CVE-2025-49844. Wer noch auf Pre-2025-10 läuft, sollte zeitnah patchen — Redis ist als Rspamd-Backend und Mailcow-Cache an kritischer Stelle der DMARC-Auswertung beteiligt.
  5. BIMI-Bereitschaft: Mit p=reject sind Sie BIMI-fähig — siehe BIMI-Kapitel (Phase 2 Provider-Expansion)
  6. Wolf-Agents Scanner monatlich: 165-Punkte-Analyse inklusive DMARC-Policy, sp=-Tag, Stack-Detection für externe Versender
  7. Forensik bei Vorfall: Bei einem aktiven Spoofing-Vorfall die parsedmarc-Datenbank der letzten 30 Tage als NIS2-Art.-23-Meldung-Belege aufbereiten
  8. Mailcow-Roadmap 2026 (Information-Gain Welle 2): Release 2026-01 (29. Januar 2026) brachte MTA-STS für Alias-Domains live (PR #6972 aus 2025-12), EAS/DAV-Zugriffsbeschränkungen und konfigurierbare Display-Namen. Release 2026-03 (10. März 2026) forciert 2FA-Einrichtung und Passwordless-Autodiscover, updated Rspamd auf 3.14.3 und SOGo auf 5.12.5. Release 2026-05 (12. Mai 2026) bringt Sicherheits-Updates für Postfix und Web-Interface mit HTML-Escaping in Sieve-Filter und Queue-Manager. DANE/ARC/PQC sind bis Mai 2026 nicht im Admin-UI integriert — siehe SMTP-TLS- und MTA-STS-Provider-Seiten für Manual-Konfiguration. Quelle: github.com/mailcow Releases (abgerufen 2026-05-13).

Häufige Fehler beim Mailcow-Enforcement

Diese drei Fehler treten beim DMARC-Enforcement mit Mailcow besonders häufig auf — jeder einzelne kann Enforcement aushebeln oder legitime Mails unbeabsichtigt blockieren.

Subdomain-Sender ohne separate DKIM-Konfiguration

Problem: Mailcow versendet von info@ihre-domain.de mit DKIM-Selektor dkim für die Hauptdomain — funktioniert. Aber von support@hilfe.ihre-domain.de versendet Mailcow mit d=hilfe.ihre-domain.de ohne DKIM-Public-Key im DNS. Bei p=reject; sp=reject blockt DMARC diese Mails komplett — der Hilfedesk-Postausgang bricht zusammen.

Lösung: Für jede Subdomain in Mailcow Configuration → Mail Setup → Domains → Add domain die Subdomain als separate Domain anlegen und einen eigenen DKIM-Key generieren. DNS-Record für dkim._domainkey.hilfe.ihre-domain.de anlegen.

parsedmarc verbindet nicht zu Mailcow-IMAP

Problem: parsedmarc läuft auf dem Mailcow-Host selbst und versucht mail.ihre-domain.de:993 über IPv4-Loopback zu erreichen, aber Mailcow-IMAP bindet nur an die externe IP. Die IMAP-Verbindung schlägt fehl, Reports werden nicht abgerufen, Sie haben keine Datenbasis für die Enforcement-Roadmap.

Lösung: parsedmarc auf einem separaten Host laufen lassen, der über das öffentliche Netz auf mail.ihre-domain.de:993 zugreift. Oder in der Mailcow-Konfiguration data/conf/dovecot/dovecot.conf zusätzlich an die Docker-internal-IP binden und parsedmarc-Container ins Mailcow-Netzwerk hängen.

Mailcow-Update-Rollback ohne DMARC-Rollback

Problem: Ein Mailcow-Update wird per ./update.sh ausgeführt, dann später per Backup zurückgerollt. Die in der Zwischenzeit neu generierten DKIM-Selektoren werden ungültig — der DNS-TXT-Record zeigt auf einen Schlüssel, den Mailcow nach Rollback nicht mehr hat. DMARC mit p=reject blockiert dann sofort alle ausgehenden Mails.

Lösung: Vor jedem Mailcow-Update das crypt-vol-1-Volume separat sichern: docker run --rm -v mailcowdockerized_crypt-vol-1:/data alpine tar czf - /data > crypt-backup-$(date +%Y%m%d).tar.gz. Bei Rollback das Volume aus dem Backup wiederherstellen, dann sind die DKIM-Keys konsistent.

NIS2, BSI TR-03108 und DSGVO Art. 32: Enforcement bei Mailcow

DMARC-Enforcement schließt den Sender-Authentifizierungs-Kreislauf — ohne p=reject liefert SPF/DKIM nur eine technische Information, die der Empfänger ignorieren darf. NIS2 verlangt Maßnahmen zur Bewältigung von Sicherheitsvorfällen sowie Konzepte und Verfahren für den Einsatz von Kryptografie und gegebenenfalls Verschlüsselung; in Deutschland umgesetzt in § 30 BSIG. Eine bestimmte DMARC-Policy-Stufe nennt der Gesetzestext nicht — Enforcement ist für diese Maßnahmenbereiche eine etablierte technische Maßnahme, weil es die vorhandene Authentifizierungs-Infrastruktur überhaupt erst durchsetzbar macht. BSI TR-03108 empfiehlt p=reject als Mindeststandard. DSGVO Art. 32 fordert technische Maßnahmen — eine durchsetzbare Policy verhindert Identitätsmissbrauch der Domain für Daten-Phishing oder BEC-Angriffe. NIS2 Art. 23 schreibt 24h-Frühwarnung, 72h-Vorfallsmeldung und 1-Monats-Abschlussbericht vor — parsedmarc-Datenbank-Exporte liefern die Forensik-Datenbasis für alle drei Fristen. Wolf-Agents prüft explizit den sp=-Tag der DMARC-Policy — fehlender Subdomain-Override = Risiko-Punkt-Markierung im 165-Punkte-Scan, verlinkt zu SubdoMailing.

DMARC-Enforcement-Roadmap auch für:

Microsoft 365 Google Workspace IONOS Strato All-Inkl Hetzner Netcup Postfix Exim Generisch

Wie steht Ihre Domain bei DMARC Enforcement?

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

E-Mail Security Check starten