ARC und Mailinglisten-Lärm: Warum DMARC bei Weiterleitungen versagt – und wie RFC 8617 das löst

Das Problem: DMARC bricht bei Mailinglisten

Du hast DMARC sauber aufgesetzt, SPF und DKIM greifen, die Policy steht auf p=reject. Alles läuft – bis jemand deine E-Mail über eine Mailingliste weiterleitet. Plötzlich landen legitime Nachrichten im Spam oder werden abgewiesen. Was ist passiert?

Mailinglisten-Software wie Mailman, Listserv oder Google Groups verändert Nachrichten, bevor sie an die Abonnenten weitergehen. Ein neuer List-*-Header kommt hinzu, oft wird der Betreff mit einem Präfix versehen ([Listenname]), manchmal wird der Body leicht angepasst. Das reicht, um die DKIM-Signatur des ursprünglichen Absenders zu brechen. Gleichzeitig sendet die Mailingliste über eine eigene IP, die nicht im SPF-Record der Absenderdomain steht. Ergebnis: SPF schlägt fehl, DKIM ist ungültig – DMARC sieht eine nicht authentifizierte Nachricht und handelt entsprechend.

Was ARC ist und was es nicht ist

ARC steht für Authenticated Received Chain und ist in RFC 8617 spezifiziert. Das Protokoll löst kein Sicherheitsproblem im klassischen Sinne – es löst ein Vertrauensproblem in Weiterleitungsketten.

Die Idee: Jeder Intermediär (Mailingliste, Forwarder, Security-Gateway) signiert beim Weiterleiten drei neue Header:

• ARC-Authentication-Results – der Authentifizierungsstatus der Nachricht, wie der Intermediär ihn gesehen hat
• ARC-Message-Signature – eine DKIM-ähnliche Signatur über den Nachrichteninhalt zu diesem Zeitpunkt
• ARC-Seal – eine Signatur über die gesamte bisherige ARC-Kette

Der empfangende Mailserver kann diese Kette rückwärts auflösen. Wenn er dem ersten Glied der Kette vertraut – also der Mailinglisten-Software –, kann er entscheiden, die Nachricht trotz fehlgeschlagener DMARC-Prüfung zuzustellen.

Wichtig: ARC ersetzt DMARC nicht. Es gibt dem empfangenden Server zusätzliche Informationen, auf deren Basis er eine informierte Entscheidung treffen kann. Ob er das tut, liegt bei ihm.

Wie die Kette in der Praxis aussieht

Ein konkretes Beispiel: [email protected] schickt eine E-Mail an eine Mailingliste, die bei list.example.org betrieben wird. Die Liste leitet an [email protected] weiter.

1. Gmail empfängt die Nachricht von list.example.org.
2. SPF für example.com schlägt fehl – die sendende IP gehört der Mailingliste.
3. DKIM für example.com ist ungültig – der Betreff wurde verändert.
4. DMARC würde normalerweise reject oder quarantine auslösen.
5. Aber: list.example.org hat ARC-Header gesetzt und signiert. Gmail prüft die ARC-Kette, stellt fest, dass die Mailingliste beim Empfang eine gültige DMARC-Prüfung gesehen hat, und vertraut dieser Information.

Gmail, Microsoft 365 und Fastmail werten ARC-Ketten heute aktiv aus. Das ist keine Garantie für Zustellung, aber es verhindert, dass legitime Mailinglisten-Nachrichten pauschal abgewiesen werden.

Was du als DMARC-Operator tun kannst

ARC ist primär eine Aufgabe für Mailinglisten-Betreiber und Intermediäre, nicht für den ursprünglichen Absender. Trotzdem gibt es konkrete Maßnahmen:

Wenn du eine Mailingliste betreibst: Stelle sicher, dass deine Software ARC-Header setzt. Mailman 3 unterstützt ARC nativ. Postfix benötigt das opendkim-Paket mit ARC-Unterstützung oder ein dediziertes Tool wie arc-milter. Prüfe außerdem, ob deine Mailinglisten-Domain einen eigenen DKIM-Schlüssel hat – viele Mailinglisten re-signieren Nachrichten mit ihrer eigenen Domain, was DMARC-Alignment für die Listendomain herstellt.

Wenn du der ursprüngliche Absender bist: Du kannst ARC nicht direkt steuern, aber du kannst dafür sorgen, dass deine DKIM-Signatur möglichst robust ist. Vermeide es, Header zu signieren, die Mailinglisten typischerweise verändern (z. B. Subject). Signiere stattdessen den Body und die stabilen Header. Manche Sender nutzen l=-Tags, um nur einen Teil des Bodies zu signieren – das ist ein zweischneidiges Schwert und sollte mit Bedacht eingesetzt werden.

Wenn du DMARC-Reports auswertest: ARC-Fehler tauchen in deinen DMARC-Aggregate-Reports auf. Nachrichten, die über Mailinglisten kamen und DMARC nicht bestanden haben, sind dort als fail mit der sendenden IP der Mailingliste gelistet. Wenn du diese IPs erkennst und weißt, dass es sich um legitime Weiterleitungen handelt, kannst du das als bekanntes Muster dokumentieren – auch wenn du es nicht direkt beheben kannst.

Die Grenzen von ARC

ARC ist kein Allheilmittel. Ein paar Einschränkungen, die du kennen solltest:

Vertrauen ist nicht universell. Ob ein empfangender Server einer ARC-Kette vertraut, hängt von seiner eigenen Policy ab. Es gibt keine zentrale Liste vertrauenswürdiger ARC-Intermediäre – jeder Provider entscheidet selbst.

ARC schützt nicht vor Missbrauch. Ein Angreifer könnte theoretisch eine eigene ARC-Kette fälschen. Deshalb ist das Vertrauen in den ersten Intermediär entscheidend – und das basiert auf Reputation, nicht auf Kryptografie allein.

Nicht alle Mailinglisten-Software unterstützt ARC. Ältere Installationen von Mailman 2, Listserv oder proprietären Systemen setzen oft keine ARC-Header. Das ist ein Deployment-Problem, das sich langsam bessert, aber noch nicht gelöst ist.

DMARC-Reports als Frühwarnsystem

Der praktischste Schritt für jeden DMARC-Operator: Schau dir deine Aggregate-Reports genau an. Wenn du regelmäßig Failures von bekannten Mailinglisten-IPs siehst, ist das ein klares Signal, dass ARC entweder nicht konfiguriert ist oder nicht greift.

DMARCPulse zeigt dir genau diese Muster – welche Quellen regelmäßig scheitern, ob es sich um Weiterleitungen handelt, und ob die Failures auf ein ARC-Problem oder ein grundsätzliches Konfigurationsproblem hindeuten.

Prüf jetzt, wie deine Domain aufgestellt ist: Kostenloser Domain-Check auf DMARCPulse