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 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, validiert den pct-Wert gegen die p=-Policy, 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 ist p=none keine ausreichende Compliance. NIS2 Art. 21 Abs. 2 lit. b (Bewältigung von Sicherheitsvorfällen) bindet Enforcement direkt an aktive Spoofing-Vorfälle — die XML-Reports zeigen den Vorfall, p=reject beendet ihn. Zusätzlich NIS2 Art. 21 Abs. 2 lit. h (Konzepte und Verfahren für den Einsatz von Kryptografie und Verschlüsselung): SPF/DKIM-Authentifizierung wird durch p=reject erst durchsetzbar. BSI TR-03108 empfiehlt p=reject. NIS2 Art. 23 (24h-Frühwarnung, 72h-Vorfallsmeldung) wird durch DMARC-Aggregate-Reports forensisch belegbar.
parsedmarc-Container-Integration mit Mailcow — 5-Schritte-Pipeline
Horizontale Pipeline mit 5 Schritten: Empfänger (Google/Microsoft) sendet täglich XML-Aggregate-Report an dmarc-reports@ihre-domain.de, Mailcow speichert in Mailbox (dovecot), parsedmarc-Container liest via IMAP per Cronjob, parsedmarc parsed XML → Elasticsearch, Kibana-Dashboard visualisiert. DSGVO-Vorteil: komplette Pipeline on-prem, keine externe Cloud-Datenverarbeitung. Konzern: Mailcow GmbH Bielefeld.
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.
# DMARC-Record (Phase 1)
_dmarc.ihre-domain.de. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@ihre-domain.de; fo=1; pct=100"
# 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.htmlQuarantäne-Phase mit pct-Erhöhung
Nach 1-2 Wochen sauberer Reports (alle Sender identifiziert, alle DKIM-Signaturen valide) wechseln Sie auf p=quarantine; pct=10. Mit Mailcow können Sie die pct-Erhöhung deutlich schneller fahren als bei Managed-Providern — Sie kennen alle Sender und können bei Problemen sofort intervenieren.
# Tag 1 — pct=10
_dmarc IN TXT "v=DMARC1; p=quarantine; sp=quarantine; pct=10; rua=mailto:dmarc-reports@ihre-domain.de; fo=1"
# Tag 4 — pct=50
_dmarc IN TXT "v=DMARC1; p=quarantine; sp=quarantine; pct=50; rua=mailto:dmarc-reports@ihre-domain.de; fo=1"
# Tag 7 — pct=100
_dmarc IN TXT "v=DMARC1; p=quarantine; sp=quarantine; pct=100; rua=mailto:dmarc-reports@ihre-domain.de; fo=1"Mailcow-Vorteile in Phase 2
- Rspamd-Logs zeigen interne DMARC-Anomalien sofort:
docker compose logs rspamd-mailcow | grep dmarc - Bei Subdomain-Sendern (z.B. Newsletter-Container) sofort separate DKIM in Mailcow generieren
- Kein Provider-Lock-in beim Reporting — XML-Daten bleiben in Ihrer Hand
Reject-Phase und Full-Enforcement
Nach 1-2 Wochen p=quarantine; pct=100 ohne neue Anomalien wechseln Sie auf p=reject. Empfänger lehnen nicht-konforme Mails direkt mit SMTP-Status 550 DMARC policy ab. Starten Sie wieder bei pct=10 und erhöhen Sie schrittweise — auch wenn alles sauber aussieht, hat Phase 3 ein höheres Risiko-Profil als Phase 2.
# Tag 1 — pct=10
_dmarc IN TXT "v=DMARC1; p=reject; sp=reject; pct=10; rua=mailto:dmarc-reports@ihre-domain.de; fo=1"
# Tag 7 — pct=50
_dmarc IN TXT "v=DMARC1; p=reject; sp=reject; pct=50; rua=mailto:dmarc-reports@ihre-domain.de; fo=1"
# Tag 14 — Final
_dmarc IN TXT "v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:dmarc-reports@ihre-domain.de; fo=1; ri=86400"
Mit p=reject; sp=reject; pct=100 ist Ihre Mailcow-Domain DMARC-konform nach BSI TR-03108 und NIS2-Stand-der-Technik geschützt. Der ri=86400-Tag setzt das Reporting-Intervall auf 24 Stunden.
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
- parsedmarc Trend-Analyse: Anteil
dmarc=passvs.failgraphisch trenden — neue Sender imsource_ip-Feld identifizieren - Mailcow-Update-Check: Nach jedem
./update.shdie DKIM-Selektoren prüfen (manche Mailcow-Releases verändern den Default-Selektor) - 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/ - 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.
- BIMI-Bereitschaft: Mit
p=reject; pct=100sind Sie BIMI-fähig — siehe BIMI-Kapitel (Phase 2 Provider-Expansion) - Wolf-Agents Scanner monatlich: 165-Punkte-Analyse inklusive DMARC-Policy,
sp=-Tag, Stack-Detection für externe Versender - Forensik bei Vorfall: Bei einem aktiven Spoofing-Vorfall die parsedmarc-Datenbank der letzten 30 Tage als NIS2-Art.-23-Meldung-Belege aufbereiten
- 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 Art. 21 Abs. 2 lit. b (Bewältigung von Sicherheitsvorfällen) bindet Enforcement direkt an laufende Spoofing-Vorfälle als reaktive Schutzmaßnahme. NIS2 Art. 21 Abs. 2 lit. h (Konzepte und Verfahren für den Einsatz von Kryptografie und Verschlüsselung) macht die Authentifizierungs-Infrastruktur überhaupt erst durchsetzbar. 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:
Wie steht Ihre Domain bei DMARC Enforcement?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.