ARC & SEG für Postfix — OpenARC-Milter und Inhaltsfilter

Bei Postfix ist ARC ein echtes MTA-Feature — anders als BIMI, das ein reiner DNS-Record ist. OpenARC läuft als Milter, eingebunden über smtpd_milters in /etc/postfix/main.cf, und signiert weitergeleitete E-Mails direkt im Mail-Transfer-Agent. Diese Anleitung zeigt den Build des aktiven flowerysong-Forks v1.3.0 mit den GNU Autotools, die Milter-Einbindung, den ARC-Public-Key im DNS und die SEG-Schicht mit rspamd oder einem vorgeschalteten Cloud-Gateway.

Postfix · Schritt für Schritt

ARC und SEG für selbst gehostete Postfix-Mailserver

Bei Postfix ist ARC ein echtes Feature des Mail-Transfer-Agents — und genau hier liegt der Unterschied zu BIMI: Während BIMI ein reiner DNS-Record ist, signiert ARC tatsächlich im MTA. Für Postfix übernimmt das OpenARC, eine Open-Source-Implementierung, die wie OpenDKIM als Milter über smtpd_milters in /etc/postfix/main.cf eingebunden wird. Ein weiterleitender Postfix versiegelt damit die geprüften Authentifizierungsergebnisse, bevor er die Nachricht weitergibt.

Quellenwahl ist entscheidend: Das ursprüngliche OpenARC-Repository des Trusted Domain Project (trusteddomainproject/OpenARC) ist seit 2018 inaktiv und kam nie über einen Beta-Status hinaus. Aktiv gepflegt wird ausschließlich der Community-Fork flowerysong/OpenARC, aktuell Version 1.3.0 (Oktober 2025). Dieser Fork wird mit den GNU Autotools aus dem Quellcode gebaut. Ein stabiles Debian- oder Ubuntu-Paket existiert Stand Mai 2026 noch nicht — ein ITP-Bug für die Paketierung ist eingereicht, apt-get install openarc funktioniert in den stabilen Releases aber noch nicht.

Hardening-Pfad: MXSPFDKIM via OpenDKIMDMARCDMARC-EnforcementMTA-STSDNS-Sicherheit → ARC & SEG (dieser Guide). Bedrohungs-Cluster: Ein SEG schützt selbst gehostete Postfächer vor Phishing und gefährlichen Anhängen.

ARC ist ein Experimental-Protokoll vor der Reklassifizierung als Historic

Eine ehrliche Einordnung gehört zur Aufwandsabschätzung: ARC (RFC 8617) trägt den IETF-Status Experimental, und das Working-Group-Dokument draft-ietf-dmarc-arc-to-historic der IETF DMARC-Arbeitsgruppe (Stand 22. April 2026) empfiehlt, RFC 8617 als Historic einzustufen und von neuen Deployments abzuraten. Der designierte Nachfolger ist DKIM2. Für einen bestehenden Postfix-Server mit Weiterleitungslast bleibt OpenARC dennoch sinnvoll — Google, Microsoft 365 und Yahoo werten ARC-Ketten aktiv aus. Wer aber neu plant, sollte den OpenARC-Aufwand gegen die absehbar begrenzte Restlaufzeit des Protokolls abwägen und die DKIM2-Entwicklung verfolgen.

1 Schritt 1 von 4

DMARC-Voraussetzung und Postfix/OpenDKIM-Stack prüfen

ARC bewahrt geprüfte Authentifizierungsergebnisse — es setzt also ein korrektes SPF/DKIM/DMARC-Setup voraus. Bei Postfix läuft die DKIM-Signierung typisch über das OpenDKIM-Milter. Prüfen Sie den Ist-Zustand, bevor Sie OpenARC ergänzen.

Terminal — DMARC, SPF, OpenDKIM-Milter, Postfix-Version Voraussetzung
# DMARC / SPF / DKIM als Voraussetzung der ARC-Kette prüfen
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-Signierung läuft bei Postfix üblich über OpenDKIM-Milter
postconf -n | grep smtpd_milters
# Erwartet z. B.: smtpd_milters = inet:localhost:8891

# Postfix-Version
postconf -d mail_version
# Erwartet: mail_version = 3.x.x   (Debian 12 / Ubuntu 24.04 LTS)
OpenARC ergänzt OpenDKIM — es ersetzt es nicht

OpenDKIM signiert ausgehende Mail mit DKIM, OpenARC versiegelt die Authentifizierungskette weitergeleiteter Mail mit ARC. Beide laufen als eigenständige Milter parallel an Postfix. Wenn OpenDKIM noch nicht eingerichtet ist, arbeiten Sie zuerst die DKIM-Anleitung für Postfix durch — ohne gültige DKIM-Signatur scheitert DMARC und ARC kann seinen Zweck nicht erfüllen.

2 Schritt 2 von 4

OpenARC v1.3.0 aus dem flowerysong-Fork bauen und konfigurieren

OpenARC wird aus dem Quellcode des aktiven flowerysong-Forks gebaut — das Build-System sind die GNU Autotools (autoreconf, configure, make). Nach der Installation erzeugen Sie ein ARC-Signierschlüsselpaar und legen die Konfiguration /etc/openarc.conf an.

Terminal — OpenARC v1.3.0 bauen flowerysong-Fork
# OpenARC v1.3.0 — aktiver flowerysong-Fork, Build mit GNU Autotools.
# Das Original trusteddomainproject/OpenARC ist seit 2018 inaktiv.

# Build-Abhängigkeiten (Debian/Ubuntu)
sudo apt-get update
sudo apt-get install build-essential autoconf automake libtool \
  libbsd-dev libjansson-dev libmilter-dev libssl-dev pkg-config

# flowerysong-Fork klonen und mit den Autotools bauen
git clone https://github.com/flowerysong/OpenARC.git
cd OpenARC
autoreconf -fiv
./configure --prefix=/usr/local
make
sudo make install

# Hinweis: "apt-get install openarc" funktioniert Stand Mai 2026
# nicht in stabilen Debian/Ubuntu-Releases — ein ITP-Bug zur
# Paketierung von OpenARC 1.3.0 ist eingereicht, aber noch offen.
Schlüssel + /etc/openarc.conf Konfiguration
# ARC-Signierschlüssel erzeugen
sudo mkdir -p /etc/openarc/keys
sudo openarc-genkey -d example.com -s arc2026 -D /etc/openarc/keys
sudo chown -R openarc:openarc /etc/openarc/keys
sudo chmod 600 /etc/openarc/keys/arc2026.private

# /etc/openarc.conf
Mode                  sv          # s=sign, v=verify
Canonicalization      relaxed/relaxed
Domain                example.com
Selector              arc2026
KeyFile               /etc/openarc/keys/arc2026.private
SignHeaders           from:to:subject:date:message-id
Socket                inet:8893@localhost
Syslog                yes
SyslogFacility        mail
Mode sv — signieren und verifizieren

Der Parameter Mode in der openarc.conf steuert die Betriebsart: s für Signieren, v für Verifizieren, sv für beides. Ein Postfix, der sowohl eingehende ARC-Ketten prüft als auch eigene weitergeleitete Mail versiegelt, nutzt sv. Der Socket bindet OpenARC an einen Port (hier inet:8893@localhost) — über genau diesen Socket spricht Postfix das Milter im nächsten Schritt an.

3 Schritt 3 von 4

OpenARC als Milter in Postfix einbinden und ARC-Key im DNS

Jetzt wird OpenARC tatsächlich in /etc/postfix/main.cf eingetragen — hier ist ARC ein MTA-Feature, kein DNS-Eintrag. Die Reihenfolge in smtpd_milters ist entscheidend: erst OpenDKIM, dann OpenARC. Der ARC-Public-Key wird zusätzlich im DNS veröffentlicht, im gleichen Format wie ein DKIM-Schlüssel.

/etc/postfix/main.cf — Milter-Einbindung + DNS MTA-Konfiguration
# OpenARC als Milter in /etc/postfix/main.cf einbinden.
# Reihenfolge entscheidend: erst OpenDKIM (8891), dann OpenARC (8893).
smtpd_milters = inet:localhost:8891, inet:localhost:8893
non_smtpd_milters = inet:localhost:8891, inet:localhost:8893

# ARC-Public-Key im DNS veröffentlichen (gleiches Format wie ein DKIM-Key):
arc2026._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3..."

# Dienste starten und testen
sudo systemctl enable --now openarc
sudo systemctl restart postfix
grep -i "openarc" /var/log/mail.log | tail -5
# ARC-Header in einer weitergeleiteten Mail:
grep -i "^ARC-" /var/log/mail.log | tail -5
Milter-Reihenfolge: OpenDKIM vor OpenARC

OpenARC muss die DKIM-Signatur und das Authentication-Results-Ergebnis der Nachricht sehen, bevor es das ARC-Set bildet. Steht OpenARC in smtpd_milters vor OpenDKIM, fehlt ihm diese Grundlage. Tragen Sie die Sockets daher in der Reihenfolge inet:localhost:8891 (OpenDKIM), dann inet:localhost:8893 (OpenARC) ein. Der ARC-Public-Key wird unter arc2026._domainkey.example.com veröffentlicht — der Selector ist frei wählbar, muss aber mit der openarc.conf übereinstimmen.

Information-Gain: Detail-Migrationspfad trusteddomainproject → flowerysong (Bestandssysteme)

Wer 2026 noch ein bestehendes OpenARC-Setup aus dem inaktiven trusteddomainproject-Repository betreibt (letzte Beta-Veröffentlichung 2018), sollte den Migrationsplan kennen: Der flowerysong-Fork ist drop-in-kompatibel, aber die Build-Schritte und einige Konfigurations-Optionen sind anders. Konkreter 6-Phasen-Migrationspfad ohne Downtime: (1) Vorbereitung: aktuelle /etc/openarc.conf sichern (cp /etc/openarc.conf /etc/openarc.conf.legacy), Selector und Schlüssel-Pfad notieren. (2) Build flowerysong v1.3.0 parallel: in einem separaten Verzeichnis (/opt/openarc-flowerysong/) das Repository klonen (git clone https://github.com/flowerysong/OpenARC.git), autoreconf -fiv && ./configure --prefix=/opt/openarc-flowerysong && make. (3) Konfig-Migration: die meisten openarc.conf-Direktiven übernehmen 1:1 — Selector, KeyFile, Domain, Socket, SignHeaders. Neu in v1.3.0: AuthResComments (Default false wegen Microsoft-Comment-Parser-Inkompatibilität — auf false belassen, sofern keine speziellen Anforderungen). (4) Test-Phase parallel: alten OpenARC auf Port 8893 lassen, neuen flowerysong-Build auf Port 8894 testen — über eine Test-Domain die ARC-Signierung verifizieren. (5) Cutover: alten OpenARC stoppen, neuen flowerysong-Build auf Port 8893 starten, Postfix-Reload (postfix reload) — Service-Unterbrechung < 5 Sekunden. (6) Cleanup: alten Build deinstallieren, apt-get remove openarc falls Distro-Paket genutzt wurde. Debian-Paketierungs-Hinweis: Ein ITP-Bug für die Debian-Paketierung von OpenARC 1.3.0 ist eingereicht (Bug #1126523), aber das Paket ist noch nicht in stable/testing — bis dahin Source-Build empfohlen.

4 Schritt 4 von 4

SEG-Schicht ergänzen und Verifikation

ARC sichert die Authentifizierungskette — ein SEG ergänzt die inhaltliche Filterung. Für selbst gehostetes Postfix gibt es zwei Wege: lokale Open-Source-Filter (rspamd, ClamAV) oder ein vorgeschaltetes Cloud-SEG mit Enterprise-Schutz. Anschließend verifizieren Sie die ARC-Kette im Mail-Log.

SEG-Optionen für Postfix Inhaltsfilter
# SEG-Schicht für selbst gehostetes Postfix — zwei Wege:

# Weg A: Lokale Filter (rspamd + ClamAV)
sudo apt-get install rspamd clamav clamav-daemon
# rspamd-Milter zusätzlich in /etc/postfix/main.cf:
# smtpd_milters = inet:localhost:8891, inet:localhost:8893, unix:/run/rspamd/milter.sock
# Solider Schutz, aber kein Sandboxing, begrenzte Threat Intelligence.

# Weg B: Cloud-SEG vorschalten (Enterprise-Schutz)
# MX-Record auf den SEG-Anbieter zeigen; Postfix akzeptiert dann
# nur noch Verbindungen aus den SEG-IP-Bereichen:
# smtpd_client_restrictions =
#   permit_mynetworks,
#   check_client_access cidr:/etc/postfix/seg-ips,
#   reject

Ergänzend prüfen Sie mit dem Wolf-Agents Email Security Check — dieser erkennt Postfix automatisch über die Banner-Detection für „ESMTP Postfix“, 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 Postfix

apt-get install openarc schlägt fehl

Problem: apt-get install openarc findet kein Paket. Ursache: OpenARC ist Stand Mai 2026 noch nicht in den stabilen Debian-/Ubuntu-Repositories — ein ITP-Bug für die Paketierung von Version 1.3.0 ist eingereicht, aber offen. Lösung: OpenARC aus dem aktiven flowerysong-Fork mit den GNU Autotools selbst bauen, wie in Schritt 2 beschrieben — nicht aus dem inaktiven Original-Repository.

OpenARC vor OpenDKIM in smtpd_milters eingetragen

Problem: ARC-Sets werden gesetzt, enthalten aber kein DKIM-Ergebnis. Ursache: OpenARC steht in smtpd_milters vor OpenDKIM und sieht die DKIM-Signatur noch nicht. Lösung: Reihenfolge korrigieren — erst inet:localhost:8891 (OpenDKIM), dann inet:localhost:8893 (OpenARC).

ARC-Public-Key nicht oder mit falschem Selector im DNS

Problem: Empfänger melden arc=fail oder ignorieren die ARC-Kette. Ursache: Der ARC-Public-Key fehlt im DNS oder der Selector in der openarc.conf weicht vom DNS-Record ab. Lösung: Public-Key unter <selector>._domainkey.example.com als TXT-Record veröffentlichen, Selector mit der openarc.conf abgleichen.

SEG-Schicht ganz weggelassen

Problem: OpenARC ist eingerichtet, eine inhaltliche Filterung fehlt aber komplett. Ursache: ARC wird mit einem SEG verwechselt — ARC authentifiziert die Weiterleitungskette, es filtert keine Inhalte. Lösung: Mindestens rspamd und ClamAV als lokale Filter ergänzen oder ein dediziertes SEG vorschalten — die BSI-Anforderung APP.5.3.A4 verlangt Spam- und Schadsoftware-Prüfung.

Compliance · NIS2 · BSI · DSGVO

Compliance: NIS2 lit. a + lit. e, BSI APP.5.3.A4, DSGVO mit Postfix

Ein selbst gehosteter Postfix mit OpenARC und einer SEG-Schicht erfüllt mehrere NIS2-Anforderungen: lit. a (Konzepte in Bezug auf die Risikoanalyse und Sicherheit für Informationssysteme) durch die inhaltliche Filterschicht, lit. d (Sicherheit der Lieferkette) durch die ARC-Absicherung der Weiterleitungskette und lit. e (Sicherheitsmaßnahmen bei Wartung, Schwachstellen-Management) durch die Versions-Hygiene von Postfix, OpenDKIM und OpenARC. 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 vollständig beim Betreiber.

Postfix-ARC-SEG-Compliance-Stack: NIS2 lit. a (SEG als Defense-in-Depth-Schicht) + NIS2 lit. d (OpenARC sichert die Forwarding-Lieferkette) + NIS2 lit. e (Versions-Hygiene von Postfix, OpenDKIM und OpenARC) + 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 Postfix automatisch über die Banner-Detection für „ESMTP Postfix“, bewertet ARC-Detection und SEG-Status im 165-Punkte-Scanner (ARC und SEG als je 5 Bonuspunkte). Da ARC ein IETF-Experimental-Protokoll mit absehbarer Restlaufzeit ist, dokumentiert Wolf-Agents den ARC-Status transparent statt ihn zu überhöhen. Cross-Verweis: Phishing und gefährliche Anhänge.

Wie steht Ihre Domain bei ARC & SEG · Postfix?

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