E-Mail-Weiterleitung mit SRS: SPF, DMARC und Grenzen

Sie richten eine Weiterleitung ein: contact@yourdomain.com geht an Gmail. Zunächst funktioniert sie, später fehlen Kundennachrichten. In den Protokollen stehen etwa 550 5.7.1 Unauthenticated email oder 550 5.7.26 This message does not have authentication information. Solche Fehler erfordern eine genaue Prüfung und beweisen nicht allein einen SRS-Fehler. E-Mail-Weiterleitung mit SRS adressiert ein typisches Problem: Ihr Server öffnet eine neue SMTP-Verbindung, während der ursprüngliche Absender im Umschlag bleibt. Ist Ihre IP für dessen Domain nicht autorisiert, kann SPF scheitern. Bei DMARC mit p=reject kann der Empfänger ablehnen, wenn weder SPF noch DKIM gültig und passend zum sichtbaren From ist. Eine SMTP-Ablehnung kann einen Unzustellbarkeitsbericht auslösen; Nachrichten verschwinden nicht immer lautlos.

SRS allein löst nicht alle Probleme. Auch nach korrekter Einrichtung können weitere Authentifizierungs- oder Richtlinienfehler die Zustellung verhindern. Der Leitfaden zur Einrichtung und Fehlerbehebung bei E-Mail-Weiterleitung beschreibt weitere Fälle und deren Diagnose.

Was ist E-Mail-Weiterleitung mit SRS?

E-Mail-Weiterleitung mit SRS, dem Sender Rewriting Scheme, schreibt die Umschlagabsenderadresse vor der Weitergabe an ein neues Ziel um. Die ursprüngliche Domain wird im technischen Rücklaufpfad durch die Weiterleitungsdomain ersetzt. SPF kann dann erfolgreich sein, wenn deren aktuelle DNS-Konfiguration die sendende IP autorisiert. Der sichtbare From-Absender bleibt unverändert. SRS arbeitet an der Umschlagebene, ist keine Verschlüsselung; technisch interessierte Nutzer können Return-Path in Rohheadern lesen.

Postfix kann SRS über den Daemon postsrsd integrieren. Microsoft 365 unterstützt es in bestimmten Versand- und Hybridkonfigurationen, ebenso verschiedene verwaltete Plattformen. Unterstützung und Einrichtung hängen von Version, Route und aktuellem Angebot ab. SRS hilft bei einem Konflikt zwischen klassischer Weiterleitung und SPF, garantiert aber keine DMARC-Erfüllung.

Warum Weiterleitung scheitern kann: die neue SMTP-Station

Eine Weiterleitung erzeugt eine neue SMTP-Station. SPF scheitert dort nicht zwangsläufig, kann aber durch die andere sendende IP beeinträchtigt werden. Header From nach RFC 5322 ist der sichtbare Absender, etwa From: alice@client.com. Der Umschlagabsender nach RFC 5321, MAIL FROM, dient als technische Rücklaufadresse und SPF-Identität. Er ist in normalen Ansichten oft verborgen, aber in Rohheadern zugänglich.

Das folgende Beispiel zeigt, wie ein nicht autorisierter Weiterleitungsschritt zu einer Ablehnung führen kann:

1. Alice sendet als alice@client.com. Ihre SPF-Konfiguration autorisiert ihren Server; SPF ist beim Eingang auf Ihrem Server erfolgreich.
2. Ihr Server öffnet eine neue Verbindung zu you@gmail.com. Jetzt sendet Ihre IP.
3. Der Umschlagabsender bleibt alice@client.com, doch client.com autorisiert Ihre Server-IP im Beispiel nicht.
4. Gmail prüft SPF für client.com. Ohne Autorisierung Ihrer IP scheitert SPF.
5. Veröffentlicht client.com die DMARC-Richtlinie p=reject und fehlt auch gültiges, abgestimmtes DKIM, kann Gmail ablehnen. Ergebnis und mögliche Fehlermeldung folgen der Empfängerrichtlinie.

Wie SRS bei SPF hilft

E-Mail-Weiterleitung mit SRS ersetzt vor der Weitergabe die Umschlagabsenderdomain durch die Weiterleitungsdomain. Der Empfänger prüft SPF nun für diese Domain. Ein Erfolg setzt korrekte Autorisierung der tatsächlichen Versand-IP voraus. Header From bleibt unverändert, während Rückläufer über die Weiterleitungsdomain verarbeitet werden können. Das muss passend zur jeweiligen Implementierung eingerichtet sein.

Die Bestandteile einer SRS-Adresse

Bei aktivem SRS kann eine einfache Rücklaufadresse zu einer strukturierten, durch einen kryptografischen Prüfwert geschützten Adresse werden:

Vor SRS: MAIL FROM: <alice@client.com>
Nach SRS: MAIL FROM: <SRS0=4fac=PM=client.com=alice@yourdomain.com>

Bei einer zweiten Weiterleitung (A → B → C) kann SRS1 verwendet werden. Die verschachtelte Darstellung hängt von der Implementierung ab und ist nicht einfach auf Hash und Zeitstempel beschränkt. Sie begrenzt weiteres Wachstum gegenüber vollständiger wiederholter Kapselung von SRS0. Die Grenze von 64 Zeichen für den lokalen Teil nach RFC 5321 bleibt dennoch zu prüfen; eine beliebige Adresse passt nicht garantiert hinein.

Warum SRS allein nicht reicht: DMARC-Alignment

Viele Administratoren aktivieren E-Mail-Weiterleitung mit SRS und erwarten damit die vollständige Lösung. SPF-Erfolg garantiert jedoch kein DMARC-Alignment. DMARC verlangt erfolgreiches SPF oder DKIM mit einer zum Header From passenden Domain. Nach der Umschreibung kann SPF für yourdomain.com erfolgreich sein, während Header From client.com bleibt. Diese unterschiedlichen Domains sind im Beispiel nicht abgestimmt. Bei gelockertem Alignment können Domains mit derselben Organizational Domain dagegen passen; gemeinsame Unternehmenszugehörigkeit allein genügt nicht.

Fehlt abgestimmtes SPF, kann gültiges, abgestimmtes DKIM weiterhin DMARC erfüllen. Weiterleitungsserver können die Signatur beeinträchtigen, wenn sie signierte Teile verändern, beispielsweise:

• [EXTERNAL] vor eine signierte Betreffzeile setzen
• Antivirus-Fußzeilen oder rechtliche Hinweise in den signierten Inhalt einfügen
• Eine 8-Bit-Kodierung in 7-Bit umwandeln
• MIME-Grenzen umschreiben

Ob eine solche Änderung DKIM ungültig macht, hängt von den signierten Teilen und der Kanonisierung ab. Scheitern beide abgestimmten Authentifizierungswege, scheitert DMARC. Der Empfänger kann dann nach seiner Richtlinie filtern oder ablehnen, obwohl die SRS-Umschreibung korrekt war.

Zusätzliche Unterstützung durch ARC (Authenticated Received Chain)

ARC nach RFC 8617 ermöglicht es einem Zwischenserver, tatsächlich beobachtete Authentifizierungsergebnisse zu dokumentieren und kryptografisch zu schützen. Es darf keinen nicht beobachteten Erfolg behaupten. Dazu gehören drei Header:

• ARC-Authentication-Results: Dokumentiert beobachtete SPF-/DKIM-/DMARC-Ergebnisse beim Empfang
• ARC-Message-Signature: Signiert ausgewählte Header und den Nachrichtenkörper zum Signaturzeitpunkt; spätere relevante Änderungen können sie ungültig machen
• ARC-Seal: Kryptografische Signatur zur Verknüpfung und Absicherung der ARC-Kette

Vertraut der Empfänger einem ARC-Signierer und einer gültigen Kette, kann er deren Informationen bei einer Zustellentscheidung trotz nachgelagerten DMARC-Fehlers berücksichtigen. ARC macht daraus keinen DMARC-Erfolg und garantiert keine Annahme. Gmail wertet ARC seit 2019 produktiv aus; die Vertrauensentscheidung bleibt beim Empfänger.

Für Weiterleitungen im Jahr 2026 sind E-Mail-Weiterleitung mit SRS, das Bewahren signierter Inhalte und ARC wichtige zu prüfende Bausteine. Sie sind nicht in jedem Fall alle notwendig oder gemeinsam ausreichend. Route, Authentifizierung und Empfängerrichtlinie entscheiden.

SRS nach Plattform einrichten

Die Einrichtung unterscheidet sich deutlich. Postfix benötigt eine geeignete Integration, Microsoft 365 hängt von Versandroute und Sicherheitsrichtlinien ab, und Google Workspace besitzt eigene Routing- und Nutzungsgrenzen. Prüfen Sie aktuelle Versionen und Konfigurationen; pauschale Aussagen über Standardaktivierung oder erforderliche Änderungen sind nicht zuverlässig.

Postfix auf einem eigenen Linux-Server

Postfix integriert SRS häufig über postsrsd. Das folgende Paketinstallationsbeispiel ist vor einer autorisierten Anwendung anhand der Distribution und Version zu prüfen:

apt-get install postsrsd

Das folgende TCP-Map-Beispiel für /etc/postfix/main.cf ist eine ältere Integrationsvariante. Sichern Sie bestehende Einstellungen und führen Sie neue Maps sorgfältig mit vorhandenen zusammen. Prüfen Sie Version, unterstützte Syntax, Ports, Sockets, Pfade und Zugriffsrechte:

sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes = envelope_recipient

Wichtig: Die Variable SRS_EXCLUDE_DOMAINS in /etc/default/postsrsd ist versionsabhängig. Prüfen Sie, welche lokalen Domains und Versandwege von der Umschreibung ausgenommen werden müssen. Fehlende Ausnahmen können unerwünschte Umschreibungen oder zusammen mit anderen Routingregeln Schleifen verursachen; sie führen nicht zwangsläufig zu jeder beschriebenen Störung. Testen Sie Ein- und Ausgang sowie Rückläufer.

Microsoft 365

Microsoft 365 kann SRS auf unterstützten ausgehenden Routen anwenden. Verhalten in Hybridumgebungen und über Connectoren ist anhand der aktuellen Konfiguration zu prüfen. Der Fehler 550 5.7.520 Access denied, Your organization does not allow external forwarding weist auf eine ausgehende Weiterleitungsrichtlinie hin, nicht auf einen bewiesenen SRS-Fehler.

Ändern Sie diese Sicherheitsrichtlinie nur nach Autorisierung und enger Prüfung des benötigten Umfangs, nicht zur Umgehung von Schutzmaßnahmen. Die aktuelle Verwaltungsoberfläche und die Einstellungen zur automatischen Weiterleitung können variieren. Der folgende Connector-Befehl ist ein Beispiel; Parameter und Unterstützung sind anhand der tatsächlichen PowerShell-Version und Connector-Art zu prüfen:

Set-OutboundConnector -Identity "Outbound to Gateway" -SenderRewritingEnabled $true

Google Workspace

Google Workspace hat plattformspezifisches Weiterleitungsverhalten. Unter anderem sind folgende Bereiche zu untersuchen; sie sind nicht ausschließlich bei Workspace relevant:

• Volumengrenzen: Catch-all-Weiterleitung und Spamfluten können Quoten oder Schutzmaßnahmen auslösen. Prüfen Sie aktuelle Grenzen; eine vollständige Kontosperre ist nicht zwangsläufig.
• Schleifen und fehlende Nachrichten: Schleifenerkennung kann zurückkehrende Weiterleitungen unterdrücken. Protokollzugriff und verfügbare Spuren hängen von Kontotyp, Berechtigung und Ereignis ab; fehlende sichtbare Logs beweisen keine universell spurenlose Löschung.

Fehler bei SRS-Weiterleitung untersuchen

Rohheader liefern wichtige Hinweise, aber nicht immer die vollständige Ursache. Senden Sie eine Testnachricht von ProtonMail über die Weiterleitung und prüfen Sie die Header am Ziel. Fehlt die Nachricht, ziehen Sie SMTP-Antworten, Serverlogs und verfügbare Nachrichtenverfolgung hinzu. Nicht jeder Fehler ist im Zielheader sichtbar.

Prüfung 1: Return-Path

Beispiel ohne erkennbare SRS-Umschreibung: Return-Path: <original@protonmail.com>
Beispiel mit SRS-Umschreibung: Return-Path: <SRS0=xxxx=yy=protonmail.com=original@yourdomain.com>

Ein unveränderter Return-Path kann auf fehlende Integration, einen nicht laufenden Dienst oder bewusst ausgeschlossene Versandwege hinweisen. Er beweist nicht allein, dass postsrsd ausgefallen ist. Prüfen Sie die tatsächlich durchlaufene Route.

Prüfung 2: Authentication-Results

Suchen Sie in vertrauenswürdigen Authentifizierungsheadern des Empfängers nach spf=pass und prüfen Sie, ob die ausgewertete Domain die SRS-Domain ist. Zeigt der Header trotzdem dmarc=fail, fehlt ein erfolgreicher abgestimmter SPF- oder DKIM-Nachweis. DKIM kann fehlen, ungültig sein oder trotz gültiger Signatur eine unpassende Domain verwenden. Prüfen Sie signierte Inhalte, Änderungen und Alignment, statt automatisch einen veränderten Nachrichtenkörper als Ursache anzunehmen.

Prüfung 3: DNS

dig yourdomain.com TXT +short

Prüfen Sie SPF der Weiterleitungsdomain und die Erreichbarkeit des Rücklaufpfads. Ein MX ist üblich, aber bei fehlendem MX kann ein impliziter Weg über A-/AAAA-Einträge bestehen. Manche Empfänger berücksichtigen die Erreichbarkeit für Rückläufer; ein vorhandener MX allein beweist sie nicht.

Prüfung 4: Postfix-Protokolle

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

Meldungen wie hash mismatch oder timestamp expired können auf unterschiedliche Schlüssel zwischen Knoten, Schlüsselwechsel, Zeit- oder Konfigurationsprobleme, Verzögerungen oder Wiederverwendung alter Adressen hinweisen. Sie beweisen nicht allein einen Replay-Angriff. Prüfen Sie den vollständigen Kontext.

Wann direkte Postfächer statt Weiterleitung sinnvoll sind

E-Mail-Weiterleitung mit SRS behandelt einen strukturellen Konflikt zusätzlicher SMTP-Stationen. SRS, das Bewahren signierter Inhalte und gegebenenfalls ARC schaffen weitere Abhängigkeiten. Weiterleitung kann wegen nutzerbezogener Lizenzkosten günstig wirken, doch Betrieb und Fehleranalyse gehören ebenfalls in die Rechnung. Direkte Postfächer können eine passendere Lösung sein.

Vergleichen Sie beide Ansätze mit ihren tatsächlichen Voraussetzungen:

TrekMail beschreibt Pläne mit gemeinsamem Speicher für Postfächer und Domains statt Einzelpostfachabrechnung. Sie bezahlen einen begrenzten Plan, nicht ausschließlich Speicher oder unbegrenzte Nutzung. Vergleichen Sie das mit einer gewöhnlichen Gmail-Weiterleitung oder lesen Sie die Abwägungen zur Alias-Weiterleitung. Die Gegenüberstellung von Domain-Alias und Postfach hilft bei der Grundentscheidung.

Bei direktem Postfachempfang auf TrekMail entfällt diese externe Weiterleitungsstation; SRS und ARC müssen dann nicht für diesen Empfangsweg eingerichtet werden. Andere Routen können sie weiterhin benötigen. Der beschriebene Assistent unterstützt SPF, DKIM und DMARC, ersetzt aber keine Autorisierung und Tests. Ein autoritativer MX-Empfangsserver ist nicht automatisch ein für SMTP-Versand autorisierter Absender.

Testen Sie TrekMail kostenlos: Nano wird ohne Kreditkarte beschrieben, Starter mit einer 14-tägigen Testphase ab $3.50 monatlich und verwaltetem SMTP. Prüfen Sie aktuelle Berechtigung, Funktionen und Bedingungen, auch für eigene SMTP-Anbieter und Zugangsdaten.

Zusammenfassung

E-Mail-Weiterleitung mit SRS ist in den Jahren 2025-2026 ein wichtiger Baustein, aber keine universelle Pflicht für jede Route. Ohne Umschreibung kann SPF an der Weiterleitungsstation scheitern. Strenges DMARC kann dann zur Ablehnung führen, wenn auch kein gültiges abgestimmtes DKIM vorhanden ist. Mit SRS kann SPF für die Weiterleitungsdomain erfolgreich sein, ohne zum ursprünglichen From zu passen. Gültiges abgestimmtes DKIM kann DMARC weiterhin erfüllen.

Bei Postfix erfordert SRS eine zur Version passende Integration und geprüfte Ausnahmen. Bei Microsoft 365 hängen Verhalten und mögliche autorisierte Richtlinienänderungen von Route und aktueller Unterstützung ab; ein PowerShell-Beispiel ist keine universelle Anleitung. Prüfen Sie bei Google Workspace reale Quoten, Routing und verfügbare Logs statt pauschaler Sperrannahmen.

SRS, erhaltene DKIM-Signaturen und ARC können zusammen helfen, garantieren aber keine zuverlässige Zustellung in jedem Fall. Prüfen Sie die erforderlichen Bausteine für Ihre Route. Oder wählen Sie ein direktes Postfach am benötigten Ziel und vermeiden Sie die zusätzliche Weiterleitungsstation.