Warum E-Mail-Weiterleitung SPF bricht (und was SRS und ARC tun)

E-Mail-Weiterleitung bricht SPF, weil SPF die verbindende IP-Adresse mit dem Record der Domain des Envelope-Absenders vergleicht, und eine einfache Weiterleitung ändert das Erste, ohne das Zweite zu ändern. Der endgültige Empfänger sieht den Server des Weiterleiters, der E-Mails „von“ example.com zustellt, findet diesen Server nirgends im SPF-Record von example.com und liefert fail. Auf keiner der beiden Seiten ist etwas falsch konfiguriert: So ist SPF entworfen. Ob die Nachricht trotzdem DMARC besteht, hängt fast ausschließlich von DKIM ab.

Dieser Leitfaden folgt einer Nachricht durch eine Weiterleitung und zeigt, was SRS, DKIM und ARC jeweils ändern.

Was SPF tatsächlich prüft

Eine SMTP-Zustellung hat zwei Absenderidentitäten:

• den Envelope-Absender, der im Befehl MAIL FROM übergeben und später als Return-Path festgehalten wird. Dorthin gehen Bounces.
• den From-Header, den das E-Mail-Programm des Empfängers anzeigt.

SPF (RFC 7208) kennt nur den ersten. Der Empfänger nimmt die Domain des Envelope-Absenders (oder ersatzweise den HELO-Namen, etwa wenn der Envelope-Absender leer ist, wie bei Bounces), holt deren SPF-Record und fragt: Ist die IP-Adresse, die sich gerade mit mir verbindet, dort aufgeführt?

Direkte Zustellung:

alice@example.com  ->  mail server of example.com (192.0.2.10)  ->  receiver
MAIL FROM:<alice@example.com>      connecting IP 192.0.2.10      spf=pass

Was eine einfache Weiterleitung tut

Eine einfache Weiterleitung ist ein Alias, eine .forward-Datei, eine Regel „alle E-Mails weiterleiten an“ oder die E-Mail-Weiterleitung, die bei vielen Registraren zur Domain gehört. Sie nimmt die Nachricht an und sendet sie an eine andere Adresse weiter, wobei der ursprüngliche Envelope-Absender erhalten bleibt, damit Bounces zum Verfasser zurückgehen.

alice@example.com  ->  forwarder (203.0.113.7)  ->  bob's real mailbox
MAIL FROM:<alice@example.com>      connecting IP 203.0.113.7     spf=fail

203.0.113.7 gehört dem Weiterleiter. example.com hat davon nie gehört und sollte die Adresse auch nicht eintragen: Ein Absender kann nicht jede Adresse kennen, an die seine Empfänger weiterleiten.

SRS: SPF für den Weiterleiter reparieren

Das Sender Rewriting Scheme ändert den Envelope-Absender vor dem erneuten Versand in eine Adresse in der eigenen Domain des Weiterleiters:

MAIL FROM:<SRS0=HHH=TT=example.com=alice@forwarder.example>

HHH ist ein kurzer Hash, TT ein Zeitstempel, und die ursprüngliche Domain und der lokale Teil bleiben erhalten, damit ein Bounce an diese Adresse wieder ausgepackt und an alice@example.com weitergegeben werden kann. Der Hash verhindert, dass Dritte den Weiterleiter als Bounce-Relay missbrauchen.

Jetzt prüft der Empfänger den SPF-Record von forwarder.example, und der führt 203.0.113.7 auf. SPF besteht.

Zwei Dinge sollten Sie über SRS wissen:

• Es ist kein IETF-Standard. Es ist eine Spezifikation aus der Community, die aus dem SPF-Projekt hervorgegangen ist, und die Implementierungen unterscheiden sich im Detail.
• Es repariert SPF, nicht DMARC. Nach dem Umschreiben ist die per SPF authentifizierte Domain forwarder.example, während im From-Header weiterhin example.com steht. DMARC verlangt, dass die authentifizierte Domain zur From-Domain passt (Alignment), also scheitert der SPF-Zweig von DMARC nach wie vor. Er scheitert nur leise statt laut.

DKIM: der Teil, der überlebt

Eine DKIM-Signatur ist Teil der Nachricht, nicht der Verbindung. Sie deckt den Textkörper und eine gewählte Menge von Headern ab und wird mit einem öffentlichen Schlüssel im DNS des Signierers geprüft. Ein Weiterleiter, der die Nachricht unverändert weitergibt, lässt die Signatur gültig, egal von welcher IP er sich verbindet. Passt die signierende Domain (d=) zur From-Domain, besteht DMARC allein über den DKIM-Zweig.

DKIM bricht, wenn sich ein signierter Teil ändert:

• eine Mailingliste stellt [Listenname] in den Betreff oder hängt eine Fußzeile an den Text an
• ein Gateway schreibt den Text um, etwa durch einen Disclaimer oder umgeschriebene Links
• ein System kodiert die Nachricht auf eine Weise neu, die die Kanonisierung der Signatur nicht verträgt

Eine einfache Weiterleitung tut nichts davon. Mailinglisten tun das Erste ständig.

Szenarien im Überblick

Angenommen, example.com veröffentlicht SPF, signiert mit d=example.com und hat p=reject.

Szenario	SPF-Ergebnis	DKIM-Ergebnis	DMARC-Ergebnis
Direkte Zustellung	pass, Alignment	pass, Alignment	pass
Einfache Weiterleitung, Nachricht unverändert	fail	pass, Alignment	pass (über DKIM)
Einfache Weiterleitung, Absender ohne DKIM	fail	none	fail
Weiterleitung mit SRS, Nachricht unverändert	pass für den Weiterleiter, kein Alignment	pass, Alignment	pass (über DKIM)
Weiterleitung mit SRS, Absender ohne DKIM	pass für den Weiterleiter, kein Alignment	none	fail
Mailingliste, die Betreff oder Text ändert	pass für die Liste, kein Alignment	fail (gebrochen)	fail, es sei denn, die Liste schreibt From um
Dasselbe, mit einer ARC-Kette, der der Empfänger vertraut	wie oben	wie oben	fail, aber der Empfänger kann lokal übersteuern

Die zweite und die fünfte Zeile sind die, auf die es in der Praxis ankommt: SRS kann einen Absender ohne DKIM mit Alignment nicht retten, und ein Absender mit DKIM im Alignment braucht kein SRS, damit DMARC besteht.

ARC: weitergeben, was der Zwischenschritt gesehen hat

Authenticated Received Chain (RFC 8617, Status Experimental) zielt auf die Mailinglisten-Zeilen. Ein Zwischenschritt, der die Nachricht verarbeitet, hält die Authentifizierungsergebnisse fest, die er beim Eingang beobachtet hat, und signiert diese Aufzeichnung. Jede Station fügt einen Satz aus drei Headern mit einer Instanznummer hinzu:

ARC-Authentication-Results: i=1; lists.example.org;
   spf=pass smtp.mailfrom=example.com; dkim=pass header.d=example.com;
   dmarc=pass header.from=example.com
ARC-Message-Signature: i=1; a=rsa-sha256; d=lists.example.org; s=arc1; …
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=lists.example.org; s=arc1; …

Ein zweiter Zwischenschritt fügt i=2 hinzu, und so weiter. Der endgültige Empfänger kann die Kette prüfen und sehen, dass die Nachricht DMARC bestanden hat, als sie lists.example.org erreichte, bevor die Liste sie veränderte.

Das entscheidende Wort ist kann. ARC sagt dem Empfänger, was ein Versiegler gesehen zu haben behauptet. Ob er diesem Versiegler glaubt, ist seine eigene Richtlinie: Empfänger KÖNNEN eine Kette eines Zwischenschritts anerkennen, dem sie vertrauen, und es steht ihnen frei, sie zu ignorieren. ARC ist keine Zustellgarantie.

Wegen dieser Unsicherheit greifen Mailinglisten bei Absendern, deren Domains DMARC durchsetzen, meist zu einem gröberen Mittel: Sie schreiben den From-Header auf eine Adresse in der eigenen Domain der Liste um, damit die Nachricht zum eigenen SPF und DKIM der Liste passt.

Den Header Authentication-Results lesen

Schicken Sie eine Nachricht über die Weiterleitung an ein Postfach, das Sie kontrollieren, öffnen Sie das Original und suchen Sie den Header Authentication-Results, den der endgültige Empfänger hinzugefügt hat (der oberste):

Authentication-Results: mx.receiver.example;
   spf=pass smtp.mailfrom=forwarder.example;
   dkim=pass header.d=example.com header.s=s2026;
   dmarc=pass header.from=example.com;
   arc=pass
Return-Path: <SRS0=a1b2=XY=example.com=alice@forwarder.example>

Feld	Was es Ihnen sagt
smtp.mailfrom=	Die Domain, gegen die SPF geprüft wurde. Ist es die des Weiterleiters, ist SRS im Einsatz.
spf=	Ergebnis für diese Domain und die verbindende IP. fail mit der ursprünglichen Domain bedeutet eine einfache Weiterleitung.
header.d=	Die Domain, deren DKIM-Signatur gültig war. Vergleichen Sie sie mit header.from.
dmarc=	Das Urteil nach dem Alignment. Das ist das Ergebnis, das entscheidet.
arc=	Ob eine ARC-Kette vorhanden war und geprüft werden konnte.

Wer die Header lieber einfügt als liest, kann sie mit dem E-Mail-Header-Analyzer aufschlüsseln lassen.

Empfehlungen für Absender

1. Signieren Sie alles mit DKIM, im Alignment mit Ihrer From-Domain. Jeder Dienst, der in Ihrem Namen versendet: Postfachanbieter, Newsletter-Tool, Rechnungssystem, Helpdesk. Das lässt Ihre E-Mails eine Weiterleitung überstehen. SPF allein wird das nie tun.
2. Tragen Sie keine IP-Adressen von Weiterleitern in Ihren SPF-Record ein. Sie können sie nicht alle kennen, sie ändern sich, und jedes Include, das Sie ergänzen, zählt gegen das Limit von 10 Abfragen.
3. Wechseln Sie erst zu p=reject, wenn die DMARC-Berichte DKIM-Alignment für alle Ihre legitimen Quellen zeigen. Einer Domain mit p=reject, die sich allein auf SPF verlässt, werden weitergeleitete E-Mails abgewiesen.
4. Rechnen Sie mit einem kleinen Rest an Fehlern durch Mailinglisten. Die Reihenfolge der Einführung in MX, SPF, DKIM und DMARC erklärt berücksichtigt das.

Empfehlungen, wenn Sie E-Mails weiterleiten

• Verwenden Sie einen Weiterleiter, der SRS umsetzt, und idealerweise ARC-Versiegelung. Ohne SRS kommt jede Nachricht von einer Domain mit -all mit spf=fail an.
• Erwägen Sie Abholen statt Weiterleiten. Kann das Zielpostfach die E-Mails des alten Kontos per POP oder IMAP abholen, findet kein erneuter Versand statt, und keine Authentifizierung wird gestört.
• Leiten Sie keinen Spam weiter. Der endgültige Empfänger sieht, dass die IP Ihres Weiterleiters ihn zustellt, und rechnet das dem Weiterleiter an. Filtern Sie vor dem Weiterleiten.
• Erwägen Sie, das Postfach zu hosten, statt es weiterzuleiten. Eine Domain, die nur an ein kostenloses Postfach weiterleitet, ist die fragile Konstellation in den meisten Meldungen der Art „meine E-Mails kommen nicht an“: siehe die DNS-Checkliste für E-Mails im Spam.

Häufige Fehler

• spf=fail bei einer weitergeleiteten Nachricht als Beweis für Spoofing werten. Sehen Sie sich dkim= und dmarc= an, bevor Sie entscheiden.
• Glauben, SRS repariere DMARC. Es repariert SPF für die Domain des Weiterleiters; das Alignment fehlt weiterhin.
• include:-Einträge für die Weiterleiter Ihrer Empfänger in den eigenen SPF-Record aufnehmen.
• Mit reiner SPF-Authentifizierung zu p=reject gehen, weil „SPF in allen unseren Tests besteht“. Tests enthalten selten eine Weiterleitung.
• Annehmen, ARC zwinge den Empfänger zur Annahme. Es ist ein Beleg, der einem Empfänger angeboten wird, der dem Versiegler vertrauen kann oder auch nicht.
• Auf einem ausgehenden Gateway einen Disclaimer nach der DKIM-Signierung anhängen. Das bricht Ihre eigene Signatur, bevor die Nachricht das Haus verlassen hat.

Mit OrbitProbe prüfen

Der SPF-Check von OrbitProbe zeigt den SPF-Record, den eine Domain veröffentlicht, und weist auf die üblichen strukturellen Probleme hin: mehrere Records, +all, ein fehlender all-Mechanismus, zu viele DNS-Abfragen. Bei einem Weiterleitungsproblem prüfen Sie zwei Namen: die Domain des ursprünglichen Absenders (endet sie auf -all, was einfache Weiterleitungen hart scheitern lässt?) und die Domain des Weiterleiters (hat sie überhaupt einen gültigen Record, damit per SRS umgeschriebene E-Mails bestehen können?). Eine DNS-Prüfung liest die veröffentlichte Richtlinie. Was mit einer bestimmten Nachricht geschehen ist, steht nur im Header Authentication-Results dieser Nachricht, also lesen Sie beides.