Wozu ARC?
Sobald eine E-Mail weitergeleitet wird — über eine Mailingliste, eine Weiterleitungsregel oder ein Gateway — ändert sich die sendende IP. SPF prüft aber genau diese IP und schlägt daher zwangsläufig fehl. Hängt der Weiterleiter zusätzlich einen Footer an, bricht auch die DKIM-Body-Signatur. Das Ergebnis: eine völlig legitime Nachricht scheitert an DMARC.
Die Authenticated Received Chain (ARC, RFC 8617) löst das. Jede Station, die eine Nachricht weiterreicht, versiegelt das Authentifizierungsergebnis, das sie selbst gesehen hat. Der finale Empfänger kann so nachvollziehen, dass die Mail beim ersten Empfang sauber authentifiziert war, auch wenn sie es jetzt nicht mehr ist.
Was AnalyzeMy.Email prüft
- Pro Hop: die signierende Domain, das Chain-Validation-Ergebnis (
cv=none,cv=pass,cv=fail) sowie die dort festgestellten SPF-, DKIM- und DMARC-Ergebnisse - Vollständigkeit: Jede ARC-Instanz braucht alle drei Header —
ARC-Authentication-Results,ARC-Message-SignatureundARC-Seal. Fehlt einer, ist die Instanz unbrauchbar - Reihenfolge der Instanzen über die
i=-Nummerierung
Die Ergebnisse lesen
- cv=none — Diese Station ist die erste in der Kette. Korrekt für den ersten Weiterleiter.
- cv=pass — Die vorhergehende Kette wurde geprüft und ist intakt.
- cv=fail — Die Kette ist gebrochen. Ab hier sind die Angaben nicht mehr vertrauenswürdig.
- Keine ARC-Header — Bei direkt zugestellten Mails völlig normal und kein Fehler.
Einordnung
ARC richtest du nicht auf deiner Absenderdomain ein — es ist eine Funktion von weiterleitenden Systemen. Relevant wird der Check, wenn du eine weitergeleitete Mail analysierst und verstehen willst, warum SPF fehlschlägt, obwohl deine Konfiguration korrekt ist. Ein fail bei SPF mit intakter ARC-Kette ist kein Konfigurationsproblem deiner Domain.
Betreibst du selbst eine Mailingliste oder ein Gateway, solltest du ARC-Signierung aktivieren. Google und Microsoft werten ARC-Ketten aus und stellen weitergeleitete Nachrichten damit deutlich zuverlässiger zu.