Eingaben
Beispiel
Füge Header ein, um strukturelle Vollständigkeit und aufgezeichnetes cv=pass/cv=fail von der nicht durchgeführten kryptografischen Validierung zu trennen.
ARC-Chain-Validator
Prüft ARC-Instanzstruktur, Kontinuität und aufgezeichneten cv-Status ohne Kryptografie- oder Sealer-Vertrauensbehauptung.
Nutze es, wenn weitergeleitete Mail einen strukturellen ARC-Check vor kryptografischer Validierung und Sealer-Vertrauensbewertung braucht.
Warum weitergeleitete Mail an der Authentifizierung scheitert
Mail-Weiterleitung bricht die beiden Säulen der Absender-Authentifizierung auf unterschiedliche Weise. SPF scheitert, weil der Forwarder von seinen eigenen Servern sendet, die die Ursprungsdomain nie autorisiert hat. DKIM überlebt oft — bis eine Mailingliste einen Betreff-Tag oder einen Footer anfügt, dann stirbt auch die Signatur. Das empfangende System sieht am Ende einen DMARC-Fehlschlag bei einer Nachricht, die an ihrem Ursprung vollkommen authentisch war.
ARC existiert, um die Beweise über diese Zwischenstationen zu tragen. Jeder Vermittler fügt einen nummerierten Satz aus drei Headern hinzu: ARC-Authentication-Results hält fest, was diese Station beobachtet hat, ARC-Message-Signature signiert die Nachricht in ihrem dortigen Zustand, und ARC-Seal versiegelt die Kette, damit spätere Stationen erkennen, ob sie ehrlich verlängert wurde. Dieser Validator zerlegt eingefügte Header in diese Sätze und prüft, was sich strukturell prüfen lässt: Instanznummerierung, Pflicht-Tags, Chain-Validation-Werte und die Kontinuität von Station zu Station.
Eine eingefügte ARC-Kette durcharbeiten
Füge den vollständigen Header-Block der zugestellten Nachricht ein, kein Fragment. Lies zuerst die Instanzfolge: Die Sätze müssen lückenlos 1, 2, 3 zählen, jede Instanz braucht alle drei Mitglieder und das erste Seal muss cv=none tragen. Jedes spätere Seal zeichnet cv=pass oder cv=fail auf. Ein aufgezeichnetes cv=fail ist gültige Syntax und berichtet, dass der Sealer die vorherige Kette als fehlgeschlagen bewertet hat; dadurch wird die ARC-Tag-Liste nicht automatisch fehlerhaft.
Sieh dir dann an, wer signiert hat. Die d=-Domains der Kette verraten, welche Infrastruktur die Nachricht tatsächlich angefasst hat — oft die interessantere Information als der Validierungsstatus selbst. Eine Kette ist nur so viel wert wie das Vertrauen in ihre Siegler: cv=pass von einer Domain, von der du nie gehört hast, ist eine Behauptung, kein Ausweis. Der Quervergleich mit der Received-Kette im E-Mail-Header-Analyzer zeigt, ob ARC-Geschichte und Transportgeschichte zusammenpassen.
Strukturprüfung versus kryptografischer Beweis
Header bleiben im Browser; nichts wird hochgeladen. Der Validator prüft Struktur, Pflicht-Tags, Reihenfolge und Kontinuität — die Fehlerbilder, die den Großteil realer ARC-Brüche ausmachen. DNS-Schlüssel holt er nicht, und Signaturen verifiziert er nicht kryptografisch: Ehrliche Verifikation braucht Resolver-Zugriff und die exakte Kanonisierung des Nachrichtenkörpers, die ein eingefügter Header-Block nicht liefern kann. Das endgültige Urteil steht in den Authentication-Results deines empfangenden MTA.
Häufige Fragen
Heißt eine strukturell gültige Kette, dass die Mail vertrauenswürdig ist?
Nein. Sie heißt nur, dass die geparsten Felder die Strukturregeln erfüllen. Das Tool prüft weder Signaturen noch Sealer-Identität, und eine strukturell gültige Kette darf cv=fail aufzeichnen. Vertrauen erfordert separate kryptografische Validierung und Empfänger-Policy.
Kann ARC eine an DMARC scheiternde Nachricht zustellbar machen?
Manchmal. Große Empfänger können einen DMARC-Fehlschlag übersteuern, wenn ein Siegler, dem sie vertrauen, bestätigt, dass die Authentifizierung stromaufwärts bestanden war. Das ist eine Policy-Entscheidung des jeweiligen Empfängers, keine Protokollgarantie — kleine Empfänger ignorieren ARC oft komplett.
Was sagt mir cv=fail mitten in der Kette?
Dass das Seal dieser Instanz die Kette davor nicht validieren konnte. Alles danach erbt den Fehlschlag; einen Reparaturmechanismus kennt ARC nicht. Untersuchen solltest du die Station unmittelbar vor dem ersten fail.
Warum tauchen Mailinglisten so oft in ARC-Ketten auf?
Weil sie der Klassiker sind, der SPF und DKIM gleichzeitig bricht: Sie versenden von eigener Infrastruktur und verändern die Nachricht. Listen waren eine Hauptmotivation für ARC — Ketten mit Listen-Sieglern sind entsprechend alltäglich.
Die Instanznummern springen von 1 auf 3 — was ist passiert?
Ein Vermittler hat einen Satz entfernt oder seinen eigenen falsch nummeriert. Beides entwertet die Kette als Beweismittel, denn Kontinuität ist genau das, was die Nummerierung garantieren soll.
Muss ich DNS-Records veröffentlichen, um ARC-Mail zu empfangen?
Nein. Gesiegelt wird von den Vermittlern mit deren eigenen Schlüsseln. DNS-Einträge brauchst du nur, wenn deine Infrastruktur selbst Nachrichten siegelt — Empfangen und Auswerten kostet nichts.