ARC: die Authenticated Received Chain, erklärt

Von Thomas · virtueller CISO · 20. August 2026

Es gibt einen präzisen Moment in jedem DMARC-Projekt, in dem eine Angst wieder auftaucht: „Wenn ich auf p=reject gehe, zerstöre ich dann die Mailinglisten und die weitergeleitete Post meiner Nutzer?" Die Angst ist begründet. Post, die durch einen Vermittler läuft — eine Mailingliste, eine Adresse, die an eine andere weiterleitet — sieht ihre ursprüngliche Authentifizierung unterwegs beschädigt und scheitert bei der finalen Zustellung an DMARC, obwohl sie an der Quelle völlig legitim war. ARC ist die Antwort, die große Empfänger auf dieses Problem gebaut haben. Dieser Artikel erklärt, was ARC ist, wie es funktioniert und vor allem, was man nicht davon erwarten sollte.

Das Problem, das ARC löst: indirekte Post

DMARC verlangt, dass mindestens einer der beiden Mechanismen, SPF oder DKIM, mit der sichtbaren Absenderdomain ausgerichtet ist. Solange die Nachricht direkt vom Server des Absenders zu dem des Empfängers geht, ist alles gut. Das Problem beginnt in dem Moment, in dem sich ein Vermittler dazwischenschiebt.

Beispiel Mailingliste. Sie empfängt die Nachricht und sendet sie dann an alle ihre Abonnenten weiter — oft mit einem Präfix im Betreff ([Liste]) oder einer Abmelde-Fußzeile. Zwei Arten von Schaden entstehen:

SPF bricht, weil der Envelope umgeschrieben wird: Die Nachricht verlässt nun die Server der Liste, nicht die des Absenders. Die sendende IP ist nicht mehr durch dessen SPF-Eintrag autorisiert.
DKIM kann brechen, weil die Liste den signierten Körper oder die Header verändert hat: Die über die ursprüngliche Nachricht berechnete Signatur verifiziert nicht mehr.

Das Ergebnis: Wenn die Nachricht das finale Postfach erreicht, scheitert sie an ausgerichtetem SPF und ausgerichtetem DKIM. Steht die Absenderdomain bei p=reject, soll der Empfänger sie abweisen — eine authentische, von einem realen Menschen geschriebene Nachricht, zerstört, weil sie das Pech hatte, durch eine Liste zu laufen. Das ist der berüchtigte „Fehlalarm" der indirekten Post und der Hauptgrund, warum Leute zögern, ihre Policy zu verschärfen.

Was ARC ist

ARC — die Authenticated Received Chain, „authentifizierte Empfangskette" — wird durch die RFC 8617 beschrieben (2019, Status experimentell). Ihre Idee ist einfach zu formulieren: Da der Vermittler derjenige ist, der die Authentifizierung bricht, ist es an ihm, zu bezeugen, was er vor der Veränderung der Nachricht gesehen hat.

Konkret erfasst jeder Vermittler, der an ARC teilnimmt, in dem Moment, in dem er die Nachricht empfängt, das Authentifizierungsergebnis, das er feststellt („bei meiner Ankunft bestand diese Nachricht ausgerichtetes SPF und DKIM für beispiel.de"). Er versiegelt dieses Zeugnis kryptografisch und leitet die Nachricht dann weiter. Der finale Empfänger kann sich, wenn er diesem Vermittler vertraut, auf das ursprüngliche Ergebnis stützen — das von vor der Veränderung —, um über die Zustellung zu entscheiden, statt dem beschädigten Ergebnis zu trauen, das er selbst beobachtet.

Wenn mehrere Vermittler aufeinanderfolgen (eine Weiterleitung in eine Liste, die selbst weiterleitet), fügt jeder sein Glied hinzu. Zusammen bilden sie eine Kette: daher der Name.

Die drei ARC-Header

Jeder ARC-Teilnehmer fügt der Nachricht drei Header-Felder hinzu, nummeriert nach „Instanz" (i=1 für den ersten Vermittler, i=2 für den nächsten und so weiter):

ARC-Authentication-Results (AAR) — die Momentaufnahme der Authentifizierungsergebnisse (SPF, DKIM, DMARC), die der Vermittler bei Ankunft beobachtet hat, vor jeder Veränderung. Das ist das eigentliche Zeugnis.
ARC-Message-Signature (AMS) — eine Signatur, einer DKIM-Signatur sehr ähnlich, berechnet über die Nachricht (Header und Körper), so wie der Vermittler sie weiterleitet. Sie erfasst den Zustand der Nachricht an diesem konkreten Glied.
ARC-Seal (AS) — eine Signatur, die alle ARC-Header-Felder der vorherigen Instanzen plus das aktuelle AAR und AMS abdeckt. Es ist das Siegel, das die Kette verriegelt: Es schützt ihre Integrität und Reihenfolge, sodass ein Glied nicht entfernt oder umgeordnet werden kann, ohne dass es sichtbar wird.

Jedes ARC-Seal trägt eine Ketten-Validierungs-Kennzeichnung, cv= (chain validation), die none, pass oder fail lautet. Sie zeigt an, ob die Kette bis zu diesem Glied gehalten hat. Das jüngste Siegel fasst den Gesamtzustand zusammen: Eine Kette bei cv=pass ist von Ende zu Ende intakt.

Wie ein Empfänger sie nutzt

Wenn eine Nachricht mit einer ARC-Kette ankommt, geht der finale Empfänger in zwei Schritten vor. Zuerst validiert er die Kette: Sind die Siegel kryptografisch korrekt, in der richtigen Reihenfolge, unverändert? Wenn ja, steht die Kette bei cv=pass.

Dann — und hier spielt sich alles ab — entscheidet er, ob er den Vermittlern vertraut, die die Kette versiegelt haben. Wenn ja, kann er einen lokalen Policy-Override anwenden: Statt die Nachricht abzuweisen, weil sie hier und jetzt an DMARC scheitert, konsultiert er das älteste AAR, stellt fest, dass die Nachricht an der Quelle die Authentifizierung bestand, und stellt sie trotzdem zu. Die legitime Post der Mailingliste ist gerettet.

Diese Entscheidung bleibt vollständig in der Hand des Empfängers. ARC erzwingt nichts: Es liefert verwertbare Beweise, und der Empfänger wählt, ob er darauf reagiert. Die großen Postfachanbieter — Google, Microsoft und andere — bringen ARC in großem Maßstab an und honorieren es, was den Mechanismus in der Praxis wirklich nützlich macht, auch wenn er formal experimentell bleibt.

Ein konkretes Beispiel

Angenommen, ein Mitarbeiter schreibt an eine berufliche Mailingliste. Seine Nachricht verlässt den Server perfekt authentifiziert: SPF und DKIM ausgerichtet für die Absenderdomain. Die Liste empfängt sie, fügt [Fachgruppe] zum Betreff und eine rechtliche Fußzeile hinzu und sendet sie dann an dreihundert Abonnenten weiter. Unterwegs ist das SPF wertlos (die Post kommt nun von der Liste) und die DKIM-Signatur gebrochen (Betreff und Körper haben sich geändert). Bei einem Abonnenten, dessen Domain bei p=reject steht, sollte diese Nachricht abgewiesen werden.

Aber die Liste nimmt an ARC teil. Als sie die Nachricht empfing, versiegelte sie ein Glied, das bezeugt: „bei Ankunft bestand diese Nachricht die Authentifizierung für diese Domain". Der Abonnent ist bei einem großen Anbieter, der ARC honoriert: Er validiert die Kette, findet sie intakt (cv=pass), vertraut der Liste und stellt die Nachricht trotz des scheinbaren DMARC-Fehlers zu. Ohne ARC landete der Beitrag an die Liste im Papierkorb; mit ihm kommt er an. Genau dieses Szenario, tausendfach am Tag wiederholt, macht den Übergang zu reject weniger beängstigend, als er scheint — vorausgesetzt, wie wir sehen werden, es wird kein blindes Vertrauen daraus.

ARC ersetzt DMARC nicht — und ist nicht automatisch

Man muss ehrlich über die Grenzen sein, sonst erzählt man sich Geschichten.

Erstens beruht ARC vollständig auf Vertrauen. Technisch hindert nichts einen bösartigen Vermittler daran, eine Kette zu versiegeln, die behauptet, eine betrügerische Nachricht habe „an der Quelle die Authentifizierung bestanden". Ein gültiges ARC-Siegel beweist nur, dass die Kette nachträglich nicht manipuliert wurde — nicht, dass ihr Inhalt ehrlich ist. Deshalb gewährt ein Empfänger einen Override nur Vermittlern, die er kennt und für vertrauenswürdig hält. ARC verschiebt das Problem auf eine Frage der Reputation, es löscht es nicht.

Zweitens ist ARC kein Ersatz für DMARC oder für die Ausrichtungsarbeit. Es rettet nur legitime indirekte Post, die im Transit gebrochen wurde. Es tut nichts für eine Nachricht, die von Anfang an nicht authentisch war, und es entbindet in keiner Weise davon, SPF, DKIM und DMARC korrekt zu veröffentlichen. Wer die Rollen vermischt, sieht sich zuerst SPF, DKIM und DMARC gemeinsam erklärt an: ARC ist ein Flicken an den Rändern, nicht das Fundament.

Schließlich honorieren nicht alle Empfänger ARC, und nicht alle Vermittler versiegeln es. Es ist eine Verbesserungsschicht, ungleichmäßig ausgerollt, keine universelle Garantie.

ARC und der Übergang zu `p=reject`

Für jemanden, der seine Policy verschärfen will, ändert ARC still die Risikoberechnung. Die große Angst vor reject — legitime Post, die durch Listen und Weiterleitungen reist, verschwinden zu sehen — ist genau der Fall, den ARC bei den Empfängern, die es honorieren, retten soll. In der Praxis durchquert ein erheblicher Teil der indirekten Post Google oder Microsoft, die die Kette auszuwerten wissen. Das heißt nicht, dass sich das Thema ignorieren lässt, sondern dass das Risiko geringer ist, als oft angenommen.

Die richtige Methode ändert sich nicht: Die Policy steigt unter Beobachtung der Berichte, ohne anzunehmen, dass ARC überall abdeckt. Die vorsichtige Trajektorie wird in p=reject erreichen, ohne die E-Mails zu zerstören detailliert. ARC ist ein zusätzliches Netz, das von den Empfängern gespannt wird, keine Erlaubnis, mit geschlossenen Augen zu verschärfen.

Wo es in den Berichten sichtbar wird

ARC hinterlässt eine beobachtbare Spur. In den Rückmeldungen, die die Empfänger senden erscheint eine Quelle, die an der Ausrichtung scheitert, aber trotzdem zugestellt wurde, oft mit einer bewerteten Disposition none, begleitet von einem Grund des Typs „lokale Policy" — die Signatur eines Overrides, häufig an eine gültige ARC-Kette gebunden. Diese Zeilen zu erkennen bewahrt vor einem klassischen Fehler: zu glauben, eine „scheiternde" Quelle sei ein zu behebendes Problem, obwohl es sich um legitime indirekte Post handelt, die vom Empfänger gerettet wurde. Diese Nuance lesen zu können ist der Unterschied zwischen Panik über ein Scheinproblem und dem wirklichen Verständnis der eigenen Posture.

Muss man „ARC konfigurieren"?

Für die überwiegende Mehrheit der Domain-Inhaber lautet die Antwort nein — und das ist eine gute Nachricht. Anders als SPF, DKIM oder DMARC wird ARC nicht auf der eigenen Domain als kontrollierbarer DNS-Eintrag veröffentlicht. Es sind die Vermittler (Listen, Gateways, Weiterleitungsdienste) und die Empfänger, die es implementieren. Auf der Absenderseite ist nichts einzuschalten: Der Nutzen von ARC stellt sich passiv ein, wenn die Nachrichten durch Vermittler laufen, die versiegeln, und bei Empfängern ankommen, die honorieren.

Der einzige Fall, in dem ARC zur eigenen Angelegenheit wird, betrifft den Betrieb einer Infrastruktur, die Post empfängt und dann im Namen anderer weitersendet — ein Sicherheits-Gateway, ein Weiterleitungsdienst, eine Plattform, die relayt. Dort wird das korrekte Anbringen der ARC-Header zu einer Verantwortung, damit die Authentifizierung der weitergegebenen Nachrichten nicht bricht. Diese Aufgabe gehört zur selben Familie fortgeschrittener Standards wie MTA-STS und TLS-RPT: nützlich, gezielt und vor allem relevant für die, die Mail-Infrastruktur betreiben.

Kurz gesagt

ARC ist die Kette von Zeugnissen, die es einem Empfänger erlaubt, legitime, von einem Vermittler gebrochene Post zu retten, indem er sich auf die ursprüngliche Authentifizierung stützt statt auf das beschädigte Ergebnis, das er beobachtet. Drei Header (AAR, AMS, AS), eine Kettenvalidierung, ein Override, der der Diskretion des Empfängers überlassen bleibt — und auf Vertrauen gegründet ist. Es ist ein wertvolles Netz gegen die Fehlalarme der indirekten Post, honoriert von den großen Anbietern, aber weder ein Ersatz für DMARC, noch eine universelle Garantie, noch etwas, das sich auf der eigenen Domain konfigurieren ließe.

Der beste Weg, all das konkret zu sehen, bleibt der Blick auf die eigenen Flüsse. Eine Domain in den kostenlosen DMARC-Analyzer eingeben: Er zeigt die realen Quellen, ausgerichtet oder nicht, und hilft, das echte Problem von der indirekten Post zu unterscheiden, die Empfänger bereits zu retten wissen.