Wenn E-Mail-Weiterleitung SPF bricht (und was SRS repariert)

Von Thomas · virtueller CISO · 21. August 2026

In den DMARC-Berichten einer eigentlich sauber konfigurierten Domain sorgt eine Zeile früher oder später für Stirnrunzeln: eine völlig legitime Nachricht, versendet von einem bekannten Mitarbeiter — und trotzdem ein klarer SPF-Fehlschlag. Die Quell-IP gehört weder zum Mailserver der Organisation noch zu einem bekannten Versanddienstleister, sondern zu einer Universität, einem Shared-Hosting-Anbieter, einem Betreiber privater Postfächer. Die Erklärung passt in ein Wort: Weiterleitung. Irgendwo hat ein Empfänger eine Regel eingerichtet, die seine Post an ein anderes Postfach weiterreicht — und dieser eine zusätzliche Sprung genügt, um SPF scheitern zu lassen.

Das ist weder ein Konfigurationsfehler noch ein Angriff. Es ist eine strukturelle Grenze des Protokolls, bekannt seit seinem Entwurf: SPF validiert die IP-Adresse des letzten Servers, der die Nachricht übergibt, und eine Weiterleitung schiebt genau einen weiteren Server in den Pfad. Der Mechanismus SRS (Sender Rewriting Scheme) wurde erfunden, um den Schlag abzufedern — doch er repariert weniger, als oft angenommen wird.

Dieser Artikel zerlegt die Mechanik des Fehlschlags, erklärt, warum DKIM die Reise meist übersteht, und arbeitet heraus, was SRS tatsächlich behebt — und was unangetastet bleibt, allen voran das DMARC-Alignment. Am Ende steht eine sehr operative Frage: Welche Policy lässt sich veröffentlichen, wenn ein Teil des legitimen Verkehrs unvermeidlich über Weiterleitungen läuft?

Die Mechanik: ein Neuversand von der falschen IP

SPF (RFC 7208) beantwortet eine einfache Frage: Ist die IP-Adresse, die diese Nachricht übergibt, berechtigt, für die Envelope-Domain zu versenden? Der empfangende Server liest die Domain aus dem MAIL FROM — dem Return-Path —, fragt deren TXT-Eintrag ab und vergleicht die verbindende IP mit der veröffentlichten Liste. Beim Direktversand geht alles gut: Die Nachricht verlässt beispiel.de über einen Server oder eine E-Mail-Plattform, deren IP im SPF-Eintrag steht, und die Prüfung besteht.

Eine Weiterleitung verändert das Bild. Das Postfach, das weiterreicht — ein Alias, eine automatische Weiterleitungsregel —, nimmt die Nachricht zunächst an und versendet sie dann aus der eigenen Infrastruktur neu an das endgültige Ziel. Die naive Weiterleitung behält den ursprünglichen Envelope bei: Der Return-Path zeigt weiterhin schmidt@beispiel.de, doch die IP, die sich mit dem Zielserver verbindet, ist nun die des Weiterleiters. Diese IP steht selbstverständlich nicht im SPF von beispiel.de — und hat dort auch nichts verloren. Das mechanische Ergebnis: ein Fehlschlag, so sorgfältig der ursprüngliche Eintrag auch gepflegt sein mag.

Wie hart die Strafe ausfällt, bestimmt der Qualifikator am Ende des Eintrags: Ein -all setzt die Nachricht schon in der SPF-Phase einer Ablehnung aus, ein ~all erzeugt einen milderen Softfail — eine Nuance, die der Leitfaden zum all-Mechanismus von SPF auseinandernimmt. Aus DMARC-Sicht ist das Urteil in beiden Fällen dasselbe: Der Beitrag von SPF ist verloren.

Warum DKIM die Reise übersteht

DKIM (RFC 6376) schaut nicht auf die IP. Der Beweis reist in der Nachricht selbst: Ein DKIM-Signature-Header deckt kryptografisch einen Satz von Headern und den Nachrichtentext ab. Wie viele Server durchquert werden, ist gleichgültig — kommt die Nachricht unversehrt an, verifiziert sich die Signatur, DKIM besteht, und da die signierende Domain (d=beispiel.de) mit dem sichtbaren From übereinstimmt, ist DMARC zufrieden. Das ist der Konstruktionsunterschied in einem Satz: SPF authentifiziert einen Pfad, DKIM authentifiziert einen Inhalt.

Die Bedingung passt in ein Wort: unversehrt. Eine saubere Weiterleitung, die die Nachricht Byte für Byte weiterreicht, erhält die Signatur. Jeder Zwischenserver, der den Inhalt verändert, zerbricht sie: ein in den Text injizierter Banner „Nachricht geprüft", eine MIME-Neukodierung, eine präfixierte Betreffzeile, eine angehängte Fußzeile. Diskussionslisten, die Betreff-Etiketten und Fußzeilen gleich stapelweise hinzufügen, sind der pathologische Fall schlechthin — ein Minenfeld, dicht genug für eine eigene Untersuchung der Mailinglisten unter DMARC.

Die strategische Konsequenz wiegt schwer: Durch eine Weiterleitung hindurch ist DKIM die einzige Verteidigungslinie, die hält. Eine Domain, die sämtliche Flüsse mit DKIM signiert, übersteht die meisten Weiterleitungen unbeschadet; eine Domain, die allein auf SPF setzt, verliert alles, sobald ein Empfänger eine Weiterleitungsregel anlegt.

SRS: den Envelope umschreiben, um SPF zu retten

Die naive Weiterleitung schafft in Wirklichkeit zwei Probleme. Das erste ist der beschriebene SPF-Fehlschlag. Das zweite ist das Routing der Bounces: Wird die weitergeleitete Nachricht am Ende der Kette abgewiesen, läuft die Fehlermeldung zum ursprünglichen Return-Path zurück — zu einem Absender, der von der Weiterleitung nichts weiß und unverständliche Bounces erhält. SRS, in den frühen 2000er-Jahren als Antwort auf den SPF-Rollout formalisiert, löst beides mit einem Griff.

Das Prinzip: Beim Neuversand schreibt der Weiterleiter den Return-Path auf den eigenen Namen um und kapselt die ursprüngliche Adresse im lokalen Teil. Eine Nachricht von schmidt@beispiel.de, weitergeleitet über weiterleitung-beispiel.de, startet neu mit einem Envelope dieser Form:

MAIL FROM: SRS0=k3v7=T9=beispiel.de=schmidt@weiterleitung-beispiel.de

Doppelter Effekt. Erstens bewertet der Zielserver SPF nun gegen weiterleitung-beispiel.de, dessen Eintrag die IP des Weiterleiters sehr wohl autorisiert: Die Prüfung besteht. Zweitens kehrt ein etwaiger Bounce zum Weiterleiter zurück, der die Adresse entkapselt und die Meldung zum ursprünglichen Absender leitet. Die Implementierungen sind ausgereift — SRS-Module in den großen Mail-Suiten, dedizierte Daemons auf Postfix-Seite —, und die meisten seriösen Hoster schreiben die von ihnen betriebenen Weiterleitungen heute um.

Was SRS nicht repariert: das DMARC-Alignment

So viel zur Klempnerei. Bleibt die Identität — und hier kühlt die Begeisterung ab. DMARC verlangt mehr als ein bestandenes SPF: Es verlangt, dass die von SPF validierte Domain mit der Domain des sichtbaren From übereinstimmt, also mit der, die der Empfänger liest. Nach der SRS-Umschreibung gehört der Return-Path jedoch dem Weiterleiter (weiterleitung-beispiel.de), während das From weiterhin beispiel.de zeigt. Zwei organisatorisch fremde Domains: Das Alignment scheitert, im strikten wie im relaxed-Modus — und der DNS Tree Walk von DMARCbis, der die Organisationsdomain bestimmt, wird zwei einander fremde Zonen niemals zusammenführen.

Das Ergebnis ist ein Muster, das in den Berichten häufig genug auftaucht, um eine eigene Akte zu verdienen: SPF besteht, während DMARC scheitert. SPF steht auf Grün — für die Domain des Weiterleiters. DMARC dagegen beurteilt die Ursprungsdomain und hat für sein Urteil nur noch DKIM in der Hand.

Anders gesagt: SRS repariert die Zustellbarkeit des Weiterleiters und das Routing der Bounces; die Authentifizierung der Ursprungsdomain repariert es nicht. Nach einer SRS-Weiterleitung hängt das DMARC-Schicksal einer Nachricht zu 100 % am Überleben ihrer DKIM-Signatur. Selbst erfahrene Teams entdecken das spät: SRS ist für modernes Forwarding unverzichtbar — und für das DMARC-Alignment des Absenders vollkommen neutral.

Drei sehr konkrete Situationen

Der Universitäts-Alias. Universitäten vergeben lebenslange Adressen (vorname.name@alumni-beispiel.de), die nichts speichern: Alles wird an ein privates Postfach weitergeleitet, oft Gmail. Jede Nachricht an einen Ehemaligen durchquert also die Infrastruktur der Universität, bevor sie bei Google ankommt. In den Berichten der versendenden Domain zeichnet das charakteristische Zeilen: akademische IPs, ein scheiterndes SPF (oder ein via SRS auf einer Drittdomain bestehendes), und ein DKIM, das den Tag rettet, wann immer die Signatur unversehrt ankam.

Das weitergeleitete Kontaktpostfach. Ein kleines Unternehmen leitet kontakt@beispiel.de an das private Gmail-Konto der Geschäftsführung weiter. Hier spielt die Domain die Rolle des Weiterleiters: Neu versendet werden die Nachrichten der Kunden, und deren Authentifizierung verschlechtert sich. Ohne SRS sieht Gmail Post Dritter von einer IP eintreffen, die deren SPF nie autorisiert hat — mit dem Spam-Ordner als wahrscheinlichem Preis, bezahlt von der Post der Kunden, nicht von der eigenen. Wer eine Weiterleitung betreibt, übernimmt Pflichten gegenüber den Domains der anderen.

Die interne Umverteilung. Eine Funktionsadresse (bestellungen@beispiel.de), die an drei Mitarbeitende weiterversendet, oder eine alte Domain, die nach einer Fusion auf die neue umgeleitet wird: dieselbe Mechanik, nur ist der Verkehr vorhersehbar und die Infrastruktur unter Kontrolle. Es ist der am einfachsten zu bereinigende Fall — und oft der erste, der in den Berichten sichtbar wird.

ARC, das ergänzende Netz

Für Weiterleitungsketten, die weder SRS noch DKIM zu retten vermögen, tritt ein dritter Standard auf: ARC (Authenticated Received Chain, RFC 8617). Die Idee: Jeder Zwischenserver versiegelt in dedizierten Headern das Ergebnis der Prüfungen, die er selbst beim Empfang durchgeführt hat. Der endgültige Empfänger kann so feststellen, dass die Nachricht SPF und DKIM vor der Weiterleitung bestand, und sich entscheiden, einen bei Ankunft festgestellten DMARC-Fehlschlag zu übergehen.

Das entscheidende Wort ist „entscheiden": ARC erzwingt nichts, es dokumentiert. Der Empfänger berücksichtigt die Kette nur, wenn er den Zwischenstationen vertraut, die sie signiert haben — Gmail und Microsoft 365 werten sie aus, jeder nach eigenen Kriterien. Die Funktionsweise im Detail, Siegel für Siegel, steht in dem Leitfaden zur Vertrauenskette. Ein wertvolles Netz also, aber eben nur ein Netz: Nichts ersetzt eine DKIM-Signatur, die die Reise übersteht.

Was die RUA-Berichte zeigen

Die gute Nachricht: Weiterleitungen hinterlassen in den aggregierten Berichten einen gut wiedererkennbaren Fingerabdruck. Die betroffenen Zeilen kombinieren bescheidene Volumina, verstreute und wechselnde IPs — Universitäten, Hoster, Betreiber privater Postfächer —, ein gegen die Ursprungsdomain scheiterndes SPF (oder ein nicht ausgerichtetes Bestehen auf einer Relais-Domain, das Erkennungszeichen von SRS) und ein ausgerichtetes DKIM, das allein das DMARC-Urteil auf Grün hält.

Genau zu beobachten sind die anderen Zeilen: die, in denen auch DKIM scheitert. Ein Zwischenserver, der Inhalte verändert — Banner, Neukodierung —, produziert legitime Post, die auf ganzer Linie durchfällt: genau die Post, die verloren geht, sobald die Policy verschärft wird. Diesen Restanteil zu schätzen, Relais für Relais, ist exakt die Vorarbeit eines Wechsels zur Durchsetzung — und eine Analyseplattform, die die IPs benennt (dieser Postfachanbieter, jene akademische Infrastruktur), verwandelt anonyme Zeilen in eine handlungsfähige Diagnose.

Welche Policy, wenn Weiterleitung zum Alltag gehört

Schließt empfängerseitige Weiterleitung p=reject aus? Nein — aber der Schritt verdient offene Augen. Drei Prinzipien gelten. Erstens: ausnahmslos jeden Fluss mit DKIM signieren, Transaktions- und Anwendungspost eingeschlossen — es ist die einzige Authentifizierung, die Weiterleitungen übersteht, und jeder unsignierte Fluss ist beim ersten Transfer verloren. Zweitens: quantifizieren, bevor verschärft wird — die Berichte sagen präzise, welcher Anteil des legitimen Verkehrs über signaturzerstörende Relais läuft; oft eine Randgröße, manchmal ein erheblicher blinder Fleck. Drittens: einen Rest akzeptieren — eine Domain auf p=reject verliert die seltenen weitergeleiteten Nachrichten, deren Signatur unterwegs zerbrach. Das sind reale, meist winzige Kosten, abzuwägen gegen alles, was die Durchsetzung den Fälschern verschließt.

DMARCbis hat an dieser Abwägung nichts geändert — die Weiterleitung bleibt die eingestandene Grenze des Modells —, doch sein Testmodus (t=y), der das alte pct-Tag ersetzt, bietet eine saubere Zwischenstufe, um die Wirkung einer Policy zu beobachten, bevor sie voll bindend wird.

Fazit

Eine Weiterleitung versendet die Nachricht neu von der IP des Relais, die im SPF des ursprünglichen Absenders fehlt — und dort zu Recht fehlt: Der SPF-Fehlschlag ist strukturell, nicht zufällig. DKIM überlebt, solange der Inhalt unangetastet bleibt, und ist damit die einzige verlässliche Authentifizierung über einen Transfer hinweg. SRS schreibt den Return-Path auf den Namen des Weiterleiters um: Das rettet die Zustellbarkeit des Forwardings und das Routing der Bounces, stellt aber nichts vom DMARC-Alignment der Ursprungsdomain wieder her — nach SRS hängt alles an DKIM, mit ARC als dokumentierendem Netz, das die großen Empfänger honorieren können, aber nicht müssen. In den Berichten liest sich das Muster klar, und es lässt sich managen: flächendeckende DKIM-Signatur, Quantifizierung des Rests, dann Verschärfung.

Der Ausgangspunkt liegt in Reichweite: Ein Durchlauf der Domain durch die kostenlose DMARC-Analyse zeigt den Zustand von SPF, DKIM und der veröffentlichten Policy, Weiterleitungen inbegriffen. Um diese weitergeleiteten Flüsse anschließend Woche für Woche zu verfolgen und die Domain ohne Verlust legitimer Post Richtung p=reject zu führen, öffnet ein neues Konto den Zugang zu den dekodierten Berichten, mit identifizierten Quellen — auch jenen, die nur weiterreichen.