Sender Rewriting Scheme: SRS verstehen und prüfen

Sie richten eine E-Mail-Weiterleitung ein. Der Test funktioniert. Zwei Wochen später fehlt die Vertragsmail eines Kunden. Nicht im Spamordner, keine sichtbare Unzustellbarkeitsmeldung, einfach nicht da. In den Logs finden Sie: 550 5.7.1 Unauthenticated email from domain.com.

Eine fehlende oder fehlerhafte Sender Rewriting Scheme-Konfiguration kann dazu beitragen, doch dieser Fehlercode hat auch andere Ursachen. Bei der E-Mail-Authentifizierung wird unter anderem geprüft, ob der sendende Server für die Domain des Envelope-Absenders autorisiert ist. Eine Weiterleitung kann diese Prüfung auf Protokollebene scheitern lassen. Sender Rewriting Scheme hilft dabei, ist aber auch 2026 allein keine vollständige Lösung. Seine Grenzen zu verstehen ist genauso wichtig wie seine Funktionsweise.

Dieser Leitfaden erklärt, was Sender Rewriting Scheme leistet, wo es an Grenzen stößt und wie eine funktionierende Weiterleitungskette aufgebaut ist. Wenn Sie auch allgemein nach Zustellproblemen suchen, etwa falschen MX-Einträgen, fehlerhaften Catch-all-Regeln oder DNS-Änderungen mit Auswirkungen auf das Routing, lesen Sie zuerst den Leitfaden zum Einrichten und Reparieren von E-Mail-Weiterleitungen.

Warum SPF bei einer E-Mail-Weiterleitung scheitern kann

Bei einer Weiterleitung sendet der weiterleitende Server die Nachricht von seiner eigenen IP, während der Envelope-Absender weiterhin die ursprüngliche Domain enthalten kann. Autorisiert deren SPF-Eintrag diese IP nicht, schlägt SPF fehl. Bei DMARC p=reject kann der Empfänger die Nachricht ablehnen, wenn auch keine gültige DKIM-Signatur mit passendem Domainabgleich vorliegt. Eine SMTP-Ablehnung wird dem weiterleitenden Server gemeldet und kann eine Unzustellbarkeitsmeldung auslösen. Für den Empfänger kann die Nachricht trotzdem ohne sichtbaren Hinweis fehlen.

E-Mail ist keine durchgehende Leitung, sondern eine Kette von SMTP-Verbindungen mit einem neuen TCP-Handshake an jeder Station. Das folgende Beispiel zeigt einen möglichen Fehlerablauf:

1. alice@client.com sendet an contact@your-agency.com
2. Ihr Server nimmt die Nachricht an: Die IP von Alices sendendem Server ist durch den SPF-Eintrag von client.com autorisiert
3. Ihr Server öffnet eine neue SMTP-Verbindung zu Gmail, um die Nachricht weiterzuleiten
4. Gmail sieht eine Verbindung von Ihrer IP
5. Der Envelope-Absender lautet weiterhin alice@client.com
6. Gmail prüft SPF für client.com: Ihre IP ist nicht autorisiert
7. SPF schlägt fehl. Verwendet client.com p=reject und fehlt eine gültige, ausgerichtete DKIM-Signatur, kann Gmail die Nachricht ablehnen

RFC 7208, die SPF-Spezifikation, behandelt dieses bekannte Problem bei Weiterleitungen ausdrücklich. SPF allein erhält die ursprüngliche Autorisierung nicht über eine neue Verbindung hinweg. Eine mögliche Lösung setzt daher am Envelope-Absender an.

Zwei Absenderidentitäten: Envelope und Header

E-Mail hat zwei Ebenen der Absenderidentität. Der Envelope-Absender (RFC 5321, MAIL FROM, P1) wird für SPF-Prüfungen und die Rückleitung von Unzustellbarkeitsmeldungen verwendet. Er dient hauptsächlich den Servern, lässt sich aber auch im Return-Path der Rohheader prüfen. Das Header-From (RFC 5322, P2) erscheint als Absender in Gmail oder Outlook. Bei Weiterleitungen können diese Identitäten auseinanderfallen. Sender Rewriting Scheme bearbeitet die Envelope-Ebene, ohne die sichtbare Absenderangabe zu ändern.

Bei der Weiterleitung bleibt das Header-From alice@client.com. Ihr Server beginnt eine neue SMTP-Transaktion, und SPF wird an dieser Station anhand des Envelope-Absenders geprüft. Ist der neue sendende Server für diese Domain nicht autorisiert, entsteht das beschriebene Problem.

Was Sender Rewriting Scheme tatsächlich macht

Sender Rewriting Scheme schreibt die Adresse des Envelope-Absenders (P1) um, bevor der weiterleitende Server seine neue SMTP-Verbindung öffnet. Das für den Empfänger sichtbare Header-From bleibt unverändert. Die neue Envelope-Domain kann den weiterleitenden Server per SPF autorisieren. Damit kann SPF am Ziel bestehen, sofern die Konfiguration stimmt; Zustellung und DMARC-Ausrichtung auf die ursprüngliche From-Domain sind dadurch nicht garantiert.

Der Vergleich mit der Post: Ohne Sender Rewriting Scheme erhalten Sie Alices Brief, legen ihn in einen neuen Postsack und lassen ihre Rücksendeadresse darauf stehen. Am Ziel kommt die Lieferung von Ihnen, behauptet aber durch die Rücksendeadresse, von Alice zu stammen. Das kann zur Ablehnung führen. Mit Sender Rewriting Scheme ersetzen Sie Alices Rücksendeadresse durch Ihre eigene. Der Rückweg passt nun zu Ihnen als Weiterleiter. Muss die Sendung zurück, kommt sie zu Ihnen, und Sie leiten sie an Alice zurück.

Das Format einer SRS-Adresse entschlüsseln

Ist Sender Rewriting Scheme aktiv, wird der Envelope-Absender vor der Weiterleitung in eine codierte Adresse umgewandelt. Deren Domain muss für den tatsächlichen Versandweg gültig konfiguriert sein. Die Adresse enthält einen kryptografischen Prüfwert zur Validierung, einen Zeitstempel zur zeitlichen Begrenzung und die ursprüngliche Absenderadresse zur Rückleitung von Unzustellbarkeitsmeldungen. Das ist kein Zeichensalat, sondern strukturierte Information. Die Schutzwirkung hängt von der Implementierung ab.

Ein Beispiel für eine mit SRS umgeschriebene Adresse:

SRS0=4fac=PM=client.com=alice@your-agency.com

• SRS0: erste Weiterleitung. SRS1 kann bei einer weiteren Weiterleitung erscheinen und begrenzt in unterstützten Implementierungen das Wachstum der Adresse
• 4fac: beispielhafter HMAC-SHA1-Prüfwert dieser Implementierung. Er dient zur Validierung eingehender Unzustellbarkeitsmeldungen; ungültige Werte können zurückgewiesen werden, um Backscatter-Missbrauch zu erschweren
• PM: Zeitstempel. Ein konfigurierbares Gültigkeitsfenster kann beispielsweise 7-21 Tage betragen. Abgelaufene Adressen lassen sich ablehnen; das ist keine universelle Garantie gegen Replay-Angriffe
• client.com=alice: codierter ursprünglicher Absender, über den Unzustellbarkeitsmeldungen an die richtige Adresse zurückgeleitet werden

Wann Sie Sender Rewriting Scheme brauchen

Sender Rewriting Scheme ist relevant, wenn Sie E-Mails automatisch zwischen Domains weiterleiten und die IP des Weiterleiters nicht vom SPF-Eintrag des ursprünglichen Absenders autorisiert wird. Strenge DMARC-Regeln machen eine solche Infrastruktur ohne passende Authentifizierungsmaßnahmen riskant. SRS adressiert dabei SPF für die umgeschriebene Envelope-Domain, nicht alle Zustellprobleme.

Eigene Domain mit Weiterleitung an ein privates Gmail-Konto. Sie besitzen cool-startup.com und leiten alle E-Mails an founder@gmail.com weiter. SRS kann hier die SPF-Prüfung unterstützen. Ohne Umschreibung kann SPF bei Nachrichten von Banken, Behörden oder anderen Absendern mit strengen DMARC-Regeln scheitern. Ob DMARC dennoch besteht, hängt unter anderem von einer gültigen, ausgerichteten DKIM-Signatur ab.

MSP oder Agentur mit gemeinsamem Mailcluster. Sie hosten 200 Kundendomains. Kunden richten regelmäßig Weiterleitungen zu ihren Anbietern ein, etwa Comcast, AT&T oder Outlook. Weitergeleiteter Spam kann Ihrer sendenden IP zugerechnet werden, auch wenn Sie ihn nicht selbst erstellt haben. Fehlende SPF-Autorisierung und unerwünschter Versand können die Reputation belasten und zu einer Spamhaus-Listung beitragen, im ungünstigen Szenario schon innerhalb weniger Wochen. Das ist weder unvermeidlich noch ein durch SRS allein beseitigtes Risiko.

Microsoft 365 mit ausgehendem Connector. M365 kann SRS für unterstützte Versandwege intern einsetzen. Bei der Übergabe über einen ausgehenden Connector sollten Sie prüfen, ob die Umschreibung tatsächlich erfolgt. Konfigurieren Sie SenderRewritingEnabled nur, wenn die unterstützte Version und der Connector dies vorsehen und die Änderung autorisiert ist. Prüfen Sie außerdem die ausgehende Spamfilterrichtlinie auf die Sperre für externe Weiterleitung mit 5.7.520: Sie betrifft eine Richtlinie und ist kein Beweis für einen SRS-Fehler.

Warum Sender Rewriting Scheme allein nicht reicht

Sender Rewriting Scheme kann SPF für die neue Envelope-Domain ermöglichen, stellt aber nicht automatisch die DMARC-Ausrichtung auf die ursprüngliche From-Domain her. DMARC verlangt eine gültige, ausgerichtete SPF- oder DKIM-Authentifizierung. SRS ersetzt die Envelope-Domain durch die Weiterleitungsdomain, lässt das Header-From aber unverändert. Sind diese Domains nicht ausgerichtet, muss eine gültige, ausgerichtete DKIM-Signatur erhalten bleiben, damit DMARC besteht.

Änderungen durch weiterleitende Server können DKIM-Signaturen beschädigen, wenn sie signierte Teile betreffen und die verwendete Kanonisierung sie nicht auffängt:

• Das Hinzufügen von [EXTERNAL] zum Betreff kann DKIM ungültig machen, wenn dieser Header signiert ist
• Angehängte Fußzeilen, etwa Hinweise zur Virenprüfung oder Abmeldelinks, können den signierten Body-Hash verändern und DKIM ungültig machen
• Eine MIME-Umschreibung, etwa die Umwandlung von 8-Bit- in 7-Bit-Codierung, kann signierte Inhalte verändern und DKIM ungültig machen

Im Fehlerfall fehlt die SPF-Ausrichtung auf die ursprüngliche From-Domain, und DKIM wird durch Änderungen ungültig. Damit scheitert DMARC. Der Empfänger kann die Nachricht gemäß seiner Richtlinie ablehnen; eine SMTP-Ablehnung oder Unzustellbarkeitsmeldung ist möglich.

Eine ergänzende Maßnahme ist ARC (Authenticated Received Chain, RFC 8617). Damit kann Ihr Weiterleiter die tatsächlich beobachteten Authentifizierungsergebnisse in einer signierten Kette dokumentieren. Hinzu kommen drei Header:

• ARC-Authentication-Results: hält die beim Eingang tatsächlich festgestellten SPF-, DKIM- und DMARC-Ergebnisse fest, nicht automatisch erfolgreiche Prüfungen
• ARC-Message-Signature: signiert den Nachrichtenstand zum Zeitpunkt der ARC-Signierung
• ARC-Seal: eine kryptografische Signatur, die den ARC-Satz mit der Kette verbindet

Ein Empfänger wie Gmail kann ARC auswerten, wenn die aktuellen Authentifizierungsprüfungen einer weitergeleiteten Nachricht scheitern. Ob er die Kette akzeptiert und ihr bei seiner Zustellentscheidung vertraut, liegt in seinem Ermessen. ARC repariert nicht die DMARC-Ausrichtung. Vertrauen lässt sich weder erzwingen noch allein durch eine über längere Zeit aufgebaute Domainreputation garantieren.

So prüfen Sie, ob Sender Rewriting Scheme funktioniert

Senden Sie eine Testmail von einem externen Konto an Ihre Weiterleitungsadresse und prüfen Sie die Rohheader am Ziel. Der Header Return-Path zeigt, ob für diese Nachricht eine SRS-Umschreibung sichtbar ist oder weiterhin die ursprüngliche Absenderadresse verwendet wird. Prüfen Sie zusätzlich die Authentifizierungsergebnisse.

Schritt 1: Return-Path am Ziel prüfen

# SRS inactive - SPF is almost certainly failing:
Return-Path: <original-sender@protonmail.com>

# SRS active:
Return-Path: <SRS0=xxxx=yy=protonmail.com=sender@your-domain.com>

Schritt 2: DNS Ihrer SRS-Domain prüfen

# Check SPF on your forwarding domain:
dig TXT your-domain.com | grep spf

# Check MX - bounces need a place to go:
dig MX your-domain.com

Die SRS-Domain braucht eine passende SPF-Autorisierung und einen erreichbaren Rückweg für Unzustellbarkeitsmeldungen. Prüfen Sie dafür die MX-Konfiguration. Ein fehlender MX-Eintrag bedeutet nicht automatisch Unerreichbarkeit: Unter bestimmten Bedingungen kann die Zustellung implizit über A- oder AAAA-Einträge erfolgen. Entscheidend ist, dass der tatsächliche Rückweg funktioniert; dessen Probleme können zur Ablehnung beitragen.

Schritt 3: Mail-Log unter Linux prüfen

grep "srs_forward" /var/log/mail.log

Meldungen wie hash mismatch oder timestamp expired können auf nicht synchronisierte PostSRSd-Schlüssel, Schlüsselwechsel, Verzögerungen, beschädigte Adressen oder einen Replay-Versuch hinweisen. Sie beweisen keinen Angriff. Postfix bringt SRS nicht nativ mit; PostSRSd ist eine mögliche Integration, deren Version und Konfiguration Sie prüfen müssen. Prüfen Sie, ob Ihre Version SRS_EXCLUDE_DOMAINS verwendet, und legen Sie lokale Ausnahmen passend zu Ihren Domains und Routingregeln fest, damit interne Nachrichten nicht unnötig umgeschrieben werden. Eine fehlende Ausnahme führt nicht zwangsläufig zu einer Schleife, kann aber die Fehlersuche erschweren.

Die einfachere Alternative: nicht weiterleiten

Sender Rewriting Scheme bearbeitet ein Problem, das durch die neue SMTP-Verbindung beim Weiterleiten entsteht. Ein echtes IMAP-Postfach auf Ihrer Domain kann diesen zusätzlichen Weiterleitungsschritt vermeiden. Die Nachricht wird direkt im Postfach zugestellt, und der Client greift über IMAP darauf zu. Dadurch entfallen weiterleitungsbedingte Authentifizierungsprobleme dieses Schritts, nicht sämtliche SPF-, DKIM- oder DMARC-Risiken. IMAP garantiert keine Ende-zu-Ende-Authentifizierung.

Weiterleitungen sind beliebt, weil niemand pro Nutzer für ein Postfach zahlen möchte, das nur fünf E-Mails im Monat bekommt. SRS ist deshalb manchmal Teil einer Lösung für ein Preisproblem, nicht nur für ein technisches Problem.

Das beschriebene TrekMail-Modell setzt hier an: Tarife beginnen bei $3.50 pro Monat und umfassen mehrere Domains mit gemeinsam genutztem Speicher zum Pauschalpreis, ohne Gebühren pro Nutzer. Prüfen Sie aktuelle Preise, Grenzen und Funktionen des gewählten Tarifs. Sie können sales@yourdomain.com als echtes IMAP-Postfach betreiben und über unterstützte Clients oder Integrationen auf Ihre Nachrichten zugreifen. Eine Gmail- oder Outlook-Anbindung setzt passende Unterstützung voraus. Ohne externe Weiterleitung entfällt deren SRS- und ARC-Konfiguration; die übrige E-Mail-Authentifizierung bleibt relevant.

Für Umgebungen mit mehreren Kunden erklärt der Leitfaden zum E-Mail-Hosting für mehrere Domains, wie Sie zahlreiche Domains zentral verwalten können. Bei einer Mischumgebung mit echten Postfächern und älteren Weiterleitungen hilft der Leitfaden zur E-Mail-Alias-Weiterleitung bei der Einrichtung eines Versandwegs mit SRS.

Ob Sie weiterleiten oder auf Postfächer umstellen: Verstehen Sie die Aufgabe von Sender Rewriting Scheme, prüfen Sie die Umsetzung und ergänzen Sie ARC, wo es unterstützt wird und sinnvoll ist. Unvollständig konfigurierte Weiterleitungen können legitime E-Mails verlieren. Das ist ein Geschäftsrisiko, keine bloße technische Besonderheit.

Beginnen Sie mit einem kostenlosen TrekMail-Konto und prüfen Sie die aktuellen Bedingungen für die beschriebene Nutzung ohne Karte und ohne Ablauf der Testphase. So können Sie E-Mail für mehrere Domains ohne die zusätzliche Komplexität einer Weiterleitung erproben.