SRS-Weiterleitung: PostSRSd, ARC und Konfigurationsprüfung

E-Mail-Weiterleitung klingt einfach: Eine Umleitung einrichten, fertig. Doch ohne SRS-Weiterleitung (Sender Rewriting Scheme) kann SPF scheitern. Beispiel: bank.com sendet an eine Weiterleitungsadresse auf Ihrem Server, und dieser leitet die Nachricht weiter. Am Ziel kommt die Verbindung von Ihrer IP, während der Envelope-Absender weiterhin bank.com verwendet. Autorisiert die Domain Ihre IP nicht, schlägt SPF fehl. Bei DMARC p=reject kann die Nachricht abgelehnt werden, sofern auch keine gültige, ausgerichtete DKIM-Signatur vorliegt. Eine SMTP-Ablehnung oder Unzustellbarkeitsmeldung ist möglich; die Nachricht verschwindet nicht immer unbemerkt.

Dieser Leitfaden behandelt die betriebliche Einrichtung von SRS. Der vollständige Leitfaden zur Einrichtung von E-Mail-Weiterleitungen und ihren Fehlerquellen liefert den Überblick. Hier geht es gezielt um die SRS-Ebene: Architektur, Umschreibsyntax, Postfix-Integration und ARC als mögliche Ergänzung für die Authentifizierungsentscheidung des Empfängers.

Was SRS-Weiterleitung tatsächlich macht

SRS schreibt den Envelope-Absender um, wenn Ihr Server eine E-Mail weiterleitet. Dabei ersetzt es die ursprüngliche Absenderdomain durch eine Domain unter Ihrer Kontrolle. SPF kann am Ziel bestehen, wenn diese Domain den tatsächlichen Versandweg Ihres Weiterleiters korrekt autorisiert. Der From-Header, den der Empfänger im E-Mail-Client sieht, bleibt unverändert.

Ohne Umschreibung kann SPF für weitergeleitete Nachrichten scheitern, wenn die ursprüngliche Domain den neuen Server nicht autorisiert. SRS kann diese Prüfung unterstützen, erhält aber nicht automatisch die gesamte Authentifizierungskette oder die DMARC-Ausrichtung auf den ursprünglichen Absender. Prüfen Sie die Anforderungen Ihres tatsächlichen Versandwegs.

Zwei Ebenen der E-Mail-Identität

Für eine korrekte SRS-Konfiguration müssen Sie zwei getrennte Adressfelder unterscheiden. SPF prüft die Envelope-Ebene; beim Wechsel des sendenden Servers kann deren Autorisierung nicht mehr passen.

• Envelope-Absender (RFC 5321 MAIL FROM): Die Rücklaufadresse, über die Mailserver Unzustellbarkeitsmeldungen routen. SPF prüft, ob die verbindende IP für diese Domain senden darf. Der Envelope-Absender ist auch im Return-Path der Rohheader prüfbar.
• Header-From (RFC 5322 From): Die im E-Mail-Client angezeigte Adresse. DMARC prüft die Ausrichtung auf mindestens eine gültig über SPF oder DKIM authentifizierte Domain. SRS lässt dieses Feld unverändert.

Das folgende Beispiel zeigt SPF-Ergebnisse bei einer Weiterleitung mit und ohne SRS, wenn die jeweilige Domain den Server wie dargestellt autorisiert:

Die SRS-Umschreibung setzt eine Domain unter Ihrer Kontrolle in den Envelope-Absender. Deren SPF-Eintrag muss Ihren Versandweg autorisieren. Das kann die Prüfung ermöglichen, garantiert aber keine Zustellung. Die umgeschriebene Adresse erscheint normalerweise nicht als sichtbarer Absender, lässt sich jedoch in den Rohheadern lesen.

SRS-Syntax: die Bedeutung der einzelnen Bestandteile

Eine mit SRS umgeschriebene Adresse wirkt kryptisch, doch jeder Bestandteil hat eine Aufgabe. Wer sie lesen kann, kann Fehler in Rücklaufprotokollen und Weiterleitungsketten mit mehreren Stationen besser untersuchen.

Eine SRS-Umschreibung bei der ersten Station (SRS0) sieht so aus:

SRS0=Hash=Timestamp=OriginDomain=OriginLocalPart@AnchorDomain

Die Bestandteile:

• Hash: Ein gekürzter HMAC-Authentifizierungscode aus einem lokalen geheimen Schlüssel, in manchen Implementierungen mit SHA1. Er erschwert das Fälschen von SRS-Rücklaufadressen auf Ihrer Domain. Ohne geeignete Validierung können scheinbar gültige SRS0-Adressen für unerwünschte Unzustellbarkeitsmeldungen missbraucht werden; die Schutzwirkung hängt vom Verfahren und Schlüsselmanagement ab.
• Timestamp: In diesem Beispiel Base32-codiert, mit einem konfigurierbaren Gültigkeitsfenster von etwa 7-21 Tagen. Abgelaufene Adressen können abgelehnt werden. Das begrenzt bestimmte Replay-Risiken, beseitigt sie aber nicht vollständig.
• Origin: Die Daten zur Rekonstruktion des ursprünglichen Absenders bei einer Unzustellbarkeitsmeldung. Ihr Server nimmt die Meldung entgegen, ordnet die Adresse zurück zu und leitet sie an den richtigen Absender weiter.
• AnchorDomain: Die Domain unter Ihrer Kontrolle. Ihr SPF-Eintrag muss den Weiterleiter autorisieren, und ein erreichbarer Rücklaufweg muss Unzustellbarkeitsmeldungen annehmen können. Üblicherweise wird dafür MX eingerichtet; unter bestimmten Bedingungen ist auch ein impliziter Rückweg über A oder AAAA möglich.

Bei einer weiteren Weiterleitung kann aus SRS0 SRS1 werden:

SRS1=NewHash=PreviousAnchorDomain==SRS0_Suffix@NewAnchorDomain

SRS1 begrenzt das Wachstum des lokalen Adressteils. Die Grenze von 64 Zeichen aus RFC 5321 bleibt relevant; das Verfahren garantiert ihre Einhaltung nicht für jede Kette. Prüfen Sie bei Fehlern in mehrstufigen Weiterleitungen unter anderem die Adresslänge, aber auch Routing und Authentifizierung.

Postfix-Integration: PostSRSd einrichten

PostSRSd ist eine verbreitete Möglichkeit, SRS auf Linux/Postfix-Systemen zu integrieren. Ein Hintergrunddienst liefert Postfix umgeschriebene Envelope-Adressen über passende Mapping-Schnittstellen. Die folgenden Beispiele müssen zu Ihrer tatsächlich installierten Version passen. Prüfen Sie Konfigurationssyntax, Socketpfad, Zugriffsrechte und die Einbindung in Ihre bestehende Postfix-Konfiguration, bevor Sie Änderungen übernehmen.

Schritt 1: Voraussetzungen der Ankerdomain

Bereiten Sie die Ankerdomain vor, bevor Sie Konfigurationsdateien ändern. Diese Domain erscheint in den von Ihrem Server umgeschriebenen Envelope-Absendern. Relevant sind:

• MX-Einträge: Unzustellbarkeitsmeldungen werden an diese Domain geroutet. Prüfen Sie, ob der Rückweg tatsächlich Nachrichten annimmt. Fehlender Empfang kann Rückmeldungen verlieren lassen. RFC 5321 beschreibt auch die implizite MX-Zustellung über A oder AAAA unter bestimmten Bedingungen; ein fehlender expliziter MX allein beweist daher keine Unerreichbarkeit.
• SPF-Eintrag: Zielserver prüfen SPF dieser Domain gegen Ihre sendende IP. Ist der tatsächliche Versandweg nicht autorisiert, kann SPF trotz aktiver SRS-Umschreibung scheitern.
• Gute Reputation: Weitergeleiteter Spam kann die Reputation Ihrer IP und Ankerdomain belasten und zu Sperrlisteneinträgen beitragen. Das ist nicht zwangsläufig, doch SRS schirmt Sie nicht von der weitergeleiteten Post ab.

# Verify SPF record exists for your anchor domain
dig relay.yourdomain.com TXT +short
# Expected output - must include your server IP:
"v=spf1 ip4:203.0.113.10 -all"

# Check MX records exist for bounce delivery
dig relay.yourdomain.com MX +short

Schritt 2: PostSRSd konfigurieren

Je nach Paket und Version kann die Konfiguration in /etc/default/postsrsd (Debian/Ubuntu) oder /etc/postsrsd/postsrsd.conf liegen. Prüfen Sie die tatsächlich verwendete Datei und unterstützte Syntax, einschließlich der versionsabhängigen Domain-Ausnahmen:

# Domain that appears in SRS-rewritten envelope senders
SRS_DOMAIN=relay.yourdomain.com

# Secret key path
# In a multi-server cluster, this file MUST be identical on all nodes.
# If nodes have different secrets, they can't validate each other's bounces.
SRS_SECRET=/etc/postsrsd.secret

# Exclusion list - critical config, don't skip this
# Without it, Postfix rewrites local-to-external mail too,
# causing routing confusion and potential delivery loops.
SRS_EXCLUDE_DOMAINS=yourdomain.com,client-one.com,client-two.com

Wenn noch kein Schlüssel vorhanden ist, können Sie einen starken geheimen Schlüssel erzeugen. Achtung: Die Umleitung im folgenden Beispiel überschreibt eine vorhandene Datei. Führen Sie sie nicht ungeprüft auf einem bestehenden System aus. Sichern Sie vorhandene Schlüssel geschützt, planen Sie Rotation und Synchronisierung im Cluster und prüfen Sie Eigentümer sowie Zugriffsrechte. Bereits ausgegebene Rücklaufadressen können von alten Schlüsseln abhängen:

openssl rand -base64 32 > /etc/postsrsd.secret
chmod 600 /etc/postsrsd.secret

Schritt 3: In Postfix integrieren

Die Integration erfolgt in /etc/postfix/main.cf. Das folgende Beispiel zeigt Socketmaps für PostSRSd 2.x und TCP für Version 1.x. Übernehmen Sie es nicht unverändert: Prüfen Sie den tatsächlichen Socketpfad, Rechte, Erreichbarkeit und die Syntax Ihrer installierten Version:

# PostSRSd 2.x - modern installs (unix socket maps)
sender_canonical_maps = socketmap:unix:srs:forward
sender_canonical_classes = envelope_sender
recipient_canonical_maps = socketmap:unix:srs:reverse
recipient_canonical_classes = envelope_recipient

# PostSRSd 1.x - legacy installs (TCP)
# sender_canonical_maps = tcp:localhost:10001
# sender_canonical_classes = envelope_sender
# recipient_canonical_maps = tcp:localhost:10002
# recipient_canonical_classes = envelope_recipient

Nach Prüfung der Konfiguration und im vorgesehenen Wartungsfenster können Sie beide Dienste neu starten:

systemctl restart postsrsd
systemctl restart postfix

SRS allein reicht nicht immer: ARC als Ergänzung

SRS kann das SPF-Problem für die neue Envelope-Domain behandeln, stellt aber nicht automatisch die DMARC-Ausrichtung her. DMARC verlangt, dass entweder die erfolgreich per SPF authentifizierte Domain oder die gültige DKIM-Signierdomain auf das Header-From ausgerichtet ist. Nach SRS authentifiziert SPF im Beispiel relay.yourdomain.com statt client.com. Ohne diese Ausrichtung bleibt eine gültige, ausgerichtete DKIM-Signatur als Weg zum Bestehen von DMARC.

Weiterleitungen können DKIM beschädigen. Ein Präfix wie „External Sender“ im Betreff, angehängte Abmeldelinks oder geänderte MIME-Grenzen können die ursprüngliche Signatur ungültig machen, wenn signierte Teile betroffen sind und die verwendete Kanonisierung die Änderung nicht auffängt. Fehlen danach sowohl SPF-Ausrichtung als auch gültiges ausgerichtetes DKIM, scheitert DMARC und ein strenger Empfänger kann ablehnen.

Eine mögliche Ergänzung ist ARC, Authenticated Received Chain, definiert in RFC 8617. Ihr Weiterleiter kann damit die beim Eingang tatsächlich beobachteten Authentifizierungsergebnisse signiert festhalten. Empfänger, die dem ARC-Signierer und der Kette vertrauen, können diese Angaben bei ihrer Entscheidung über ein aktuelles DMARC-Scheitern berücksichtigen. ARC repariert keine Domainausrichtung und garantiert keine Zustellung.

ARC ergänzt drei Header bei der weitergeleiteten Nachricht:

• ARC-Authentication-Results: die beim Eingang tatsächlich festgestellten Authentifizierungsergebnisse, nicht zwingend erfolgreiche Prüfungen
• ARC-Message-Signature: signiert ausgewählte Header und den Body im Zustand zum Zeitpunkt der ARC-Signierung
• ARC-Seal: verknüpft den ARC-Satz kryptografisch mit der Kette über mehrere Stationen

SRS behandelt den Envelope, ARC dokumentiert Authentifizierungskontext. In strengen DMARC-Umgebungen, etwa bei Google oder Microsoft, können beide nützlich sein. Sie sind weder überall zwingend nötig noch zusammen ausreichend für garantierte Zustellung. Fehlen SPF-Ausrichtung und gültiges ausgerichtetes DKIM, lässt SRS allein DMARC nicht bestehen.

Die maßgebliche Referenz für SPF, dessen Weiterleitungsproblem SRS adressiert, ist RFC 7208.

Anbieterspezifische Fehler vor der Einführung kennen

Auch bei korrekt eingerichtetem SRS und ARC können Anbieterregeln die Weiterleitung einschränken. Das muss kein Fehler Ihrer Konfiguration sein. Prüfen Sie den betroffenen Versandweg und die geltende Richtlinie, bevor solche Einschränkungen den produktiven Betrieb beeinträchtigen.

Der M365-Fehler 550 5.7.520 kann viel Zeit kosten, wenn Sie ihn als SRS-Problem behandeln. In diesem Szenario sperrt eine Sicherheitsrichtlinie im sendenden Mandanten die externe Weiterleitung, bevor die Nachricht ihn verlässt. SRS oder ARC auf dem nachgelagerten Server beheben das nicht. Änderungen im Microsoft-Defender-Portal brauchen die passenden Verwaltungsrechte und die Freigabe der Organisation.

Prüfen, ob SRS-Weiterleitung funktioniert

Prüfen Sie SRS vor dem produktiven Einsatz. Senden Sie eine Testnachricht durch die Kette und lesen Sie die Rohheader am Ziel. Eine SRS-Adresse im Return-Path zeigt eine sichtbare Umschreibung dieser Nachricht, nicht automatisch vollständige Korrektheit. Bleibt die ursprüngliche Adresse erhalten, kommen unter anderem Domain-Ausnahmen, ein anderer Versandweg oder eine fehlende PostSRSd-Abfrage infrage.

1. Return-Path prüfen

Senden Sie eine Testmail von einem externen Konto, beispielsweise ProtonMail, an Ihre Weiterleitungsadresse. Öffnen Sie am Ziel den Nachrichtenquelltext und suchen Sie die Return-Path-Zeile:

• Return-Path: <SRS0=...@yourdomain.com> → eine SRS-Umschreibung ist für diese Nachricht sichtbar; prüfen Sie auch die Authentifizierungsergebnisse
• Return-Path: <alice@protonmail.com> → keine Umschreibung sichtbar; prüfen Sie Ausnahmen, Versandweg und Dienstintegration

2. DNS der Ankerdomain prüfen

# SPF record must cover your server IP
dig relay.yourdomain.com TXT +short

# MX record must exist so bounces can arrive
dig relay.yourdomain.com MX +short

3. Postfix-Logs prüfen

grep -E "srs_forward|canonical" /var/log/mail.log | tail -50

Prüfen Sie, ob Postfix den SRS-Dienst abfragt und umgeschriebene Adressen erhält; verfügbare Logdetails hängen von Konfiguration und Logniveau ab. „Connection refused“ kann auf einen gestoppten Dienst, eine falsche Adresse, Socket- oder Netzwerkprobleme hinweisen. Prüfen Sie unter anderem systemctl status postsrsd, die konfigurierte Schnittstelle und gegebenenfalls Firewallregeln.

4. Erreichbarkeit und TLS testen

SRS- und TLS-Probleme können sich in ähnlichen Zustellfehlern zeigen. Prüfen Sie deshalb auch die Netzwerkverbindung und STARTTLS:

openssl s_client -connect gmail-smtp-in.l.google.com:25 -starttls smtp

Ein Timeout kann durch Netzwerk- oder Portsperren entstehen und beweist kein TLS-Problem. Scheitert die Aushandlung, prüfen Sie zusätzlich TLS-Konfiguration und Fehlermeldungen. Diese Ursachen sind getrennt von der SRS-Umschreibung zu untersuchen.

Wann Sie nicht mehr weiterleiten, sondern Postfächer hosten sollten

SRS, ARC, Ankerdomain, Schlüsselmanagement, Domain-Ausnahmen und Reputationsüberwachung erzeugen echten Betriebsaufwand. Viele Organisationen nutzen Weiterleitungen, um Gebühren pro Postfach bei großen Anbietern zu vermeiden. Sie leiten sales@ an Ihr privates Postfach weiter und sparen im Beispiel einen Nutzerplatz für $6 pro Monat. Was bei einer Adresse sinnvoll wirkt, kann bei zehn Adressen teuer im Betrieb werden.

Wenn Sie Optionen vergleichen, erläutert der Leitfaden zu den Vor- und Nachteilen von Alias-Weiterleitungen, wann Weiterleitung sinnvoll ist und wann sich Probleme ansammeln. Der Entscheidungsleitfaden zu Alias und Postfach hilft bei der Wahl der zugrunde liegenden Adressstruktur.

Der beschriebene TrekMail-Pro-Tarif bietet für $10 pro Monat 100 Domains und 50GB gemeinsamen Speicher. Prüfen Sie aktuelle Preise, Grenzen und Funktionen. Hosten Sie sales@, support@ und info@ als echte IMAP-Postfächer, ohne Gebühren pro Nutzer gemäß dem beschriebenen Modell. Der zusätzliche Weiterleitungsschritt und dessen SRS-Pflege entfallen. Direkte Zustellung und Speicherung bleiben von Konfiguration, Quoten und Anbieterentscheidungen abhängig.

Wenn Sie eine Weiterleitung brauchen, etwa um mehrere Domains an einem Ziel zusammenzuführen, übernimmt die beschriebene verwaltete Weiterleitung in Pro und Agency SRS-Umschreibung und OpenARC-Signierung serverseitig. Prüfen Sie die aktuelle Unterstützung. Sie setzen die Zieladresse im Dashboard; die Verarbeitung auf dem Server garantiert weder DMARC-Ausrichtung noch Annahme. Nano mit BYO SMTP bedeutet nicht automatisch eine Berechtigung zur verwalteten Weiterleitung. Wenn Sie über eigene Infrastruktur weiterleiten, ist SRS dort relevant; die PostSRSd-Beispiele müssen zu Ihrer Version und Architektur passen.

Für den konkreten Versandweg von einer eigenen Domain zu Gmail behandelt der Leitfaden zur Weiterleitung von Domain-E-Mails an Gmail die Gmail-spezifischen Fehler und Prüfschritte im Detail.

Die Kurzfassung

SRS-Weiterleitung schreibt den Envelope-Absender um, damit SPF die Domain des Weiterleiters prüfen kann. Die Prüfung kann bestehen, wenn diese Domain die sendende IP korrekt autorisiert. Ohne SRS scheitert nicht jede weitergeleitete Nachricht. PostSRSd ist eine mögliche Postfix-Integration mit erreichbarer Ankerdomain, passendem SPF, geheimem Schlüssel, geeigneten Domain-Ausnahmen und Mapping-Einträgen in main.cf. Prüfen Sie Version und Syntax. ARC kann Authentifizierungskontext ergänzen, wenn DKIM unterwegs beschädigt wird, repariert aber keine fehlende DMARC-Ausrichtung.

Prüfen Sie nach jeder Konfigurationsänderung die Rohheader und tatsächlichen Authentifizierungsergebnisse. Übersteigt der SRS-Betriebsaufwand die eingesparten Lizenzkosten, kann direktes Hosting sinnvoller sein. Prüfen Sie die TrekMail-Tarife und die aktuellen Bedingungen des beschriebenen Nano-Angebots ohne Kreditkarte. Die Einrichtung hängt von DNS und Konfiguration ab und ist nicht überall sofort abgeschlossen. Pro bietet im beschriebenen Umfang verwaltete SRS-Weiterleitung und ARC, wenn Sie diese Verarbeitung abgeben möchten.