Mailinglisten und DMARC: warum es bricht und wie ARC den Schaden auffängt

Von Thomas · virtueller CISO · 23. August 2026

Eine Nachricht kann ihren Ursprungsserver perfekt authentifiziert verlassen — SPF gültig, DKIM-Signatur intakt, DMARC-Ausrichtung tadellos — und trotzdem mit einem gescheiterten DMARC-Urteil in den Postfächern der Abonnenten einer Mailingliste ankommen. Auf der Absenderseite war nichts falsch konfiguriert, und niemand hat eine Fälschung versucht: Die Liste selbst hat die Authentifizierung zerstört. Beim Weiterverteilen hat sie die Nachricht angefasst (ein Präfix in der Betreffzeile, eine angehängte Fußzeile) und sie anschließend von ihrer eigenen Infrastruktur aus neu versendet. Beide Säulen, auf denen DMARC ruht, stürzen damit gleichzeitig ein.

Das Szenario ist alles andere als exotisch. Technische Diskussionslisten, Alumni-Listen, Vereinsverteiler, interne Firmenlisten: Überall dort, wo eine Software eine einzelne Nachricht empfängt, um sie an Hunderte von Abonnenten weiterzureichen, greift die hier beschriebene Mechanik. Und je weiter sich p=reject verbreitet — angetrieben von den Anforderungen der großen Anbieter an Massenversender —, desto häufiger verwandelt eine schlecht gerüstete Liste eine völlig legitime Domain-Policy in kollaterale Abweisungen: Echte Nachrichten, von echten Menschen geschrieben, verschwinden lautlos.

Dieser Artikel zerlegt das doppelte Scheitern, erzählt den Gründungsvorfall von 2014 nach, geht die Gegenmaßnahmen auf Listenseite durch, erklärt, was ARC wirklich repariert — und was nicht —, zeigt, wie dieser Verkehr in einem RUA-Bericht aussieht, und schließt mit Empfehlungen, getrennt nach Rolle: Listenbetreiber oder Domain-Inhaber.

Das doppelte Scheitern: DKIM bricht an der Veränderung, SPF an der Neuversendung

Was eine Mailingliste tut, passt in einen Satz: Eine Nachricht an diskussion@listen.beispiel.de wird empfangen und anschließend an jeden einzelnen Abonnenten neu ausgeliefert. Zwei alte Gewohnheiten begleiten diese Weiterverteilung. Die erste: den Inhalt verändern — ein Präfix [diskussion] in der Betreffzeile, damit die Liste auf einen Blick erkennbar ist, dazu eine Fußzeile mit dem Abmeldelink und der Adresse des Archivs. Die zweite: von den eigenen Servern der Liste aus versenden, mit einer Rücklaufadresse, die der Liste gehört, etwa diskussion-bounces@listen.beispiel.de, damit Zustellfehler bei der Liste landen und nicht beim Autor.

Jede dieser beiden Gewohnheiten zerstört eine Säule von DMARC. Die DKIM-Signatur, die der Server des Autors angebracht hat, deckt Betreff und Nachrichtentext ab: Ein einziges verändertes Byte — ein Präfix, eine Fußzeile — und die Prüfung scheitert bei jedem Empfänger. SPF wiederum wird gegen die Umschlagadresse der Neuversendung ausgewertet: die der Liste. Die Prüfung kann durchaus bestehen — die Server der Liste sind für die Domain der Liste ordnungsgemäß autorisiert —, doch dieses Bestehen ist für DMARC wertlos: Verlangt wird die Ausrichtung auf die Domain im From:-Header, also die des Autors. Eine Domain ohne jede Verwandtschaft zu beispiel.de richtet sich nicht aus, auch nicht im gelockerten Modus.

Das Ergebnis: DKIM scheitert, SPF besteht, aber für die falsche Domain, und DMARC — das nur einen der beiden ausgerichteten Mechanismen braucht, um zu bestehen — findet keinen von beiden. Der Vergleich mit der einfachen Weiterleitung macht die Besonderheit des Falls deutlich: Eine Weiterleitung von Postfach zu Postfach bricht SPF, lässt DKIM aber unangetastet, solange der Inhalt unverändert bleibt — DMARC überlebt dort also meistens. Eine Mailingliste hingegen bricht beides auf einmal. Genau das macht sie zum heikelsten aller Zwischenglieder und zu einer der klassischen Figuren jener Familie widersprüchlich wirkender Urteile, die in warum DMARC scheitert, obwohl SPF besteht auseinandergenommen wird.

2014, das Jahr, in dem die Listen p=reject kennenlernten

Das Problem wurde nicht allmählich entdeckt; es explodierte an einem Wochenende. Im Frühjahr 2014, nach massiven Spam-Kampagnen auf Basis gestohlener Adressbücher, stellte Yahoo seine Verbraucherdomain auf p=reject um — die erste Abweisungs-Policy, die je auf einer Domain mit Millionen menschlicher Nutzer veröffentlicht wurde. AOL folgte wenige Wochen später. Über Nacht konnte kein Abonnent mit einer Adresse dieser Domains mehr auf einer Mailingliste posten: Jede von der Liste weiterverteilte Nachricht scheiterte an DMARC, und jeder Empfänger, der die Policy durchsetzte, wies sie ab.

Der perverseste Effekt war nicht die Abweisung selbst, sondern ihre automatische Verarbeitung. Listen zählen Zustellfehler, um tote Adressen auszusortieren; die DMARC-Abweisungen trafen jedoch die weiterverteilten Kopien und wurden deshalb den Empfängern angelastet, deren Server die Nachricht ablehnten. Völlig unbeteiligte Abonnenten, die gar nichts gepostet hatten, fanden sich massenhaft abgemeldet wieder, weil ein Dritter von einer Domain mit p=reject geschrieben hatte. Ganze Gemeinschaften — darunter Arbeitslisten der IETF, ausgerechnet der Organisation, die E-Mail standardisiert — waren binnen Tagen desorganisiert.

Der Vorfall hinterließ zwei bleibende Spuren. Auf der Softwareseite mussten die Listenplattformen in aller Eile Abmilderungsmechanismen ausliefern; heute gehören sie zur Standardausstattung. Auf der Doktrinseite setzte sich eine Lehre durch: Wer p=reject auf einer Domain veröffentlicht, deren Adressen echten Menschen gehören, verpflichtet das gesamte Mail-Ökosystem, nicht nur die eigene Domain. Ein Jahrzehnt später hat die von den Gmail- und Yahoo-Anforderungen an Massenversender neu entfachte Adoptionswelle dem Thema seine volle Aktualität zurückgegeben: Mehr Domains unter strenger Policy bedeutet mechanisch mehr Reibung mit den Listen.

Die Auswege auf Listenseite: das From umschreiben oder gar nichts mehr anfassen

Vor dieser Wand haben sich die Listenbetreiber auf zwei große Strategien mit entgegengesetzter Philosophie geeinigt.

Die erste: die Umschreibung des From. Die Liste tritt nicht länger als bloßes Relais auf, sondern wird zur offiziellen Autorin der Nachricht. Der Header wird zu etwas wie From: "Marie Dupont via diskussion" <diskussion@listen.beispiel.de>, während die echte Adresse des Autors nach Reply-To wandert. DMARC bewertet fortan die Domain der Liste — die ihre eigenen Nachrichten per DKIM signiert und ihr eigenes SPF ausrichtet —, und alles besteht. GNU Mailman, auf technischen Listen allgegenwärtig, bietet dieses Verhalten als Option an, oft nur dann ausgelöst, wenn die Domain des Autors eine restriktive Policy veröffentlicht. Der Preis ist semantisch: Die private Antwort an den Autor wird zum Glücksspiel, Adressbücher speichern die Adresse der Liste statt der Person, und die echte Identität des Autors überlebt nur noch im Anzeigenamen.

Die zweite: die Nicht-Veränderung. Die Liste verzichtet auf das Betreffpräfix, auf die Fußzeile, auf jede Retusche des MIME-Körpers. Die ursprüngliche DKIM-Signatur bleibt dann intakt und beim Empfang prüfbar — und da DMARC nur einen einzigen ausgerichteten Mechanismus verlangt, genügt dieses überlebende DKIM: Die SPF-Fehlausrichtung wiegt nichts mehr. Es ist der kryptografisch sauberste Weg, den eine wachsende Zahl technischer Listen eingeschlagen hat. Seine Kosten sind ergonomischer Natur: Die vertrauten Markierungen verschwinden aus dem sichtbaren Inhalt, die Information wandert in die normierten Header List-Id, List-Post und List-Unsubscribe — für das Auge unsichtbar, von modernen Mailprogrammen aber ausgewertet. Ein dritter, historischer Weg — die Originalnachricht als Anhang in eine von der Liste erzeugte neue Nachricht einzupacken — bewahrt zwar alles, verschlechtert das Lesen aber so sehr, dass er praktisch verschwunden ist.

ARC, die Beweiskette der Authentifizierungsergebnisse

Beide vorgenannten Auswege beheben das Symptom, indem sie etwas opfern: die Identität des Autors oder die Gewohnheiten der Liste. ARC (Authenticated Received Chain, RFC 8617, 2019 mit experimentellem Status veröffentlicht) greift das Problem von einer anderen Seite an: Statt den Bruch zu vermeiden, dokumentiert es die Verwahrungskette, wie ein Übergabeprotokoll an jedem Glied.

Das Prinzip: Jedes Zwischenglied, das die Nachricht anfasst, stempelt ihr drei nummerierte Header auf (i=1, i=2 …). ARC-Authentication-Results protokolliert die beim Eintreffen bei diesem Zwischenglied beobachteten Authentifizierungsergebnisse — zum Beispiel spf=pass, dkim=pass, dmarc=pass in dem Moment, in dem die Liste die Nachricht vom Autor erhielt. ARC-Message-Signature signiert die Nachricht so, wie sie weiterversendet wird, Veränderungen eingeschlossen. ARC-Seal versiegelt die gesamte Kette und garantiert, dass kein Glied nachträglich manipuliert wurde. Der Endempfänger, der das DMARC-Scheitern feststellt, kann die Kette dann zurückverfolgen: Ist sie intakt und stammt das Siegel von einem als vertrauenswürdig eingestuften Zwischenglied, weiß er, dass die Nachricht vor der Liste korrekt authentifiziert war — und kann sich entscheiden, sie trotz der Policy zuzustellen. Das Protokoll wird im Detail in der Funktionsweise von ARC zerlegt.

Die Grenze steckt im letzten Satz: als vertrauenswürdig eingestuft. ARC authentifiziert eine Zeugenaussage, nicht die Ehrlichkeit des Zeugen. Jeder Server kann eine formal gültige ARC-Kette versiegeln, die behauptet, am Ursprung sei alles in Ordnung gewesen — auch ein Spammer, der seinen eigenen Müll versiegelt. Der Wert einer Kette hängt also vollständig von der Reputation ab, die der Empfänger dem Versiegler zubilligt, und ein öffentliches Register vertrauenswürdiger Zwischenglieder existiert nicht: Jeder große Empfänger pflegt sein eigenes. Gmail und Microsoft 365 versiegeln und honorieren ARC im großen Maßstab; eine kleine, selbst gehostete Liste auf einem anonymen Server wird ihre Siegel dagegen höflich ignoriert sehen. ARC fängt also einen großen Teil des legitimen Bruchs bei den großen Anbietern auf, ist aber weder eine universelle Garantie noch ein Grund, auf gute Praxis auf Listenseite zu verzichten.

Was ein RUA-Bericht zeigt

Für den Inhaber der Autorendomain hinterlässt all das einen wiedererkennbaren Fingerabdruck in den aggregierten Berichten. Die typische Signatur des Listenverkehrs: eine Quell-IP, die dem Server der Liste gehört, ein SPF, das scheitert oder ohne Ausrichtung besteht (die Umschlagdomain ist die der Liste), ein DKIM, das scheitert — oder für die Domain der Liste besteht, also ebenfalls nicht ausgerichtet ist —, und eine Disposition, die der veröffentlichten Policy folgt. Hat ein Empfänger eine ARC-Kette honoriert, sagt die Zeile es ausdrücklich:

<policy_evaluated>
  <disposition>none</disposition>
  <dkim>fail</dkim>
  <spf>fail</spf>
  <reason>
    <type>local_policy</type>
    <comment>arc=pass</comment>
  </reason>
</policy_evaluated>

Dieser Block liest sich so: Die Policy verlangte eine Sanktion, doch der Empfänger hat sie außer Kraft gesetzt (local_policy), weil die ARC-Kette eine saubere Authentifizierung weiter oben bezeugte. Diese Zeilen erkennen zu können, verändert die gesamte Interpretation eines Berichts. Wer sie als Fälschungsversuche zählt, bläht die wahrgenommene Bedrohung künstlich auf und gerät womöglich grundlos in Panik; umgekehrt stehen dieselben Zeilen ohne ARC-Ausnahme unter p=reject für echte Nachrichten echter Nutzer, die endgültig verloren sind. Ein Analysewerkzeug, das die Quellen benennt — diese IP ist ein bekannter Listenbetreiber, jene ein Universitätsserver —, verkürzt die Diagnose von Stunden auf Minuten.

Empfehlungen: Listenbetreiber und Domain-Inhaber

Die beiden Rollen halten nicht dieselben Hebel in der Hand, und wer sie verwechselt, landet bei unmöglichen Remediationsplänen.

Auf Betreiberseite ist die Rangfolge klar. Zuerst: aufhören, die Nachrichten zu verändern. Ohne Betreffpräfix und ohne Fußzeile überlebt das ursprüngliche DKIM, und das Problem verschwindet im Wesentlichen — die List-*-Header transportieren die Abmeldeinformation völlig ausreichend. Besteht die Kultur der Liste auf sichtbaren Markierungen, dann die From-Umschreibung aktivieren, idealerweise bedingt (nur für Autoren, deren Domain eine strenge Policy veröffentlicht). In jedem Fall gilt: mit der eigenen Domain der Liste DKIM-signieren, SPF und DMARC dieser Domain ausrichten, ARC-Siegel anbringen, sofern die Plattform es erlaubt, und die Bounce-Verarbeitung überwachen, damit nie wieder Unbeteiligte wegen der Policy eines Dritten abgemeldet werden.

Auf Inhaberseite hängt alles von der Population hinter den Adressen ab. Eine rein anwendungsgetriebene Domain — Transaktionspost, Benachrichtigungen, Marketing — hat keine Menschen, die auf Listen posten: Dort ist das Problem marginal und rechtfertigt keinerlei Verzögerung auf dem Weg zur strengen Policy. Eine Domain mit echten menschlichen Postfächern verlangt dagegen, die Berichte vor jeder Verschärfung zu beobachten: den Listenverkehr identifizieren, sein Volumen messen, die betroffenen Teams vorwarnen. Die Wahl zwischen Quarantäne und Abweisung bekommt hier eine sehr konkrete Bedeutung: p=quarantine lässt den Listennachrichten eine Chance zu landen — im Spam, aber wiederauffindbar —, während p=reject sie bei Empfängern, die ARC nicht honorieren, restlos vernichtet. Der Testmodus t=y von DMARCbis erlaubt es zudem, die Wirkung einer Policy zu bewerten, ohne sie durchzusetzen — Zeit genug, um die tatsächliche Exposition der Domain gegenüber Mailinglisten zu kartieren.

Fazit

Eine Mailingliste bricht DMARC gleich zweimal: Die Eingriffe in den Inhalt entwerten die DKIM-Signatur des Autors, und die Neuversendung von eigenen Servern lässt SPF ohne Ausrichtung zurück — keiner der beiden Mechanismen überlebt, und die legitime Nachricht scheitert. Der Gründungsvorfall von 2014 hat den Listen zwei Auswege aufgezwungen, die From-Umschreibung und die Nicht-Veränderung des Inhalts, jeder mit seinem eigenen Opfer. ARC fügt einen dritten Weg hinzu: eine versiegelte Kette, die die ursprüngliche Authentifizierung bezeugt und dem Empfänger erlaubt, die Nachricht zu rehabilitieren — vorausgesetzt, dem Versiegler wird vertraut, was den Nutzen heute den großen, bekannten Zwischengliedern vorbehält. In den RUA-Berichten ist dieser Verkehr an seinem charakteristischen Fingerabdruck und an den local_policy-Ausnahmen zu erkennen; ihn richtig zu lesen erspart sowohl den Fehlalarm als auch den lautlosen Verlust.

Der praktische Ausgangspunkt kostet nichts: Ein Durchlauf der Domain durch eine kostenlose DMARC-Analyse legt den Zustand der Authentifizierungsmechanismen offen und zeigt, wie die aktuelle Policy weitergeleiteten Verkehr behandeln würde. Um die Sache zu Ende zu bringen — die Listen in den Berichten identifizieren, die ARC-Ausnahmen verfolgen, die Policy verschärfen, ohne eine einzige legitime Nachricht zu verlieren —, eröffnet die Einrichtung eines Kontos die kontinuierliche Überwachung der Berichte, mit der nötigen Historie, um Woche für Woche den Listenbruch von der echten Fälschung zu unterscheiden.