Sender Rewriting Scheme SRS: SPF und Weiterleitung

Sie richten eine Weiterleitung ein: contact@your-agency.com → you@gmail.com. Der Test funktioniert. Zwei Wochen später fehlt die Vertragsmail eines Firmenkunden, auch im Spamordner. In den Logs steht: 550 5.7.1 Unauthenticated email. Oder Sie finden 550 5.7.520 Access denied, das bei Microsoft 365 eine Sperre für ausgehende externe Weiterleitung anzeigen kann. Beide Fehler brauchen eine eigene Diagnose. Dass Sie keine Nachricht sehen, bedeutet nicht, dass es keine SMTP-Ablehnung oder Unzustellbarkeitsmeldung gab.

Eine mögliche Maßnahme gegen weiterleitungsbedingte SPF-Probleme ist Sender Rewriting Scheme, SRS. Ohne Umschreibung kann SPF scheitern, wenn der ursprüngliche Envelope-Absender den Weiterleiter nicht autorisiert. Auch 2026 sind die Anforderungen von Google und Yahoo nicht mit einer allgemeinen Pflicht zu DMARC p=reject für alle Absender gleichzusetzen (Googles Anforderungen an E-Mail-Absender). Bei fehlender ausgerichteter Authentifizierung können strenge Regeln zur Ablehnung beitragen. Dieser Leitfaden erklärt die Funktion von SRS auf Protokollebene, seine Grenzen und ergänzende Maßnahmen.

Für einen Überblick beginnen Sie mit unserem Leitfaden zur Einrichtung von E-Mail-Weiterleitungen und Behebung häufiger Fehler.

Was ist Sender Rewriting Scheme (SRS)?

Sender Rewriting Scheme, SRS, schreibt den Envelope-Absender um und kann dadurch SPF-Fehler bei E-Mail-Weiterleitungen vermeiden. Bevor Ihr Server eine Nachricht weiterleitet, ersetzt er die SMTP-Envelope-Adresse (MAIL FROM) durch eine Adresse auf Ihrer Weiterleitungsdomain. Diese Adresse erscheint normalerweise nicht in der Absenderanzeige, ist aber in Rohheadern prüfbar. Der Empfänger prüft SPF nun für Ihre Domain. Die Prüfung kann bestehen, wenn deren DNS-Eintrag den tatsächlichen Versandweg autorisiert und sonst korrekt ist. Ohne Umschreibung muss die ursprüngliche Domain Ihren Server autorisieren, was häufig nicht der Fall ist. Ein SPF-Fehler allein beweist jedoch keine Fälschung und bedeutet nicht automatisch ein DMARC-Scheitern.

Zwei Ebenen der E-Mail-Identität

Die Fehlersuche bei SRS wird leichter, wenn Sie zwei unterschiedliche Absenderidentitäten auseinanderhalten. SPF prüft die Envelope-Ebene. DMARC prüft, ob mindestens eine gültige SPF- oder DKIM-Authentifizierung auf die sichtbare From-Domain ausgerichtet ist. Eine Weiterleitung kann diese Beziehungen verändern.

Der Envelope dient der SMTP-Übertragung und dem Rückweg für Unzustellbarkeitsmeldungen; SPF prüft seine Absenderdomain. Der From-Header erscheint im E-Mail-Client und liefert die Vergleichsdomain für DMARC. Beginnt die Weiterleitung eine neue SMTP-Verbindung, kann die ursprüngliche SPF-Autorisierung nicht mehr passen. SRS kann diese Prüfung unterstützen, ohne sämtliche Authentifizierungsprobleme zu lösen.

Eine neue Station: warum SPF bei der Weiterleitung scheitern kann

Bei einer Weiterleitung öffnet Ihr Server eine neue SMTP-Verbindung zum Ziel, also eine neue Station im Versandweg. Der Envelope-Absender lautet weiterhin alice@bank.com, aber die verbindende IP gehört jetzt Ihnen. SPF prüft Ihre IP anhand des Eintrags von bank.com. Ist sie dort nicht autorisiert, scheitert SPF. Veröffentlicht bank.com DMARC p=reject, kann der Empfänger ablehnen, sofern auch keine gültige, ausgerichtete DKIM-Signatur vorliegt. Eine SMTP-Fehlermeldung oder eine Unzustellbarkeitsmeldung ist möglich; die Ablehnung erfolgt nicht immer unbemerkt.

Das muss kein Einrichtungsfehler sein: Die neue Verbindung gehört zur Funktionsweise einer Weiterleitung. Das Problem entsteht, wenn die ursprüngliche Domain den Weiterleiter nicht autorisiert. SRS ist eine Möglichkeit, damit umzugehen, aber nicht jeder Versandweg verhält sich gleich.

Wie Sender Rewriting Scheme (SRS) den Envelope umschreibt

SRS ersetzt die Envelope-Adresse MAIL FROM vor dem Aufbau der neuen SMTP-Verbindung durch eine Adresse auf Ihrer Weiterleitungsdomain. Dadurch kann SPF für diese Domain bestehen. Der für den Empfänger sichtbare Header From: bleibt so, wie ihn der ursprüngliche Absender gesetzt hat.

# WITHOUT SRS - SPF fails downstream
Return-Path: <alice@bank.com>
Received-SPF: fail (IP not authorized for bank.com)

# WITH SRS - SPF passes on your domain
Return-Path: <SRS0=4fac=PM=bank.com=alice@your-domain.com>
Received-SPF: pass (IP authorized for your-domain.com)

Im Beispiel prüft der Zielserver SPF für your-domain.com, das Ihren Server autorisiert. SPF besteht unter dieser Voraussetzung. Der Empfänger sieht weiterhin From: alice@bank.com. SRS hat die unmittelbare SPF-Prüfung ermöglicht, aber die Ausrichtung auf die ursprüngliche From-Domain muss separat betrachtet werden.

Das Format einer SRS-Adresse verstehen

Die SRS-Adresse im Return-Path wirkt zunächst unübersichtlich, doch jeder Abschnitt hat eine Aufgabe. Wenn Sie ihre Struktur kennen, können Sie die sichtbare Umschreibung prüfen und mögliche Fehler gezielter untersuchen.

Beispiel: SRS0=4fac=PM=bank.com=alice@your-domain.com

Die zweite Hürde: SRS stellt keine SPF-Ausrichtung her

Ein wichtiger Unterschied: SRS kann die SPF-Prüfung ermöglichen, stellt aber nicht automatisch die SPF-Ausrichtung auf die sichtbare From-Domain her. Für DMARC muss entweder SPF oder DKIM gültig und ausgerichtet sein. Deshalb kann weitergeleitete Post auch bei korrekt eingerichtetem SRS noch scheitern.

DMARC verlangt die Ausrichtung einer erfolgreich authentifizierten Domain auf die Domain im sichtbaren Header From:. Im Beispiel mit aktivem SRS:

• SPF-Prüfung: PASS - Ihre IP ist für die Envelope-Domain your-domain.com autorisiert
• SPF-Ausrichtung: FAIL - Envelope your-domain.com ≠ Header bank.com

Fehlt die SPF-Ausrichtung, hängt das Bestehen von DMARC von einer gültigen, ausgerichteten DKIM-Signatur ab. Hat der ursprüngliche Absender entsprechend signiert und bleiben die signierten Teile unter der verwendeten Kanonisierung unverändert, kann DMARC über DKIM bestehen. Warnhinweise wie „External Email“, angehängte Antivirus-Fußzeilen oder MIME-Umwandlungen von 8-Bit- in 7-Bit-Codierung können DKIM beschädigen, wenn sie signierte Inhalte verändern.

Im Fehlerfall fehlt die SPF-Ausrichtung, und Änderungen machen DKIM ungültig. DMARC scheitert, und der Empfänger kann die Nachricht ablehnen, obwohl SRS seine Aufgabe für die Envelope-Domain korrekt erfüllt hat. Ob und wie eine Fehlermeldung entsteht, hängt vom Versandweg ab.

ARC als Ergänzung zu Sender Rewriting Scheme SRS

ARC (Authenticated Received Chain, RFC 8617) ergänzt SRS. Während SRS den Envelope für die SPF-Prüfung umschreibt, kann Ihr Weiterleiter mit ARC die tatsächlich beobachteten Authentifizierungsergebnisse signiert dokumentieren. Damit erhält der nächste Empfänger Informationen über frühere Prüfungen. Das bedeutet weder, dass alle Prüfungen bestanden wurden, noch dass die Nachricht frei von Spam ist.

ARC ergänzt drei Header: ARC-Authentication-Results, ARC-Message-Signature und ARC-Seal. Die Ergebnisse können frühere Authentifizierung nachvollziehbar machen. Die Nachrichtensignatur ist jedoch empfindlich gegenüber Änderungen an signierten Inhalten; nicht jede Änderung des Nachrichteninhalts wird überstanden. ARC repariert weder eine ungültige DKIM-Signatur noch die DMARC-Ausrichtung.

Die Einschränkung: Der Empfänger entscheidet, ob er dem ARC-Signierer und der Kette vertraut. In Microsoft 365 kann eine autorisierte Verwaltung vertrauenswürdige ARC-Signierer über PowerShell mit Set-ArcConfig konfigurieren, sofern die aktuelle Mandantenkonfiguration dies unterstützt und erfordert. Das ist kein pauschal notwendiger manueller Schritt für jede Umgebung. Auch das Vertrauen von Gmail lässt sich nicht manuell erzwingen.

In produktiven Umgebungen können SRS und ARC einander ergänzen: SRS unterstützt SPF für den neuen Envelope, ARC liefert Kontext für die Entscheidung des Empfängers. Beide sind weder in jeder Umgebung zwingend nötig noch zusammen eine Garantie für zuverlässige Zustellung an alle großen Anbieter.

SRS-Probleme eingrenzen: eine Checkliste

Wenn weitergeleitete Nachrichten fehlen, hilft diese Checkliste zu prüfen, ob SRS beteiligt ist oder eine andere Stelle im Versandweg die Ursache darstellt.

1. Return-Path prüfen

Senden Sie eine Testmail von einem externen Konto über Ihre Weiterleitung und prüfen Sie die Rohheader am endgültigen Ziel. Die folgenden Ergebnisse sind ein Beispiel, keine Diagnose allein anhand der Adresse.

# SRS inactive - SPF will fail
Return-Path: <original-sender@external.com>
Authentication-Results: spf=fail (IP not authorized for external.com)

# SRS active - SPF passes on your domain
Return-Path: <SRS0=xxxx=yy=external.com=sender@your-domain.com>
Authentication-Results: spf=pass (IP authorized for your-domain.com)

2. Ausgehende Sperren in Microsoft 365 prüfen

Wenn Sie Nachrichten aus Microsoft 365 weiterleiten und die folgende Richtliniensperre greift, werden sie bereits vor dem Verlassen des Mandanten blockiert. SRS auf einem nachgelagerten Server behebt diese Sperre nicht.

550 5.7.520 Access denied, Your organization does not allow external forwarding.

Prüfen Sie die ausgehende Spamfilterrichtlinie im Defender-Portal. Ändern Sie sie nur nach Freigabe durch die Organisation und mit passenden Schutzmaßnahmen. SRS auf Ihrem empfangenden Server hilft bei dieser Sperre nicht und sollte nicht als Umgehung der Richtlinie dienen.

3. Routingschleifen prüfen

Leitet A an B und B wieder an A weiter, kann je nach Regeln und Schleifenschutz wiederholter Versand entstehen. Suchen Sie in den Logs nach Hinweisen wie diesen:

554 5.4.14 Hop count exceeded
5.4.6 Routing loop detected

Nicht weiterleiten, sondern echte Postfächer hosten

postsrsd konfigurieren, HMAC-Schlüssel verwalten und Fehler bei der DMARC-Ausrichtung untersuchen: Das kann zum Betriebsaufwand gehören, wenn Sie berufliche E-Mails an private Postfächer weiterleiten, um Gebühren pro Postfach zu vermeiden. SRS behandelt ein Problem dieser Architektur. Ein direkt zugestelltes Postfach kann den zusätzlichen Weiterleitungsschritt vermeiden.

Statt contact@client-domain.com an Gmail weiterzuleiten und die SRS-Konfiguration zu pflegen, können Sie contact@client-domain.com als echtes IMAP-Postfach bei TrekMail hosten. Der Zugriff über einen unterstützten Gmail-Client oder eine passende Integration ist möglich, sofern diese IMAP unterstützt. Die Zustellung erfolgt direkt ins Postfach. Der zusätzliche SMTP-Weiterleitungsschritt und dessen Envelope-Umschreibung entfallen, nicht sämtliche Authentifizierungsprobleme. Vergleichen Sie die Ansätze im Leitfaden zur Weiterleitung von Domain-E-Mails an Gmail oder im Vergleich von Alias und Postfach.

Verwalten Sie mehrere Kundendomains? Statt die SRS-Einrichtung auf jedem Kundenserver zu prüfen, können Sie Domains zentral bei TrekMail mit getrennten Postfächern einrichten. Trennung, Verfügbarkeit und Einrichtungsdauer hängen von Konfiguration und aktuellen Funktionen ab; eine Einrichtung innerhalb weniger Minuten oder absolute Sicherheitsisolation sind nicht garantiert. Unser Leitfaden zum E-Mail-Hosting für mehrere Domains erklärt die zentrale Verwaltung und den damit verbundenen Aufwand.

Die beschriebenen TrekMail-Tarife beginnen bei $3.50 pro Monat mit einer kostenlosen Testphase von 14 Tagen. Prüfen Sie die aktuellen Preise, Grenzen und Testbedingungen. Richten Sie echte Postfächer ein, um den zusätzlichen Weiterleitungsaufwand zu vermeiden.