ARC wird eingestellt: Was das für E-Mail-Authentifizierung und Mailinglisten bedeutet

Was ist ARC – und warum war es überhaupt nötig?

Wer DMARC einsetzt, kennt das Problem: Eine E-Mail wird über eine Mailingliste oder einen Weiterleitungsdienst geleitet, und plötzlich schlägt die DMARC-Prüfung fehl. Der ursprüngliche Absender hat alles richtig gemacht – SPF, DKIM, DMARC – aber der zwischengeschaltete Server hat die Nachricht verändert oder eine neue IP-Adresse ins Spiel gebracht. Das Ergebnis: Die empfangende Seite sieht eine E-Mail, die die Authentifizierungsprüfungen nicht besteht.

Genau für dieses Szenario wurde ARC (Authenticated Received Chain) entwickelt. ARC ist ein Mechanismus, der die Authentifizierungsergebnisse einer E-Mail über mehrere Weiterleitungsschritte hinweg dokumentiert und weitergibt. Jeder zwischengeschaltete Server – ein sogenannter ARC-Sealer – fügt eine kryptografisch signierte Aufzeichnung der Authentifizierungsergebnisse hinzu. Der empfangende Server kann diese Kette nachvollziehen und entscheiden, ob er der ursprünglichen Authentifizierung vertraut, auch wenn SPF oder DKIM auf dem letzten Hop fehlschlagen.

ARC wurde 2019 als experimenteller RFC (RFC 8617) veröffentlicht. Experimentell bedeutet in der IETF-Welt: Es gibt Interesse, aber keine Garantie für breite Adoption oder langfristige Standardisierung.

Warum wird ARC jetzt eingestellt?

Nach Jahren als experimenteller Standard hat die IETF entschieden, ARC nicht in den Status eines vollständigen Internet-Standards zu heben. Die Gründe sind mehrschichtig:

• Mangelnde Adoption: Nur wenige Mailserver-Implementierungen haben ARC vollständig und korrekt umgesetzt. Die kritische Masse, die für einen funktionierenden Standard nötig wäre, hat sich nie eingestellt.
• Vertrauensproblem: ARC löst das Authentifizierungsproblem nur, wenn alle Beteiligten in der Weiterleitungskette ARC korrekt implementieren und wenn der empfangende Server dem ARC-Sealer vertraut. Dieses Vertrauensmodell ist in der Praxis schwer zu operationalisieren.
• Komplexität ohne klaren Mehrwert: Die Implementierung von ARC ist komplex, und der Nutzen hängt stark von der Umgebung ab. Für viele Betreiber war der Aufwand schlicht nicht gerechtfertigt.

Das Ergebnis: ARC bleibt zwar technisch nutzbar, wird aber nicht mehr aktiv weiterentwickelt. Wer heute auf ARC setzt, baut auf einem auslaufenden Fundament.

Was bedeutet das konkret für Mailinglisten?

Mailinglisten sind der klassische Anwendungsfall für ARC. Ein Nutzer schickt eine E-Mail an eine Liste, der Listenserver modifiziert die Nachricht (z. B. fügt einen Footer hinzu oder ändert den Reply-To-Header), und die modifizierte E-Mail wird an alle Abonnenten weitergeleitet. Dabei bricht in der Regel die DKIM-Signatur des ursprünglichen Absenders, und SPF schlägt fehl, weil die sendende IP nun die des Listenservers ist.

Ohne ARC – oder ohne eine funktionierende ARC-Implementierung auf allen beteiligten Servern – bedeutet das: Nachrichten von Mailinglisten werden von strikten DMARC-Policies (p=reject oder p=quarantine) blockiert oder in den Spam-Ordner verschoben.

Konkrete Szenarien, die jetzt Aufmerksamkeit brauchen:

• Eigene Mailinglisten (z. B. Mailman, Listserv, Sympa): Prüfen, ob der Listenserver DKIM im eigenen Namen signiert. Das ist die zuverlässigste Lösung: Der Listenserver wird zum legitimen Absender und signiert die E-Mail mit seinem eigenen DKIM-Schlüssel.
• Externe Listendienste: Anbieter wie Google Groups oder Mailchimp handhaben das unterschiedlich. Es lohnt sich, die aktuellen Authentifizierungspraktiken des jeweiligen Anbieters zu prüfen.
• Weiterleitungen auf Postfachebene: Klassische .forward-Weiterleitungen sind besonders anfällig. Hier hilft SRS (Sender Rewriting Scheme) für SPF, aber DKIM bleibt ein Problem, wenn der weiterleitende Server nicht neu signiert.

Welche Alternativen gibt es?

Die Einstellung von ARC bedeutet nicht, dass das Problem der Weiterleitungsauthentifizierung gelöst ist – es bedeutet, dass es keine universelle protokollbasierte Lösung mehr gibt. Stattdessen müssen IT-Admins auf eine Kombination aus bewährten Praktiken setzen:

DKIM-Resigning durch den Listenserver: Der Listenserver entfernt die ursprüngliche DKIM-Signatur und signiert die E-Mail mit seinem eigenen Schlüssel. Der Absender im From-Header bleibt der ursprüngliche Nutzer, aber die DKIM-Signatur gehört zur Domain des Listenservers. Das funktioniert nur, wenn die DMARC-Policy der Absender-Domain nicht p=reject mit striktem Alignment erzwingt – oder wenn der Listenserver die From-Adresse auf seine eigene Domain umschreibt (Munging).

From-Header-Munging: Der Listenserver schreibt den From-Header um, z. B. von [email protected] auf nutzer via [email protected]. Das ist keine elegante Lösung, aber sie ist zuverlässig und weit verbreitet. Viele moderne Mailinglisten-Softwares machen das automatisch, wenn sie eine DMARC-Policy mit p=reject erkennen.

Subdomains für Mailinglisten: Wer eine eigene Mailingliste betreibt, kann eine dedizierte Subdomain verwenden (z. B. lists.beispiel.de) und für diese Subdomain eine eigene DMARC-Policy definieren, die weniger restriktiv ist.

Direkte Kommunikation statt Mailinglisten: In vielen Fällen sind moderne Kollaborationstools (Teams, Slack, etc.) eine praktischere Alternative zu klassischen Mailinglisten – auch wenn das keine technische Lösung des Authentifizierungsproblems ist.

Was sollten IT-Admins jetzt tun?

Die Einstellung von ARC ist ein guter Anlass, die eigene E-Mail-Infrastruktur zu überprüfen:

1. DMARC-Reports auswerten: Welche Quellen schicken E-Mails in eurem Namen, und welche davon schlagen bei DMARC fehl? Mailinglisten und Weiterleitungen tauchen hier oft als problematische Quellen auf.
2. Mailinglisten-Konfiguration prüfen: Signiert euer Listenserver im eigenen Namen? Ist From-Munging aktiviert, wenn nötig?
3. DMARC-Policy schrittweise verschärfen: Wer noch auf p=none steht, sollte den Weg zu p=quarantine und schließlich p=reject planen – aber erst, nachdem alle legitimen Sendequellen korrekt konfiguriert sind.
4. Externe Weiterleitungen inventarisieren: Gibt es Postfächer, die E-Mails automatisch weiterleiten? Diese sind oft unsichtbar in DMARC-Reports, können aber Probleme verursachen.

Die gute Nachricht: Die Grundprinzipien von DMARC, SPF und DKIM sind durch die ARC-Einstellung nicht berührt. Es fällt lediglich eine Krücke weg, die ohnehin nie breit genug getragen hat.

Prüft jetzt, wie eure Domain aufgestellt ist – der kostenlose Domain-Check auf dmarcpulse.io zeigt euch sofort, ob eure DMARC-, SPF- und DKIM-Konfiguration für eine ARC-freie Welt gerüstet ist.