ARC: Vertrauen in eine E-Mail erhalten, wenn sie Zwischenstationen passiert

Kurz gesagt: ARC (Authenticated Received Chain) ist ein Standard, mit dem Relays (Mailinglisten, Anti-Spam-Gateways, Weiterleitungen usw.) die von ihnen beobachteten Authentifizierungsergebnisse (SPF, DKIM, DMARC) bewahren und versiegeln können. Der Empfänger kann danach fundiert entscheiden, ob er der Nachricht vertrauen möchte, auch wenn SPF/DKIM nach einer Änderung oder Weiterleitung berechtigterweise fehlschlagen.

Warum brauchen wir ARC?

Ohne ARC kann eine legitime Nachricht nach einer Weiterleitung abgelehnt werden:

• SPF schlägt fehl, weil die sendende IP nun die des Relays ist.
• Die ursprüngliche DKIM-Signatur kann ungültig werden, wenn das Relay Header oder Body verändert (Banner, Footer, Anti-Spam-Markierung).
• Dadurch scheitert DMARC beim Empfänger, obwohl die E-Mail am Ursprung korrekt war.

ARC erlaubt dem Relay zu sagen: „Ich habe eine Nachricht erhalten, die SPF/DKIM/DMARC bestanden hat; hier sind meine Ergebnisse, und ich signiere sie.“
Der Zielserver untersucht die Kette der Siegel, um zu entscheiden, ob die E-Mail vertrauenswürdig bleibt.

Wie ARC funktioniert (Überblick)

An jedem Relay werden drei ARC-Header mit einem Index i=1, i=2, … ergänzt:

1. ARC-Authentication-Results (AAR) — übernimmt die SPF/DKIM/DMARC-Ergebnisse aus Sicht des Relays.
2. ARC-Message-Signature (AMS) — kryptografische Signatur der vom Relay gesehenen Nachricht (analog zu DKIM).
3. ARC-Seal (AS) — ein Siegel, das das Gesamtpaket (AAR + AMS + vorherige Siegel) signiert, um das Vertrauen zu verketteten.

Beispiel für ARC-Header (vereinfacht)

ARC-Seal: i=1; a=rsa-sha256; d=relay.example.net; s=arc1; cv=none; b=...
ARC-Message-Signature: i=1; a=rsa-sha256; d=relay.example.net; s=arc1; h=from:to:subject:date:message-id; bh=...; b=...
ARC-Authentication-Results: i=1; relay.example.net; spf=pass smtp.mailfrom=example.org; dkim=pass header.d=example.org; dmarc=pass header.from=example.org

• i=: Position in der Kette (1 beim ersten Relay, danach +1 pro Hop).
• d= / s=: Domain und Selector (wie bei DKIM), mit denen der öffentliche DNS-Schlüssel veröffentlicht wird.
• cv= (in ARC-Seal): Chain Validation, die das Relay für die von ihm gesehene Kette angibt; übliche Werte sind none, pass, fail.
• h=, bh=, b=: Standardfelder einer Signatur (Liste signierter Header, Body-Hash, Signatur).

„Ich sehe ARC-Header ohne Weiterleitung – ist das normal?“

Ja. Große Anbieter (Webmail, Kollaborationssuiten, Security-Gateways) signieren eingehende Nachrichten häufig standardmäßig mit ARC.
Ziele: einen internen Truth-Point setzen, den Weg der Nachricht durch die Infrastruktur nachverfolgen und spätere Weiterleitungen erleichtern, ohne Vertrauen zu verlieren.

Wie bewertet der Empfänger die ARC-Kette?

1. Alle ARC-Message-Signature- und ARC-Seal-Signaturen prüfen, beginnend mit dem höchsten i.
2. Kontinuität sicherstellen: kein fehlendes i; jedes Siegel muss die vorherigen abdecken.
3. cv= beobachten im letzten ARC-Seal (die Einschätzung des Signierenden zur Kette).
4. Mit DMARC abgleichen: schlagen die aktuellen SPF/DKIM fehl, entscheiden, ob den dokumentierten Ergebnissen vertrauenswürdiger ARC-Authentication-Results Glauben geschenkt wird.

Wichtig: ARC erzwingt nicht, eine Nachricht anzunehmen; es liefert verifizierbaren Kontext, damit der Empfänger präziser entscheiden kann.

Best Practices (Betreiberseite)

• ARC auf Ihren Relays signieren und verifizieren (Listen, Aliasse, Security-Gateways).
• Vorhandene ARC-Header beibehalten; gültige Siegel nicht entfernen.
• Schlüssel verwalten (Rotation, DNS-TTL, Überwachung fehlerhafter Verifikationen).
• Nach dem Versiegeln Änderungen minimieren (Banner, Umschreibungen) oder nach einer Änderung neu versiegeln.
• DMARC-Entscheidungen protokollieren, die durch ARC beeinflusst werden, um den Effekt messen zu können.

Häufige Fehler

• Einen ARC-Authentication-Results ohne ARC-Message-Signature und ARC-Seal hinzufügen.
• Die Kette unterbrechen (doppelte/fehlende i, Siegel deckt den vorherigen Eintrag nicht ab).
• Unbekannten d=-Domains blind vertrauen. Die Reputation des Signierenden ist relevant.

Häufig gestellte Fragen

Ersetzt ARC DKIM/DMARC?
Nein. ARC ergänzt SPF/DKIM/DMARC, indem es die von Relays beobachteten Ergebnisse erhält.

Wer kann ARC hinzufügen?
Jeder Transportvermittler (MTA, Gateway, E-Mail-Dienst), der die Nachricht handhabt.

Was bedeutet cv= genau?
Es ist die Aussage des Signierenden über den Zustand der von ihm gesehenen Kette: none (keine vorherige Kette), pass (konsistent und verifizierbar), fail (ungültige Kette). Der Empfänger führt trotzdem seine eigene Validierung durch.

Warum hat dieselbe Nachricht mehrere i=?
Jedes Relay erhöht i und fügt sein eigenes AAR/AMS/AS-Triplett hinzu.

Weiterführende Informationen

• IETF – RFC 8617: Authenticated Received Chain (ARC) : https://datatracker.ietf.org/doc/html/rfc8617
• RFC 8601 – Authentication-Results Header Field (Kontext für AAR): https://datatracker.ietf.org/doc/html/rfc8601

---

Spickzettel

• Zweck: SPF/DKIM/DMARC-Ergebnisse über Relays hinweg bewahren und versiegeln.
• 3 Header: ARC-Authentication-Results (Ergebnisse) + ARC-Message-Signature (Nachrichtensignatur) + ARC-Seal (Kettensiegel).
• Entscheidung beim Empfänger: gültige Signaturen + Reputation des Signierenden + interne DMARC-Regeln.