Wenn Sie ein gewöhnlicher Absender sind und ein Leitfaden Ihnen gesagt hat, Sie sollten ARC ausrollen, irrt dieser Leitfaden gleich zweifach. ARC fügt ein Vermittler hinzu, während er die Nachricht von jemand anderem weiterleitet, ein ursprünglicher Absender hat also nichts zu versiegeln. Und die IETF-Arbeitsgruppe, die dafür zuständig ist, hat im April 2026 einen Entwurf veröffentlicht, der die Umstufung der Spezifikation auf Historic verlangt, mit der Begründung, das Experiment sei beendet.
Nichts davon macht ARC nutzlos zu lesen. Es erklärt weiterhin, warum eine weitergeleitete Nachricht zugestellt oder abgewiesen wurde, und Apple fragt weiterhin danach bei Mail, die an seine Postfächer weitergeleitet wird. Es zu lesen und es auszurollen sind verschiedene Entscheidungen, und nur eine davon wird eingestellt.
ARC hält fest, was ein Weiterleiter gesehen hat, und deshalb hat ein Absender nichts zu versiegeln
DMARC bricht beim Weiterleiten. Eine Mailingliste oder eine Weiterleitungsadresse leitet Ihre Nachricht von ihren eigenen Servern weiter, SPF scheitert also an einer Umschlagdomain, die nicht Ihre ist, und jede Änderung an Headern oder Text bricht Ihre DKIM-Signatur. Die Nachricht war beim Senden rechtmäßig und scheitert bei der Ankunft an der Authentifizierung.
ARC war die vorgeschlagene Antwort. Jeder Vermittler hält die Authentifizierungsergebnisse fest, die er bei der Ankunft gesehen hat, signiert diese Aufzeichnung und versiegelt die Kette von allem davor. Ein Empfänger am Ende kann dann das ursprüngliche Ergebnis so sehen, wie der erste Sprung es beobachtet hat, obwohl der Beleg selbst verschwunden ist.
Wer da signiert, ist der Weiterleiter und nicht Sie. Für ARC veröffentlichen Sie nichts, es gibt dafür keinen DNS-Record auf Ihrer Domain über den DKIM-Schlüssel hinaus, den ein Vermittler verwenden würde, falls Sie zufällig einer wären, und der Headersatz erscheint nur auf weitergeleiteten Nachrichten. Ein Leitfaden, der einer gewöhnlichen Versanddomain sagt, sie solle "ARC aktivieren", hat es mit DKIM verwechselt.
Die Kette sind drei Header pro Sprung, und die Nummerierung ist die Prüfung
Jeder Sprung fügt drei Header hinzu, und RFC 8617 Abschnitt 5.2 macht sowohl den Satz als auch die Folge streng.
| Header | Was er trägt |
|---|---|
| ARC-Authentication-Results | Die Authentifizierungsergebnisse, die dieser Sprung bei der Ankunft sah |
| ARC-Message-Signature | Eine Signatur über die Nachricht, wie dieser Sprung sie empfangen hat |
| ARC-Seal | Eine Signatur über die bisherige Kette, mit dem Validierungsstatus der Kette |
Vier Regeln machen aus diesen Headern eine Kette statt eines Stapels:
- Die Instanznummern laufen von 1 aufwärts, lückenlos, bis höchstens 50. Eine Lücke oder eine Wiederholung ist eine fehlerhafte Kette und keine Kette mit einem fehlenden Glied.
- Jede Instanz hat genau einen von jedem der drei Header. Ein Duplikat ist ein Fehler.
- Das Siegel bei Instanz 1 muss
cv=nonetragen, und jede spätere Instanz musscv=passtragen. Dieser Wert ist die Aussage des Signierers über alles davor. - Ein
cv=failbei der höchsten Instanz beendet die Kette dort. Hat ein Sprung einmal einen Fehlschlag festgehalten, stellt nichts danach die Kette wieder her.
Die Struktur ist offline prüfbar und die Signaturen sind es nicht, und das ist die gesamte Form dessen, was ein Header-Werkzeug ehrlich sagen kann. Ein Leser, der auf die höchste Instanz schaut und den dort gefundenen Wert meldet, hat die entscheidende Prüfung übersprungen, denn erst die Lückenlosigkeit ab 1 macht die Folge bedeutungsvoll.
Die IETF stellt ARC ein und sagt es in klaren Worten
draft-ietf-dmarc-arc-to-historic-00, veröffentlicht am 22. April 2026 von Todd Adams von Proofpoint und John Levine von Taughannock Networks, ist ein Arbeitsgruppendokument und kein Einzelvorschlag. Es löst RFC 8617 ab, falls es angenommen wird, und verlangt, die Spezifikation als Historic zu kennzeichnen.
Seine Schlussfolgerungen sind ungewöhnlich direkt. Das Experiment ist vorbei. Wer es umsetzt und betreibt, sollte sich künftig nicht auf ARC verlassen und weitere internetweite Ausrollungen einstellen. Wer es bereits betreibt, sollte die Abschaltung planen oder die Nutzung auf kontrollierte Kontexte innerhalb einer Domain beschränken. Neue Ausrollungen werden abgeraten, weil sie für die Mailverarbeitung unwahrscheinlich nützliche Informationen liefern.
Die angegebene Begründung ist nicht, dass die Kryptografie versagt hätte. Sie ist, dass Verifikation ohne Reputation eine Durchsetzungsrichtlinie nicht sicher außer Kraft setzen kann. Wer auswertet, muss entscheiden, ob er jedem Signierer der Kette traut, bevor er auf dessen Aussagen hin handelt, und das heißt, ein Reputationssystem für Vermittler zu betreiben, und nach zehn Jahren hat niemand eines gebaut, das internetweit funktioniert. Gebaut wurden stattdessen Erlaubnislisten von Vermittlern, denen man ohnehin traute, was bilateral funktioniert und sich nicht verallgemeinern lässt. Der Entwurf nennt das die Kernlektion: Signaturen sind kein Vertrauen.
Eine zweite Einschränkung ist konkreter. Verändert ein Vermittler eine Nachricht, benennt ARC zwar, wer sie verändert hat, hat aber keinen Mechanismus, um zu sagen, was geändert wurde oder warum, der Empfänger ist also wieder beim Beurteilen der Reputation des Vermittlers. Die brauchbaren Teile fließen in die DKIM-Nachfolgearbeit ein, derzeit DKIM2 genannt, die eine parallele Kette und ein eigenes Vertrauensgeflecht von Sprung zu Sprung vermeidet.
Halten Sie den Status ehrlich fest: Das ist ein Internet-Draft und kein RFC. Er läuft im Oktober 2026 ab, wenn er nicht weiterkommt. Was er dokumentiert, ist allerdings weniger ein Vorschlag als eine Beschreibung dessen, wo die Arbeit bereits aufgehört hat.
Apple ist der einzige Anbieter, der noch danach fragt, und er fragt den Weiterleiter
Apples Absenderanforderungen, veröffentlicht im Februar 2025, fragen nach ARC bei Mail, die an Apple-Postfächer weitergeleitet wird. Es ist der einzige der vier großen Anbieter, der überhaupt danach fragt, und der ehrliche Grund, ARC in einem Prüfwerkzeug überhaupt zu zeigen.
Lesen Sie den Geltungsbereich genau, denn dort wird es falsch wiedergegeben. Die Anforderung betrifft weitergeleitete Mail, und wer sie erfüllen kann, ist der Weiterleiter. Betreiben Sie einen Weiterleitungsdienst, eine Mailingliste oder ein Mail-Gateway, dann geht es um Sie. Versenden Sie Marketing- oder Transaktionsmail von Ihrer eigenen Domain, dann nicht, und keine Einstellung auf Ihrer Seite erzeugt eine ARC-Kette.
Die anderen drei großen Mailbox-Anbieter fragen nach SPF, DKIM und DMARC, und keiner erwähnt ARC. Über die Domains, die wir für den Unspam 2026 Email Deliverability Benchmark testen, veröffentlichen 48 % eine DMARC-Richtlinie, und das ist die Arbeit, die wirklich unerledigt ist.
Was stattdessen zu tun ist, wenn Weiterleitung Ihr DMARC bricht
Das Problem, für das ARC gebaut wurde, ist echt und braucht weiterhin eine Behandlung. Die verfügbaren Antworten sind weniger exotisch.
- Sorgen Sie dafür, dass DKIM ausgerichtet ist und die Header signiert, die überleben. DKIM ist der Bezeichner, der überhaupt durch eine Weiterleitung kommt, weil er die Nachricht abdeckt und nicht die Verbindung. Ist nur SPF ausgerichtet, nimmt die Weiterleitung Ihnen den einzigen bestehenden Bezeichner.
- Halten Sie die Liste der signierten Header konservativ. Eine Signatur über Header, die Vermittler routinemäßig umschreiben, bricht öfter als eine über das Wesentliche.
- Lesen Sie Ihre DMARC-Berichte, bevor Sie die Weiterleitung als Ursache annehmen. Weiterleiter tauchen als unbekannte Quellen auf, die DKIM bestehen und SPF verfehlen, was eine unverwechselbare Form ist und sich leicht von echten Problemen trennen lässt.
- Bleiben Sie nicht wegen Weiterleitungen bei
p=none. Mail, die ausgerichtetes DKIM besteht, übersteht die Weiterleitung, und die Berichte sagen Ihnen vor jeder Durchsetzung, welche Quellen das nicht tun. - Betreiben Sie einen Vermittler, verfolgen Sie die DKIM2-Arbeit, statt jetzt eine ARC-Ausrollung zu beginnen.
Unser Leitfaden zu DMARC-Records behandelt die Richtlinie und die Berichte, und der Bezeichner, den eine Weiterleitung zuerst bricht, ist das Thema unseres Leitfadens zum Return-Path.
Was ein Prüfwerkzeug melden kann und was es zu melden ablehnen sollte
Eine ARC-Kette in einer empfangenen Nachricht ist ein Beleg über deren Weg, und genau so lohnt es sich, sie zu lesen.
Unser E-Mail-Header-Analysator meldet die Kettenstruktur: wie viele Sätze vorhanden sind, ob die Instanznummern eine lückenlose Folge ab 1 bilden, ob jeder Satz vollständig ist, ob die cv-Werte der Regel für ihre Position folgen, und die Domain, die jeden Sprung versiegelt hat. Ein cv=fail meldet er als die Stelle, an der die Kette endete.
Was er nicht tut, ist die Signaturen zu verifizieren, und er sagt Ihnen nicht, dass die Kette vertrauenswürdig ist. Das sind verschiedene Aussagen, und der Entwurf ist ausdrücklich darin, dass Kettengültigkeit ohne ein Reputationsurteil keine Grundlage für eine Zustellentscheidung ist. Ein Werkzeug, das ein grünes ARC-Abzeichen druckt, behauptet etwas, auf das kein Empfänger hin handeln würde.
Für die Records, die die Zustellung wirklich entscheiden, behandelt unser Leitfaden zur E-Mail-Authentifizierung, wie SPF, DKIM und DMARC voneinander abhängen. Um die Authentifizierungsergebnisse an einer echten Nachricht zu sehen, samt jeder ARC-Kette, die sie unterwegs aufgesammelt hat, machen Sie einen kostenlosen Spam-Test.
