ARC wird bei der IETF auf "Historic" gesetzt: müssen Sie sich 2026 noch darum kümmern?
Von CaptainDNS
Veröffentlicht am 8. Juni 2026
- Die IETF stuft ARC (RFC 8617) über den Draft
draft-ietf-dmarc-arc-to-historic(eingereicht am 22. April 2026) auf den Status "Historic" herab, nachdem die DMARC-Arbeitsgruppe am 16. April 2026 neu chartert wurde. - Nein, es ist kein "Tool, das ARC entfernt": Die Quelle ist eine Standardisierungsentscheidung der IETF, kein Softwarehersteller.
- "Historic" rät von neuen Deployments und domänenübergreifendem Vertrauen ab. Es macht RFC 8617 nicht ungültig und zwingt niemanden, bestehende Ketten nicht mehr zu prüfen.
- ARC bleibt 2026 in der Praxis erforderlich: iCloud (Großversender), Gmail-Forwarder (
arc=pass), Microsoft 365 (trusted sealers, reason code 130). - Wenn Sie eine Domain betreiben, müssen Sie an ARC wahrscheinlich nichts tun: stärken Sie SPF, DKIM und DMARC, überwachen Sie Ihre Reports, behalten Sie DKIM2 im Auge.
Seit Ende April 2026 kursiert eine Schlagzeile: "ARC is dead". In Foren und einigen Newslettern liest man bereits, dieses oder jenes Diagnose-Tool "entferne ARC", das Protokoll sei aufgegeben, man müsse alles neu konfigurieren. Die Realität ist ruhiger und vor allem differenzierter. ARC verschwindet nicht über Nacht, und die Nachricht stammt von keinem Softwarehersteller.
Die genaue Quelle ist ein Dokument der IETF: der Draft draft-ietf-dmarc-arc-to-historic, eingereicht am 22. April 2026 von J. Trent Adams (Proofpoint) und John Levine. Er schlägt vor, RFC 8617, die ARC spezifiziert, auf den Status "Historic" herabzustufen. Das ist eine Entscheidung im Standardisierungsprozess, getroffen innerhalb der frisch neu charterten DMARC-Arbeitsgruppe. Nichts zu tun mit einem Anbieter, der eine Funktion abschaltet.
Dieser Leitfaden erklärt nicht erneut die Mechanik von ARC im Detail (die Siegel-Header, die Ergebniskette). Dafür lesen Sie unseren Grundlagenartikel Was ist ARC (Authenticated Received Chain)?. Hier geht es um die Entscheidung: was "Historic" wirklich ändert, warum die IETF so entschieden hat und was Sie je nach Rolle tun müssen. Meist passt die Antwort in ein Wort: nichts, zumindest nichts, das speziell ARC betrifft. Dieser Artikel richtet sich an Mail-Administratoren, DevOps-Teams und Deliverability-Verantwortliche, die eine alarmierende Schlagzeile gelesen haben und eine klare Entscheidung wollen.
Prüfen Sie Ihre E-Mail-Authentifizierung, statt ARC hinzuzufügen
Die Nachricht, korrekt erklärt: ARC wird bei der IETF auf "Historic" gesetzt
Beginnen wir mit den Fakten, denn das Gerücht hat das Wesentliche bereits verzerrt. Kein Tool "entfernt" ARC. Was passiert, ist eine Änderung des dokumentarischen Status bei der IETF, der Organisation, die die Internet-Protokolle standardisiert.
Was sagt der Draft draft-ietf-dmarc-arc-to-historic?
Der Draft draft-ietf-dmarc-arc-to-historic ist ein kurzes Dokument, dessen einziger Zweck darin besteht, die Umstufung von RFC 8617 (der ARC-Spezifikation, veröffentlicht 2019) vom aktuellen Status auf den Status "Historic" zu beantragen. Er wurde am 22. April 2026 von J. Trent Adams von Proofpoint und John Levine eingereicht, zwei langjährigen Mitwirkenden an den Mail-Standards.
Ein solches Dokument ändert nicht den technischen Inhalt von ARC. Es schreibt das Protokoll nicht um, fügt keinen Header hinzu und entfernt keinen. Es ist ein "status-change document": Es hält eine Einschätzung der Community fest, welchen Platz ARC künftig in der Standardlandschaft einnehmen soll. Die Begründung passt in einen Satz: Die Verbreitung und das domänenübergreifende Vertrauen, die ARC voraussetzte, haben sich nie im erwarteten Umfang eingestellt, und die Standardisierungsarbeit konzentriert sich nun anderswo.
Zeitplan: Neuchartrung der DMARC-Arbeitsgruppe und Frist
Dieser Schritt ist Teil einer Reorganisation. Die DMARC-Arbeitsgruppe der IETF wurde am 16. April 2026 neu chartert, wenige Tage vor der Einreichung des Drafts. Eine Neuchartrung definiert Umfang und Prioritäten einer Gruppe neu; hier signalisiert sie, dass die Community manche Baustellen schließen und andere öffnen will.
Der Umstufungs-Draft durchläuft danach den üblichen Prozess: Diskussion in der Gruppe, Aufruf zur letzten Stellungnahme ("last call"), dann Prüfung durch die IESG. Die angepeilte Frist zur Finalisierung des status-change liegt um November 2026. Solange der Prozess nicht abgeschlossen ist, behält RFC 8617 formal seinen aktuellen Status; doch die Richtung ist klar und öffentlich.
Was "Historic" wirklich bedeutet (und was nicht)
Das Wort "Historic" klingt wie ein Todesurteil. Im Vokabular der IETF (definiert durch den Prozess in RFC 2026) hat es eine viel präzisere und viel weniger dramatische Bedeutung.
"Historic" bezeichnet einen Standard, der nicht mehr empfohlen wird, meist weil er ersetzt wurde, weil seine Verbreitung ausblieb oder weil die Erfahrung seine Grenzen gezeigt hat. Konkret heißt der Status Historic Folgendes:
- Er rät von neuen Deployments des Protokolls ab;
- er signalisiert, dass die Community für die Zukunft nicht mehr auf diesen Mechanismus setzt;
- er rät davon ab, neue domänenübergreifende Abhängigkeiten auf diesem Protokoll aufzubauen.
Dagegen bedeutet "Historic" nicht Folgendes:
- es ist keine Ungültigkeitserklärung: RFC 8617 bleibt ein veröffentlichtes und lesbares Dokument, seine Header bleiben syntaktisch gültig;
- es ist kein Verbot: niemand muss aufhören, bestehende ARC-Ketten zu erzeugen oder zu prüfen;
- es ist kein Schalter: kein Server hört auf zu funktionieren, weil ein Draft eingereicht wurde.
Diese Unterscheidung ist der Kern des Artikels. Auf dem Papier veraltet heißt nicht tot in der Praxis. Der Rest zeigt es.
Warum dieser Kurswechsel? Die Gründe der IETF
ARC wurde entworfen, um ein reales und hartnäckiges Problem zu lösen: Mail-Weiterleitung zerstört die Authentifizierung. Die Idee war elegant. Warum ordnet die Community es dann heute den historischen Standards zu? Drei Gründe greifen ineinander.
Begrenzte Verbreitung und brüchiges Vertrauen
ARC beruht auf einer starken Annahme: dass ein Empfänger dem Siegel vertraut, das ein Intermediär anbringt, den er nicht kontrolliert. Doch dieses Vertrauen lässt sich nicht verordnen. In der Praxis haben nur einige sehr große Akteure Listen "vertrauenswürdiger Sealer" veröffentlicht und gepflegt, und die domänenübergreifende Koordination im großen Maßstab hat sich nie etabliert. Ein Mechanismus, dessen Wert von verallgemeinertem Vertrauen abhängt, verliert seinen Nutzen, wenn dieses Vertrauen auf eine Handvoll Betreiber beschränkt bleibt.
Eine grundlegende Lücke, die ARC nicht schließt
ARC dokumentiert eine Kette von Authentifizierungsergebnissen, schützt aber nicht vor Replay. Eine legitim signierte Nachricht kann abgefangen und massenhaft erneut versendet werden, ohne dass die Signatur ungültig wird, weil weder DKIM noch ARC die Signatur an den Envelope oder die tatsächliche Route der Nachricht binden. ARC fügt Nachvollziehbarkeit hinzu, keine Ende-zu-Ende-Integritätsgarantie. Die Community kam zu dem Schluss, dass weitere Investitionen in ARC eher ein Pflaster verstärken als die Wunde behandeln würden.
Ein Aufwand, der sich auf den Nachfolger konzentriert
Die IETF lenkt die Arbeit lieber auf einen Mechanismus, der die Ursache angeht, statt ARC weiter zu verfeinern. Dieser Nachfolger ist DKIM2, derzeit in Standardisierung, der zugleich Quelle und Ziel jedes Hops signiert und die Replay-Lücke schließt. ARC auf Historic umzustufen ist auch ein Richtungssignal: investiere keine Energie mehr in die Erweiterung von ARC, schau auf DKIM2. Darauf kommen wir am Ende des Artikels zurück.
Das Paradox: ARC bleibt 2026 in der Praxis erforderlich
Hier ist, was die alarmierenden Schlagzeilen vergessen. Genau in dem Moment, in dem die IETF ARC den historischen Standards zuordnet, nutzen es die drei größten Mailanbieter der Welt aktiv. Für ein Postfach ist ARC quicklebendig.
Apple und iCloud: ARC für Großversender
Seit dem 25. Februar 2025 wendet Apple verschärfte Anforderungen für Versender mit hohem Volumen an iCloud an. Die Dokumentation beschreibt ausdrücklich den Einsatz von ARC, um die Authentifizierungsergebnisse zu bewahren, wenn eine Nachricht über einen Intermediär läuft, bevor sie ein iCloud-Postfach erreicht. Anders gesagt: Ein Anbieter, der Mail an iCloud weiterleitet und die ARC-Kette korrekt versiegelt, bekommt seinen Traffic besser behandelt als einer, der das nicht tut.
Google und Gmail: die Forwarder signieren, Gmail liest arc=pass
Gmail ist vermutlich der weltweit größte ARC-Nutzer. Wenn eine Nachricht weitergeleitet wird (automatische Umleitung, Alias, Mailingliste über die Google-Infrastruktur), bringen die Google-Forwarder ARC-Header an. Beim Empfang liest Gmail das Ergebnis arc=pass, um zu erkennen, dass die ursprüngliche Authentifizierung vor der Weiterleitung gültig war, und vermeidet so, DMARC bei einer legitimen Nachricht scheitern zu lassen, nur weil sie weitergeleitet wurde. ARC ist hier ein alltägliches Rädchen der Deliverability, unsichtbar, aber entscheidend.
Microsoft 365: trusted sealers und reason code 130
Microsoft 365 integriert ARC in sein zusammengesetztes Authentifizierungsurteil. Wenn eine Nachricht aufgrund einer Weiterleitung an DMARC gescheitert wäre, aber ein "trusted sealer" per ARC die ursprünglichen Ergebnisse bewahrt hat, kann Exchange Online Protection die Nachricht retten und trägt den reason code 130 in den Header compauth ein. Dieser Code signalisiert präzise, dass ein vertrauenswürdiges ARC-Siegel ein DMARC-Scheitern ersetzt hat. Der Mechanismus aus trusted sealers, reason code 130 und dem Indikator oda=1 wird in unserem Leitfaden Compauth=fail bei Microsoft 365 ausführlich beschrieben.
Auf dem Papier veraltet, im Postfach nicht tot
Der Kontrast ist deutlich. Bei der IETF wird ARC "Historic". In den Infrastrukturen von Apple, Google und Microsoft bleibt ARC ein Signal, das täglich gelesen und genutzt wird. Diese beiden Fakten widersprechen sich nicht. Der Status Historic sagt "baue keine neuen ARC-Abhängigkeiten mehr und setze für die Zukunft nicht darauf"; er sagt nicht "höre sofort auf, die ARC-Ketten zu verarbeiten, die die großen Betreiber noch erzeugen". Beides zu verwechseln heißt, einen Standardisierungs-Draft als Abschaltmeldung zu lesen.
Das Grundproblem ist nicht verschwunden: Weiterleitung zerstört SPF, DKIM und DMARC
Wenn ARC als unzureichend gilt, bleibt das Problem, das es anging, selbst ungelöst. Dieses Problem zu verstehen hilft zu entscheiden, was Sie tun (oder lassen) müssen.
Warum zerstört eine Umleitung oder Mailingliste die Authentifizierung?
Mail-Weiterleitung setzt den drei Säulen der Authentifizierung zu, jeder auf ihre Weise.
SPF scheitert, weil es die sendende IP-Adresse gegen die Envelope-Domain prüft. Wenn ein Umleitungsserver die Nachricht weitersendet, präsentiert sich seine IP beim Empfänger, und diese IP ist fast nie im SPF der Ursprungsdomain deklariert. Ergebnis: SPF richtet sich nicht mehr aus.
DKIM scheitert, sobald der Intermediär die Nachricht verändert. Eine Mailingliste, die eine Fußzeile hinzufügt, den Betreff mit einem Präfix [Liste] umschreibt oder einen Header anpasst, zerstört den signierten Hash. Die DKIM-Signatur, die den Body und bestimmte Header abdeckt, wird ungültig.
DMARC, das sich auf die Ausrichtung von SPF oder DKIM mit der From:-Domain stützt, scheitert daher ebenfalls, sobald beide gleichzeitig brechen. Eine völlig legitime Nachricht landet nach einer einfachen Weiterleitung bei dmarc=fail. Genau dieses häufige Szenario wollte ARC auffangen, indem es den Beweis transportiert, dass die Authentifizierung vor dem Relay in Ordnung war.
ARC war ein Pflaster, kein Heilmittel
ARC hat SPF oder DKIM nie repariert. Es fügte eine Bezeugungsebene hinzu: "Als ich diese Nachricht erhielt, habe ich diese Authentifizierungsergebnisse festgestellt, und ich versiegle sie." Nützlich, aber gebunden an das Vertrauen, das der Empfänger dem Sealer entgegenbringt, und machtlos gegen Replay. Genau deshalb besteht die dauerhafte Antwort nicht darin, ARC zu stapeln, sondern das zu stärken, was Sie wirklich kontrollieren: Ihre eigene Authentifizierung. Der künftige Standard DMARCbis, den wir im DMARCbis-Leitfaden detaillieren, klärt im Übrigen die Ausrichtung und das Policy-Management, ohne Ihre Konformität von einem Drittmechanismus abhängig zu machen.
Wer macht was: Domaininhaber oder Intermediär?
Das ist der wichtigste Abschnitt für die Entscheidung. Die verbreitetste Verwechslung besteht im Glauben, alle "implementierten ARC". Falsch. ARC ist ein Intermediär-Mechanismus. Die große Mehrheit der Leser dieses Artikels musste es nie und wird es nie ausrollen müssen.
Sie betreiben eine Domain: Sie implementieren ARC nicht
Wenn Sie den Mailversand für Ihre Organisation verwalten (eine Website, ein Shop, transaktionale Benachrichtigungen, ein Vertriebsteam), sind Sie ein Domaininhaber, kein Intermediär. Sie versiegeln keine ARC-Ketten, und der Status Historic verlangt von Ihnen keine Aktion an ARC. Was Sie tun müssen, betrifft Ihre eigene Authentifizierung:
- Stärken Sie SPF. Deklarieren Sie alle Ihre Versandquellen, beachten Sie die Grenze von 10 DNS-Anfragen, die einen
permerrorauslöst, und entwickeln Sie den End-Mechanismus von~allzu-all, sobald Sie Ihre Quellen im Griff haben. - Festigen Sie DKIM. Signieren Sie alle Ihre Ströme mit einem auf Ihre Domain ausgerichteten Schlüssel und organisieren Sie eine regelmäßige Schlüsselrotation.
- Bringen Sie DMARC voran. Wechseln Sie von
p=none(Beobachtung) zu einer durchsetzenden Policy (p=quarantine, dannp=reject), sobald Ihre Quellen unter Kontrolle sind. - Überwachen Sie Ihre DMARC-Reports. Die aggregierten Reports zeigen präzise, was bei der Weiterleitung bricht und welche Quellen scheitern. Das ist Ihr Dashboard.
- Fügen Sie ARC nicht als Notlösung hinzu. Sie können ARC nicht "aktivieren", um eine nachgelagert erlittene Weiterleitung zu reparieren: das Versiegeln wäre Sache des Intermediärs, nicht Ihre. Konzentrieren Sie den Aufwand auf das, was Sie kontrollieren.
Um den realen Zustand Ihrer Authentifizierung und die Art, wie Ihre Nachrichten empfangen werden, zu prüfen, ist ein Deliverability-Test besser als eine Vermutung; unser Leitfaden zum Deliverability-Test erklärt, wie Sie die Ergebnisse lesen.
Sie sind ein Intermediär: versiegeln Sie ARC weiter
Wenn Sie einen Dienst betreiben, der Mail für andere weiterleitet (ein Forwarder, eine Mailinglisten-Plattform, ein Security-Gateway, ein Umleitungsanbieter), sind Sie von ARC betroffen, und Ihr Vorgehen ist differenziert.
Zunächst: kappen Sie nichts abrupt. Apple, Google und Microsoft lesen weiterhin die ARC-Ketten, um legitime weitergeleitete Nachrichten zu retten. Von einem Tag auf den anderen mit dem Versiegeln aufzuhören würde die Deliverability der Mail verschlechtern, die Sie an diese Empfänger weiterleiten. Der Status Historic zwingt Sie keineswegs zum Aufhören.
Lesen Sie Historic dann als Richtungsanweisung, nicht als Stoppbefehl. Bauen Sie keine neue ARC-Abhängigkeit auf, die verallgemeinertes domänenübergreifendes Vertrauen voraussetzen würde, investieren Sie nicht in ehrgeizige ARC-Erweiterungen und bereiten Sie den Übergang zum Nachfolger vor. Verfolgen Sie die Entwicklung des IETF-Prozesses und die Ankündigungen der großen Empfänger: Sie geben in der Praxis das reale Tempo des ARC-Ausstiegs vor.
Und danach? DKIM2, der Nachfolger
ARC auf Historic umzustufen ergibt nur Sinn, weil ein besseres Werkzeug kommt. Dieser Nachfolger ist DKIM2.
Was DKIM2 behebt
DKIM2 ändert den Ansatz. Wo DKIM den Inhalt signiert und ARC ein versiegeltes Zeugnis hinzufügt, lässt DKIM2 jeden SMTP-Hop signieren und bindet dabei Quelle und Ziel der Nachricht. Jedes Relay fügt seine eigene nummerierte Signatur hinzu, und der bei jedem Hop genutzte Envelope wird abgedeckt. Direkte Folge: Replay, die Lücke, die keiner der beiden bisherigen Mechanismen schloss, wird erkennbar, weil eine außerhalb ihrer signierten Route erneut versendete Nachricht nicht mehr zur erwarteten Kette passt. DKIM2 behandelt die Ursache, wo ARC das Symptom behandelte.
Zeitplan und was sich für Sie ändert
DKIM2 befindet sich noch im Stadium der Internet-Drafts bei der IETF. Die genaue Syntax der Header und Parameter kann sich verschieben, und die ersten Deployments werden erst ab Ende 2026 erwartet. Für Sie als Domaininhaber verlangt das heute keine Aktion: Es gibt für DKIM2 vorerst nichts zu veröffentlichen oder zu konfigurieren. Die richtige Haltung ist Beobachtung. Verstehen Sie die Prinzipien, verfolgen Sie die Drafts und halten Sie eine gesunde DKIM-Infrastruktur, denn DKIM2 wird auf denselben DNS-Grundlagen aufbauen. Unser Artikel DKIM2: Neuerungen, Streichungen und wichtige Daten erläutert die neuen Header und die Chronologie der Drafts.
Fazit: Panik vermieden, Kurs auf DKIM2
Die Nachricht ist real, aber harmlos. Die IETF stuft ARC auf "Historic" um: ein Signal für das Ende eines Zyklus, keine Dienstabschaltung. Fassen wir nach Rolle zusammen.
Wenn Sie eine Domain betreiben, müssen Sie an ARC nichts tun, weder gestern noch heute. Stärken Sie SPF, DKIM und DMARC, überwachen Sie Ihre Reports und fügen Sie ARC niemals als Notlösung hinzu.
Wenn Sie ein Intermediär sind, versiegeln Sie ARC weiter, solange Apple, Google und Microsoft es lesen, aber bauen Sie keine neue Abhängigkeit mehr darauf auf und bereiten Sie den Übergang vor.
Und für alle ist der Kurs derselbe: Die nächste Stufe der E-Mail-Authentifizierung heißt DKIM2. Heute nichts zu tun, aber für morgen alles zu verstehen.
FAQ
Ist ARC 2026 tot oder aufgegeben?
Nein. Die IETF stuft ARC (RFC 8617) über den Draft draft-ietf-dmarc-arc-to-historic (eingereicht am 22. April 2026) auf den Status "Historic" um. "Historic" rät von neuen Deployments ab und signalisiert, dass die Community für die Zukunft nicht mehr auf ARC setzt, aber es macht die Spezifikation nicht ungültig und zwingt niemanden, ARC-Ketten nicht mehr zu erzeugen oder zu prüfen. In der Praxis nutzen Apple, Google und Microsoft es weiterhin aktiv.
Muss man ARC 2026 noch implementieren, wenn man es noch nicht hat?
Für die große Mehrheit der Organisationen nein. ARC ist ein Intermediär-Mechanismus (Forwarder, Mailinglisten, Gateways), kein Protokoll, das Domaininhaber selbst veröffentlichen. Wenn Sie den Mailversand für Ihre Organisation verwalten, mussten Sie ARC nie ausrollen, und der Status Historic ändert daran nichts. Konzentrieren Sie sich auf SPF, DKIM und DMARC.
Ich habe ARC bereits auf einem Forwarder oder Gateway ausgerollt: muss ich es entfernen?
Nein, kappen Sie nichts abrupt. Apple, Google und Microsoft lesen weiterhin die ARC-Ketten, um legitime weitergeleitete Nachrichten zu retten. Mit dem Versiegeln aufzuhören würde die Deliverability der Mail verschlechtern, die Sie an diese Empfänger weiterleiten. Der Status Historic lädt Sie nur ein, keine neue ARC-Abhängigkeit aufzubauen und den Übergang zu DKIM2 vorzubereiten, nicht sofort aufzuhören.
Soll man ARC-Header beim Empfang weiter prüfen?
Ja, wenn Sie einen Empfänger betreiben, der sich bereits auf ARC stützt. Der Status Historic verlangt nicht, das Prüfen bestehender Ketten einzustellen. Die großen Anbieter lesen weiterhin arc=pass, um zu vermeiden, dass DMARC bei legitimen weitergeleiteten Nachrichten scheitert. Solange diese Ketten zirkulieren, würde ihr Ignorieren legitime Mail benachteiligen.
ARC gegen DKIM2: was ersetzt ARC, und wann?
Der Nachfolger ist DKIM2, derzeit in Standardisierung bei der IETF. Anders als ARC, das ein versiegeltes Zeugnis hinzufügt, ohne die Replay-Lücke zu schließen, lässt DKIM2 jeden Hop signieren und bindet dabei Quelle und Ziel, was Replay erkennbar macht. DKIM2 ist noch im Draft-Stadium; die ersten Deployments werden erst ab Ende 2026 erwartet. Heute ist keine Aktion erforderlich, nur Beobachtung.
Wird RFC 8617 mit dem Status Historic gelöscht oder ungültig?
Nein. Der Status "Historic" im Sinne des IETF-Prozesses löscht oder entwertet ein Dokument nicht. RFC 8617 bleibt veröffentlicht, lesbar und technisch gültig: die ARC-Header bleiben syntaktisch korrekt, und bestehende Implementierungen funktionieren weiter. Historic ist ein dokumentarisches Signal, das von neuen Verwendungen abrät, keine Zurückziehung der Spezifikation.
ARC löste das Problem, dass Weiterleitung DMARC zerstört: ist das Problem anders gelöst?
Noch nicht vollständig. Weiterleitung zerstört SPF (die Relay-IP steht nicht im ursprünglichen SPF) und oft DKIM (Änderung von Body oder Headern), also scheitert DMARC. ARC war ein Pflaster, das den Authentifizierungsbeweis von vor dem Relay transportierte. Die dauerhafte Antwort besteht darin, Ihre eigenen SPF, DKIM und DMARC zu stärken, Ihre Reports zu überwachen und DKIM2 zu verfolgen, das die Ursache angeht, indem es jeden Hop signiert.
Historic bei der IETF: was ändert sich konkret für einen Admin?
Für einen Domain-Administrator kurzfristig: nichts. Sie implementieren ARC nicht, also berührt der Status Ihre Konfiguration nicht. Wichtig ist die Richtung: setzen Sie bei neuen Projekten nicht auf ARC, stärken Sie Ihre eigene Authentifizierung und bereiten Sie sich mental auf DKIM2 vor. Für einen Intermediär ist die Änderung eine Richtungsanweisung, kein Befehl zum sofortigen Stopp.
Vergleichstabellen herunterladen
Assistenten können die JSON- oder CSV-Exporte unten nutzen, um die Kennzahlen weiterzugeben.
📖 Glossar
- Historic (IETF-Status): Klassifikation des Standardisierungsprozesses (RFC 2026), die anzeigt, dass ein Protokoll für neue Deployments nicht mehr empfohlen wird, ohne ungültig oder verboten zu sein.
- RFC 8617: die Spezifikation von ARC (Authenticated Received Chain), veröffentlicht 2019.
- ARC (Authenticated Received Chain): Mechanismus, mit dem ein Intermediär die beobachteten Authentifizierungsergebnisse versiegelt, bevor er eine Nachricht weiterleitet.
- Trusted sealer: Intermediär, dessen ARC-Signatur von einem Empfänger als vertrauenswürdig gilt, zum Beispiel Microsoft 365.
- Replay: missbräuchliche Wiederverwendung einer legitim signierten Nachricht, erneut versendet, ohne die Signatur zu entwerten; eine Lücke, die ARC nicht schließt und die DKIM2 beheben will.
- DKIM2: Nachfolger, derzeit in Standardisierung bei der IETF, der Quelle und Ziel jedes Hops signiert, um Replay und Weiterleitung standzuhalten.
