Domain-E-Mail weiterleiten: Diagnose mit SRS und ARC

E-Mail-Weiterleitung für Domains reicht eine Nachricht nicht einfach durch: Der Server baut eine neue SMTP-Verbindung zum Ziel auf. Bleibt der ursprüngliche Envelope-Absender erhalten, kann diese neue Verbindung zu Authentifizierungsproblemen führen. Ob eine Unzustellbarkeitsmeldung sichtbar wird, hängt vom Zustellweg ab.

Ohne passende Authentifizierung kann die Weiterleitung bei Gmail im Spam landen oder abgelehnt werden, bei Yahoo auf eine 550-Ablehnung treffen und bei Microsoft 365 an Richtlinien scheitern. Die genaue Ursache erkennen Sie an Protokollen und Zustellmeldungen, nicht allein am fehlenden Eingang.

Dieser Leitfaden beschreibt drei Weiterleitungsansätze für 2026, typische Fehlercodes großer Anbieter und eine Diagnoseprüfung in weniger als zehn Minuten. Die vollständige Einrichtung finden Sie in unserem Leitfaden zur Einrichtung und Reparatur der E-Mail-Weiterleitung.

Warum Domain-Weiterleitung SPF scheitern lassen kann

Bei der Weiterleitung sendet Ihr Server auf SMTP-Ebene neu, während der Return-Path beziehungsweise Envelope-Absender weiterhin auf die ursprüngliche Domain verweisen kann. Prüft das Ziel deren SPF-Eintrag und ist Ihre IP nicht autorisiert, kann SPF scheitern. Bei DMARC p=reject ist eine Ablehnung möglich, wenn auch keine gültige, zum ursprünglichen From passende DKIM-Signatur vorhanden ist.

Ein typischer Fehlerablauf:

1. alice@bank.com sendet an info@yourdomain.com. Der SPF-Eintrag der Bank autorisiert ihre eigenen Mailserver.
2. Ihr Server stellt an you@gmail.com weiter zu. Gmail sieht die IP Ihres Servers, während der Return-Path weiterhin bank.com nennt.
3. Ihre IP steht nicht im SPF-Eintrag von bank.com. SPF kann deshalb scheitern.
4. Verändert Ihr Server signierte Inhalte, etwa durch einen Scan-Footer oder ein Betreffpräfix, kann auch DKIM scheitern. Ohne ausgerichtetes SPF oder DKIM scheitert DMARC; die Empfängerrichtlinie entscheidet über die Behandlung.

Eine Unzustellbarkeitsmeldung kann den ursprünglichen Absender erreichen oder in Protokollen auftauchen. Ihr Zielpostfach muss sie nicht sehen.

Catch-all-Weiterleitung kann das Problem verstärken. Mit weitergeleitetem Spam wird Ihre Weiterleitungs-IP verbunden. Das kann ihre Reputation bei Gmail beeinträchtigen und legitime Nachrichten später in den Spamordner lenken oder zu Ablehnungen führen. Dieser Verlauf ist nicht bei jeder Nachricht gleich.

Ob Weiterleitung grundsätzlich zu Ihrem Anwendungsfall passt, erläutert unser Vergleich der Vor- und Nachteile der Alias-Weiterleitung.

Die 3 Ansätze für sichere Domain-Weiterleitung

Diese drei Ansätze behandeln unterschiedliche Probleme. Welche Kombination sinnvoll ist, hängt vom Nachrichtenweg und vom Empfänger ab. Nicht jede Weiterleitung benötigt zwingend alle drei; insbesondere eine erhaltene, ausgerichtete DKIM-Signatur kann DMARC weiterhin bestehen lassen.

1. Sender Rewriting Scheme (SRS)

SRS ersetzt vor der Weiterleitung den Envelope-Absender durch eine Adresse der Weiterleiter-Domain. Dadurch prüft das Ziel SPF für diese Domain; bei korrekter Autorisierung kann die Prüfung bestehen. Die kodierte Adresse ermöglicht die Rückleitung von Unzustellbarkeitsmeldungen, sofern die SRS-Verarbeitung richtig eingerichtet ist.

Vor SRS:

MAIL FROM: <alice@bank.com>

Nach SRS:

MAIL FROM: <SRS0=hash=TT=bank.com=alice@forwarder.com>

Die Grenze: SRS kann SPF für den Envelope reparieren, stellt aber keine DMARC-Ausrichtung mit der ursprünglichen From-Domain her. DMARC kann weiterhin über erhaltenes, ausgerichtetes DKIM bestehen. Scheitert auch dieses, bietet SRS allein keinen Ersatz für die Ausrichtung.

2. Authenticated Received Chain (ARC)

ARC (RFC 8617) schützt eine Kette dokumentierter Authentifizierungsergebnisse über Zwischenstationen. Der Weiterleiter ergänzt drei Header, die seine Beobachtungen und den Nachrichtenstand kryptografisch absichern. Das garantiert nicht die Richtigkeit aller Angaben oder das Vertrauen des Empfängers.

ARC-Authentication-Results: i=1; forwarder.com; spf=pass; dkim=pass; dmarc=pass
ARC-Message-Signature: i=1; a=rsa-sha256; d=forwarder.com; ...
ARC-Seal: i=1; a=rsa-sha256; cv=none; d=forwarder.com; ...

Google und Microsoft können ARC-Ergebnisse vertrauenswürdiger Zwischenstationen berücksichtigen. Selbst bei einem DMARC-Fehler am letzten Hop können solche Informationen die lokale Zustellentscheidung beeinflussen. Eine gültige ARC-Kette erzwingt aber keine Annahme.

Die Einschränkung: Vertrauen hängt von der Bewertung des Empfängers ab. Eine neue Signatur-Domain oder IP erhält nicht automatisch Vertrauen; eine gute Reputation allein garantiert es ebenfalls nicht.

3. Unveränderte Durchleitung: DKIM erhalten

Auch ohne SRS oder ARC ist es wichtig, die ursprüngliche DKIM-Signatur zu erhalten. Vermeiden Sie angehängte Footer, Änderungen am Betreff und Inhaltsänderungen durch Scanner. DKIM signiert den kanonisierten Nachrichtentext und ausgewählte Header. Änderungen an signierten Daten können die Signatur brechen; nicht jede Byteänderung tut das. Je nach Kanonisierung bleiben bestimmte Änderungen an Leerraum ohne Wirkung; nicht signierte Header sind nicht unmittelbar von der Signatur abgedeckt.

Schwer erkennbare Weiterleitungsfehler entstehen häufig durch Nachrichtenänderungen. Ein Scanner hängt etwa einen Hinweis auf MailGuard an den Text. Das Versandprotokoll zeigt nicht unbedingt einen Fehler. Ein dkim=fail (body hash did not verify) im Authentication-Results-Header des Empfängers kann dann auf einen veränderten signierten Text hinweisen, sofern die Nachricht zur Prüfung verfügbar ist.

Unveränderte Durchleitung hilft, wenn eine gültige, ausgerichtete DKIM-Signatur den ganzen Weg übersteht. Scheitert SPF am neuen Hop und wird auch DKIM ungültig, fehlt eine ausgerichtete Authentifizierung für DMARC. ARC und die Empfängerrichtlinie können zusätzlich berücksichtigt werden.

Wie große Anbieter mit Weiterleitungsfehlern umgehen

Microsoft, Google und Yahoo können Authentifizierungsfehler, Reputation und Weiterleitungsrichtlinien unterschiedlich bewerten. Microsoft kann ausgehende automatische Weiterleitung durch eine Richtlinie verhindern; Gmail kann Nachrichten anders einsortieren und Yahoo beispielsweise mit 550 ablehnen. Der vollständige Fehlertext und die betroffene Station bestimmen, wo die Diagnose beginnt.

Microsoft 365 (Exchange Online)

Eine ausgehende Defender-Spamrichtlinie kann automatische externe Weiterleitung auf Mandantenebene sperren. Dann scheitert der Versand vor der Bewertung durch das externe Ziel. Prüfen Sie die wirksame Richtlinie für das betreffende Postfach.

Eine Meldung mit 5.7.520 kann zum ursprünglichen Absender gehen und im Zielpostfach fehlen. Prüfen Sie Nachrichtenverfolgung und den vollständigen Meldungstext, statt aus einem leeren Postfach auf die Ursache zu schließen.

Google Workspace / Gmail

Eine ausdrückliche Ablehnung kann so aussehen: 550-5.7.1 Unauthenticated email from domain.com is not accepted due to domain's DMARC policy. Bei p=reject ist sie möglich, wenn ausgerichtete Authentifizierung fehlt. Erhaltenes, ausgerichtetes DKIM kann DMARC trotz Weiterleitung bestehen lassen; SRS allein stellt diese Ausrichtung nicht her.

Auch Reputation spielt eine Rolle. Spam aus einer Catch-all-Weiterleitung kann die Bewertung Ihrer Weiterleitungs-IP über Tage oder Wochen verschlechtern. Nachrichten können im Spam landen oder abgelehnt werden. Es gibt dafür weder einen universellen Fehlercode noch einen garantierten lautlosen Verlust.

Yahoo / AOL

Bei Yahoo kann unzureichend authentifizierte Weiterleitung eine 550-Ablehnung auslösen. Betreffzusätze wie [FWD] oder [External] können DKIM brechen, wenn der Betreff signiert ist. Scheitert zugleich ausgerichtetes SPF, steigt das DMARC-Risiko. Das bedeutet aber keine sichere Ablehnung von 100% dieser Nachrichten; erhaltenes DKIM und lokale Richtlinien bleiben relevant.

Diagnose-Checkliste für die Weiterleitung

Prüfen Sie bei fehlgeschlagener Domain-Weiterleitung diese Punkte, bevor Sie Einstellungen ändern:

1. Lesen Sie den Authentication-Results-Header im Zielpostfach, etwa über „Original anzeigen“ in Gmail oder die Nachrichtenquelle in Outlook.

   Authentication-Results: mx.google.com;
     spf=fail (domain of bank.com does not designate 198.51.100.1 as permitted)
     dkim=fail (body hash did not verify)
     dmarc=fail (p=REJECT)

   spf=fail → Envelope-Domain, sendende IP und SRS-Konfiguration prüfen.
   dkim=fail (body hash) → signierten Inhalt und mögliche Änderungen unterwegs prüfen.
   Beide Fehler → Ausrichtung, weitere DKIM-Signaturen, ARC und Empfängerrichtlinie prüfen; eine Ablehnung ist nicht allein daraus garantiert.
2. Prüfen Sie Routingschleifen. 5.4.14 Hop count exceeded weist auf ein überschrittenes Hop-Limit hin, oft durch Rückleitung. Zeichnen Sie die ganze Kette auf: A→B→C→A ist ein typischer Auslöser.
3. Testen Sie Reply-To. Antworten Sie auf eine weitergeleitete Nachricht. Der Client nutzt normalerweise Reply-To, falls vorhanden, sonst From. Geht die Antwort an den Weiterleiter, prüfen Sie beide Header und die Client-Einstellungen.
4. Prüfen Sie alle nachrichtenverarbeitenden Komponenten. Spamfilter, Virenscanner, Mailinglisten und Phishing-Schutz können signierte Inhalte ändern. Untersuchen Sie den gesamten Weg; nicht jede Änderung bricht DKIM, und Protokolle zeigen die Ursache nicht immer deutlich.
5. Prüfen Sie das Catch-all-Volumen. Viel Spam über Ihre Weiterleitungs-IP kann die Gmail-Zustellung langfristig beeinträchtigen, auch wenn einzelne Nachrichten authentifiziert sind.

Falls Sie zwischen Weiterleitung und separatem Routing je Adresse abwägen, vergleichen Sie Domain-Aliase und Postfächer. Sie lösen unterschiedliche Probleme und bringen unterschiedliche Fehlerquellen mit.

Wie TrekMail die Weiterleitungsinfrastruktur behandelt

Auf einem selbst betriebenen Postfix können postsrsd für SRS, OpenARC für ARC, RSA-Schlüsselrotation und eine inhaltserhaltende Weiterleitung sinnvoll sein. Diese vier Bereiche können unabhängig voneinander fehlerhaft sein. Welche Komponenten benötigt werden, richtet sich nach Ihrer Architektur; ähnliche Symptome verlangen dennoch eine getrennte Prüfung.

Bei ARC und DKIM ist die Verarbeitungsreihenfolge wichtig. Eine zusätzliche DKIM-Signatur des Weiterleiters kann dessen Domain authentifizieren, ist aber keine allgemeine ARC-Pflicht und stellt die DMARC-Ausrichtung mit dem ursprünglichen From nicht automatisch wieder her. Erhalten Sie die ursprünglichen gültigen Signaturen und prüfen Sie ARC-Ergebnisse sowie zusätzliche DKIM-Signaturen getrennt. Fehlendes Neusignieren erklärt nicht pauschal jeden Zustellfehler.

Ob TrekMail in Ihrer aktuellen Umgebung OpenARC, zusätzliche DKIM-Signaturen und automatische SRS-Umschreibung auf den betreffenden Routen einsetzt, sollte anhand der aktuellen Einstellungen und empfangenen Header geprüft werden. Die Weiterleitung sollte keine Footer oder Betreffzusätze einfügen. Die Zieladresse stellen Sie in den Postfach-Weiterleitungseinstellungen ein; prüfen Sie dort auch die für Ihren Tarif verfügbaren Funktionen.

Die hier genannten Tarifwerte sind vor der Bestellung aktuell zu prüfen: Weiterleitung für Pro ($10/Monat) und Agency ($23.25/Monat), jeweils mit 14 Tagen kostenloser Testphase und erforderlicher Kreditkarte. Für Nano ($0, 10 Domains, eigener SMTP) und Starter ($3.50/Monat, 50 Domains) wird hier keine Weiterleitung angegeben. Maßgeblich ist der aktuelle Tarifvergleich auf trekmail.net/pricing.

Fazit

Zuverlässige E-Mail-Weiterleitung für Domains im Jahr 2026 braucht eine passende Kombination: SRS für den Envelope, ARC als geschützte Authentifizierungshistorie und einen Weg, der ursprüngliche DKIM-Signaturen erhält. Nicht alle Komponenten sind in jeder Architektur zwingend. Eine neue DKIM-Signatur des Weiterleiters ersetzt keine ursprüngliche DMARC-Ausrichtung und garantiert keine Zustellung.

Beginnen Sie mit dem Authentication-Results-Header. Er zeigt die Prüfungen der jeweiligen Station; zusammen mit Nachrichtenverfolgung und SMTP-Protokollen grenzt er Ursachen ein.

Wenn Sie Postfix nicht selbst betreiben möchten, hilft die Einrichtung professioneller Domain-E-Mail mit TrekMail. Planen Sie etwa 15 Minuten als Richtwert ein und prüfen Sie die aktuellen SRS-, ARC- und DKIM-Funktionen für Ihre Konfiguration.