ARC & SEG für Mailcow — ARC über Rspamd in der Mailcow-UI
Mailcow (mailcow-dockerized) ist der ARC-freundlichste der drei Self-Hosted-Stacks: ARC-Signierung übernimmt der mitgelieferte Rspamd-Container, die Schlüssel verwaltet die Mailcow-UI unter Configuration ARC/DKIM keys — kein manueller OpenARC-Build wie bei Postfix, kein Compile-Schalter wie bei Exim. Rspamd und ClamAV bilden zugleich die integrierte SEG-Schicht. Mailcow-Originaldokumentation auf Englisch — die hier verwendeten Begriffe wurden ins Deutsche übertragen.
ARC und SEG für Mailcow-Dockerized
Mailcow (mailcow-dockerized) ist ein Docker-basierter Mailserver-Stack mit Postfix als MTA, Dovecot und Rspamd. Bei Mailcow ist ARC ein integriertes Feature: Der Rspamd-Container signiert ausgehende Mail mit DKIM und versiegelt weitergeleitete Mail mit ARC. Die Schlüssel verwaltet die Mailcow-UI unter Configuration ARC/DKIM keys (Originalbezeichnung Englisch) — ein manueller OpenARC-Build wie bei Postfix oder ein Compile-Schalter wie bei Exim entfällt. ARC bleibt damit ein MTA-Feature, nur komfortabel im Container-Stack gekapselt.
Mailcow-Originaldokumentation auf Englisch: Die offizielle Mailcow-Dokumentation (docs.mailcow.email, Abruf 2026-05-21) ist englischsprachig — UI-Bezeichnungen wie Configuration und ARC/DKIM keys sind Originalbegriffe, die hier ins Deutsche übertragen wurden. Die ARC-Signierung läuft vollständig über den Rspamd-Container; ein Eingriff in data/conf/postfix/extra.cf oder die docker-compose.override.yml ist dafür nicht nötig.
Hardening-Pfad: MX → SPF → DKIM in der Mailcow-UI → DMARC → DMARC-Enforcement → MTA-STS → DNS-Sicherheit → ARC & SEG (dieser Guide). Bedrohungs-Cluster: Rspamd schützt Mailcow-Postfächer vor Phishing und gefährlichen Anhängen.
Dass Mailcow ARC bequem über die UI handhabt, ändert nichts am Standard-Status: ARC (RFC 8617) ist ein IETF-Experimental-Protokoll, das Working-Group-Dokument draft-ietf-dmarc-arc-to-historic (Stand 22. April 2026) empfiehlt die Reklassifizierung als Historic. Nachfolger ist DKIM2. Da Mailcow ARC ohne Zusatzaufwand mitliefert, ist der Betrieb für bestehende Forwarding-Szenarien unkritisch — Google, Microsoft 365 und Yahoo werten ARC aktiv aus. Mailcow-seitig bleibt der Aufwand minimal, weil die Pflege über update.sh mitläuft.
DMARC-Voraussetzung und Mailcow-Stack prüfen
ARC konserviert geprüfte Authentifizierungsergebnisse — SPF, DKIM und DMARC müssen korrekt arbeiten. Prüfen Sie zuerst die Mailcow-Version, den MAILCOW_HOSTNAME und die DMARC-Policy der Domain.
# Mailcow-Version (NIS2 lit. e — Update-Disziplin)
cd /opt/mailcow-dockerized
git log -1 --pretty=format:"%h %s %ai"
# MAILCOW_HOSTNAME — Pflicht-Hostname (Reverse-DNS / FCrDNS)
grep MAILCOW_HOSTNAME /opt/mailcow-dockerized/mailcow.conf
# DMARC / SPF als Voraussetzung der ARC-Kette
dig TXT _dmarc.ihre-domain.de +short
# Erwartet: v=DMARC1; p=quarantine; ... oder v=DMARC1; p=reject; ...
dig TXT ihre-domain.de +short | grep "v=spf1"
# DKIM-/ARC-Selector im DNS (Mailcow-Default-Selector: dkim)
dig TXT dkim._domainkey.ihre-domain.de +shortMailcow verwaltet DKIM- und ARC-Schlüssel gemeinsam unter Configuration → ARC/DKIM keys. Der DKIM-Selector (Mailcow-Default dkim) signiert ausgehende Mail; den ARC-Seal setzt Rspamd auf weitergeleitete Mail. Entscheidend für DMARC pass ist, dass die DKIM-Signatur am Empfänger validiert und das Domain-Alignment passt. Ist DKIM noch nicht eingerichtet, arbeiten Sie zuerst die DKIM-Anleitung für Mailcow durch.
ARC- und DKIM-Schlüssel in der Mailcow-UI verwalten
Mailcow erzeugt und verwaltet die Schlüssel über die Web-UI unter Configuration → ARC/DKIM keys. Die UI zeigt den Public-Key als fertigen DNS-TXT-Record an — diesen tragen Sie beim DNS-Provider ein. Danach signiert der Rspamd-Container DKIM und ARC automatisch.
# ARC- und DKIM-Schlüssel in der Mailcow-UI verwalten.
# Mailcow-Originaldokumentation auf Englisch — die hier verwendeten
# Begriffe wurden ins Deutsche übertragen.
#
# Browser: https://mail.ihre-domain.de/admin
# -> Configuration -> ARC/DKIM keys
# -> Domain auswählen, Selector setzen (Default: dkim),
# Schlüssellänge 2048 Bit, "Add ARC/DKIM key"
#
# Die UI zeigt den Public-Key als fertigen DNS-TXT-Record —
# diesen beim DNS-Provider eintragen:
dkim._domainkey.ihre-domain.de. IN TXT "v=DKIM1; k=rsa; t=s; p=MIIBIjAN..."
# Der Rspamd-Container signiert danach ausgehende Mail mit DKIM
# und versiegelt weitergeleitete Mail mit ARC — ohne weiteren Eingriff.Die Mailcow-UI zeigt den zu setzenden DNS-Record an — sie trägt ihn aber nicht selbst beim DNS-Provider ein. Sie übernehmen den vorgeschlagenen TXT-Record manuell ins DNS (Cloudflare, Hetzner DNS, Netcup, deSEC). Der BIMI- und ARC-Standard-Selector sind verschieden: ARC und DKIM teilen sich bei Mailcow den _domainkey-Mechanismus, ein BIMI-Record läge dagegen unter default._bimi.
Die häufigste Mailcow-bezogene Falschannahme im Internet — und in einigen älteren Mailcow-Anleitungen, der MDX-Quelle dieses Kapitels (siehe R4-Konvergenz-Backlog) sowie diversen Stack-Overflow-Posts — lautet: „Für ARC in Mailcow muss OpenARC installiert werden.“ Das ist falsch. Mailcow nutzt für ARC den Rspamd-Container (Standard-Komponente seit Jahren), nicht OpenARC als externen Milter. Konkrete Architektur: Im Mailcow-Stack laufen Postfix und Rspamd in separaten Containern; Postfix leitet ein- und ausgehende Mail über die Rspamd-Proxy-Worker-Schnittstelle (Standard rspamd_milter auf Port 11332 intern). Die ARC-Signierung erfolgt in Rspamd via arc.conf-Konfiguration im Container — die Mailcow-UI unter Configuration → ARC/DKIM keys rendert genau diese Konfiguration, sodass Sie nicht in den Container greifen müssen. Warum kein OpenARC bei Mailcow? Zwei Gründe: (1) Container-Konsistenz — eine zusätzliche Komponente außerhalb der docker-compose-Stack-Logik wäre eine Wartungs-Ausnahme. (2) Rspamd-Doppel-Rolle — Rspamd übernimmt bei Mailcow neben Spam-Filterung auch DKIM-Signing und ARC-Sealing; das ist ressourceneffizienter als drei separate Daemons (OpenDKIM + OpenARC + Spam-Filter). Drift-Vermeidung: Wer Anweisungen findet, die docker-compose.override.yml um einen OpenARC-Container ergänzen wollen, sollte das ablehnen — es entstehen Konflikte mit dem Rspamd-Sealing, und es widerspricht dem Mailcow-Stack-Design. Wenn Sie explizit OpenARC brauchen (z. B. wegen einer spezifischen flowerysong-v1.3.0-Feature wie AuthResComments), wechseln Sie zum Postfix-Stack (siehe ARC & SEG für Postfix), nicht zu einer Mailcow-Modifikation.
Mailcow-Rspamd-Architektur: Drift-Vermeidung gegen MDX-Faktenfabrikation
Mailcow nutzt Rspamd-Container für ARC, NICHT OpenARC. Konzeptioneller Vergleich Postfix-OpenARC vs Mailcow-Rspamd zur Drift-Vermeidung. Mailcow-Variable RSPAMD_DKIM_ARC_DOMAINS aktiviert ARC-Signing via Rspamd. Config in /etc/rspamd/local.d/dkim_signing.conf + arc.conf — Pattern-Klasse 1 Faktenfabrikations-Anker.
SEG-Schicht — Rspamd und ClamAV im Mailcow-Stack
Mailcow bringt seine SEG-Schicht bereits mit: Der Rspamd-Container übernimmt Spam-, Phishing- und Reputations-Scoring, der ClamAV-Container scannt Anhänge auf Schadsoftware. Beide sind Teil des Standard-Stacks — anders als bei Postfix oder Exim ist keine separate Installation nötig.
Rspamd und ClamAV liefern soliden Basis-Schutz — sie erreichen aber nicht das Niveau eines Enterprise-SEG mit Sandboxing, Time-of-Click-URL-Rewriting und herstellerübergreifender Threat Intelligence. Für KRITIS-Betreiber, die Finanz- und Gesundheitsbranche oder bei hohem Angriffsrisiko lässt sich ein dediziertes Cloud-SEG vorschalten: Der MX-Record zeigt dann auf das SEG, das gefilterte Mail an den Mailcow-Stack weiterreicht. Rspamd-Regeln verfeinern Sie in der Mailcow-UI; die ClamAV-Definitionen aktualisiert der Container-Stack selbst.
Verifikation per Container-Logs und update.sh
Die ARC-Signierung verifizieren Sie in den Container-Logs von Rspamd und Postfix sowie an einer weitergeleiteten Test-Mail. Das offizielle Werkzeug update.sh hält den gesamten Container-Stack aktuell — Pflicht für das Schwachstellen-Management nach NIS2 lit. e.
# ARC-/DKIM-Signing im Rspamd-Container prüfen
docker exec rspamd-mailcow rspamadm configdump dkim_signing | head -20
# Mail-Log des Postfix-Containers
docker exec postfix-mailcow grep -iE "dkim|arc" /var/log/mail.log | tail -10
# ARC-Header in einer weitergeleiteten Test-Mail
grep -i "^ARC-" empfangene-mail.eml | tail -5
# Update-Disziplin (NIS2 lit. e) — offizielles Mailcow-Werkzeug
cd /opt/mailcow-dockerized
./update.sh --check
# Update einspielen: ./update.sh
# Wolf-Agents Email Security Check: erkennt Mailcow-Setups über die
# Postfix-Container-Banner-Detection plus das MAILCOW_HOSTNAME-Muster.
Ergänzend prüfen Sie mit dem Wolf-Agents Email Security Check — dieser erkennt Mailcow-Setups über die Banner-Detection des Postfix-Containers in Kombination mit dem MAILCOW_HOSTNAME-Muster, bewertet die ARC-Detection und gleicht die MX-Records gegen die SEG-Provider-Datenbank ab. Das Monitoring überwacht die E-Mail-Sicherheit alle 6 Stunden.
Häufige Fehler bei ARC & SEG für Mailcow
Suche nach OpenARC im Mailcow-Stack
Problem: Es wird ein OpenARC-Container oder ein Eintrag in der docker-compose.yml gesucht. Ursache: Mailcow nutzt für die ARC-Signierung den Rspamd-Container, nicht OpenARC. Lösung: ARC wird über Configuration → ARC/DKIM keys in der Mailcow-UI verwaltet — kein separater ARC-Dienst, kein Eingriff in die Compose-Datei.
DKIM-/ARC-Key in der UI angezeigt, aber nicht im DNS publiziert
Problem: Der Schlüssel ist in der Mailcow-UI angelegt, Empfänger melden trotzdem dmarc=fail. Ursache: Der von der UI angezeigte Public-Key wurde nicht als TXT-Record beim DNS-Provider eingetragen. Lösung: In der UI auf den Eintrag klicken, den vorgeschlagenen DNS-TXT-Record kopieren und unter <selector>._domainkey.<domain> beim DNS-Provider veröffentlichen.
update.sh-Disziplin vergessen — Container-Stack veraltet
Problem: Der Mailcow-Stack läuft seit Monaten ohne ./update.sh; Postfix, Dovecot, Rspamd und nginx im Container haben offene CVEs. Ursache: Fehlende Update-Disziplin verletzt NIS2 lit. e. Lösung: ./update.sh --check regelmäßig ausführen und Updates monatlich einspielen — update.sh ist das offizielle Mailcow-Werkzeug aus der englischsprachigen Originaldokumentation.
Rspamd als vollwertiges SEG überschätzt
Problem: Die Annahme, der integrierte Rspamd-Schutz decke alle Bedrohungen ab. Ursache: Rspamd und ClamAV bieten soliden Basis-Schutz, aber kein Sandboxing und keine herstellerübergreifende Threat Intelligence. Lösung: Bei erhöhtem Schutzbedarf ein dediziertes Cloud-SEG vorschalten (MX-Umstellung) und den nativen Mailcow-Schutz als zweite Filterstufe behalten.
Compliance: NIS2 lit. a + lit. e, BSI APP.5.3.A4, DSGVO mit Mailcow
Ein Mailcow-Stack mit ARC über Rspamd und der integrierten SEG-Schicht erfüllt mehrere NIS2-Anforderungen: lit. a (Konzepte in Bezug auf die Risikoanalyse und Sicherheit für Informationssysteme) durch die Rspamd-/ClamAV-Filterschicht, lit. d (Sicherheit der Lieferkette) durch die ARC-Absicherung der Weiterleitungskette und lit. e (Sicherheitsmaßnahmen bei Wartung und Schwachstellen-Management) durch die Update-Disziplin via update.sh. Die BSI-IT-Grundschutz-Basis-Anforderung APP.5.3.A4 verlangt Spam- und Schadsoftware-Prüfung auf dem E-Mail-Server — bei Self-Hosting liegt diese Verantwortung beim Betreiber.
Mailcow-ARC-SEG-Compliance-Stack: NIS2 lit. a (Rspamd/ClamAV als Defense-in-Depth-Schicht) + NIS2 lit. d (ARC über Rspamd sichert die Forwarding-Lieferkette) + NIS2 lit. e (Update-Disziplin via update.sh) + BSI IT-Grundschutz APP.5.3.A4 (Spam-/Schadsoftware-Prüfung) + DSGVO Art. 32 (Schutz personenbezogener Daten). Wolf-Agents-USP: Der Email Security Check erkennt Mailcow-Setups über die Banner-Detection des Postfix-Containers plus das MAILCOW_HOSTNAME-Muster, bewertet ARC-Detection und SEG-Status im 165-Punkte-Scanner (ARC und SEG als je 5 Bonuspunkte) und ordnet den experimentellen ARC-Status transparent ein. Cross-Verweis: Phishing und gefährliche Anhänge.
ARC- und SEG-Anleitung für weitere Provider:
Wie steht Ihre Domain bei ARC & SEG · Mailcow?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.