E-Mail-Weiterleitung funktioniert nicht: Diagnose in 6 Schritten

Die E-Mail-Weiterleitung funktioniert nicht. Nachrichten fehlen, der Absender sieht keinen Rückläufer und die Regel scheint in allen geprüften Oberflächen richtig zu sein. Ohne sichtbare Fehlermeldung ist die Suche besonders schwierig.

Wenn E-Mail-Weiterleitung nicht funktioniert, kommen fehlerhafte Regeln ebenso wie Authentifizierung und Empfängerrichtlinien infrage. Beim Weiterleiten sendet ein anderer Server für den ursprünglichen Absender; dadurch kann SPF fehlschlagen. Ob eine Nachricht abgelehnt, zurückgestellt, als Spam einsortiert oder angenommen wird, hängt auch von DKIM, DMARC und Empfängerentscheidungen ab. Eine Ablehnung kann innerhalb von Sekunden erfolgen, doch fehlende Benachrichtigungen allein beweisen keine stille Löschung.

Gehen Sie diese Liste durch, bevor Sie DNS ändern. Die Protokolldetails zu SPF sowie SRS und ARC erklärt der vollständige Leitfaden zur Einrichtung und Reparatur von Weiterleitungen. Hier geht es um die unmittelbare Eingrenzung eines aktuellen Fehlers.

Warum manchmal keine Fehlermeldung sichtbar ist

Ein Fehler am Empfänger kann anders gemeldet werden als einer am Weiterleitungsserver. Eine SMTP-Ablehnung kann einen Rückläufer auslösen; nach Annahme kann eine Nachricht gefiltert werden, und eine Fehlermeldung kann beim Weiterleiter oder einer umgeschriebenen Rückadresse landen. Keine sichtbare Nachricht bedeutet deshalb nicht automatisch, dass die Zustellung erfolgreich war oder die Nachricht innerhalb von Sekunden gelöscht wurde.

Header, Rückläufer und Logs helfen, wenn die aktive Regel keinen Hinweis liefert. Die folgenden sechs Prüfbereiche führen von leicht zugänglichen Informationen zur technischen Untersuchung. Wer vor dem Spamordner sofort DNS bearbeitet, kann beispielsweise 45 Minuten an der falschen Stelle verlieren.

60 Sekunden Eingrenzung: erst das Fehlerbild benennen

Nutzen Sie zunächst 60 Sekunden, um das Verhalten einzuordnen, statt sofort Einstellungen zu ändern. Die vier folgenden Muster geben Hinweise, aber keine allein ausreichende Diagnose.

Prüfliste für fehlerhafte E-Mail-Weiterleitung

Schritt 1 und Schritt 2 liefern leicht zugängliche Hinweise aus Spamordner und Rückläufer. Prüfen Sie zuerst, statt beispielsweise 45 Minuten unnötig DNS zu ändern. Folgen Sie den Schritten, bis die Ursache ausreichend eingegrenzt ist.

Schritt 1: Spamordner des Ziels prüfen

Priorität: früh prüfen  |  Symptom: keine Mail, kein Rückläufer

Eine fehlende Nachricht kann im Zielspamordner liegen. Weiterleitung verändert den für SPF geprüften Versandweg: Bei client@gmail.com an you@outlook.com sieht Outlook möglicherweise eine Weiterleiter-IP, die der ursprüngliche SPF-Eintrag nicht autorisiert. Das kann die Bewertung beeinflussen, führt aber nicht zwangsläufig zu Spam; eine erhaltene, ausgerichtete DKIM-Signatur und weitere Empfängersignale zählen ebenfalls.

Aktion: Im endgültigen Zielpostfach Junk oder Spam prüfen.

Maßnahme: Eine berechtigte Nachricht gegebenenfalls als “Kein Junk” markieren. Sender Rewriting Scheme (SRS) schreibt den Umschlagabsender um und kann SPF für die Weiterleiterdomain ermöglichen. Das garantiert weder ursprüngliche From-Ausrichtung noch spätere Zustellung; fehlendes SRS macht nicht jede Weiterleitung an Gmail, Yahoo oder Outlook unmöglich.

Schritt 2: Rückläufer und NDR-Codes lesen

Priorität: bei vorhandenem Rückläufer  |  Symptom: Absender erhält “Unzustellbar”

Ein SMTP-Code mit vollständigem Fehlertext hilft bei der Diagnose. Lesen Sie ihn samt betroffenem Server und Adresse; die Betreffzeile allein reicht nicht. Ähnliche Codes können unterschiedliche Konfigurations- oder Richtlinienursachen haben.

Schritt 3: DMARC-Ausrichtung prüfen

Relevanz: auch bei Gmail, Yahoo und Outlook  |  Symptom: fehlende Nachricht oder Ablehnung

DMARC kann Weiterleitungen beeinflussen, ist aber nicht stets die Ursache. Bei p=reject scheitert einfache Weiterleitung nicht in 100% der Fälle ohne SRS oder ARC: Eine unverändert erhaltene, erfolgreich geprüfte und zum sichtbaren From ausgerichtete DKIM-Signatur kann DMARC bestehen lassen. DMARC braucht ausgerichtetes SPF oder DKIM, nicht zwingend beide; die Empfängerpolitik bestimmt die Verarbeitung.

Die DMARC-Richtlinie der ursprünglichen Domain lässt sich im Terminal abfragen:

dig _dmarc.originalsender.com TXT +short

Ein Ergebnis p=reject allein beweist keine konkrete Ablehnung. Prüfen Sie erfolgreiches SPF und dessen Ausrichtung zum sichtbaren From sowie DKIM-Erfolg und Signierdomain. Der Umschlagabsender muss nicht der DKIM-Domain entsprechen; die Domain mindestens einer erfolgreichen Methode muss nach den geltenden DMARC-Regeln zur From-Domain ausgerichtet sein.

Maßnahme: Geeignete serverseitige Weiterleitung kann SRS beim Relay und ARC (Authenticated Received Chain) unterstützen. ARC bewahrt verifizierbare vorherige Authentifizierungsergebnisse; ob der Empfänger der Kette und dem Vermittler vertraut, bleibt seine Entscheidung. Gmail-Filter und Outlook-Regeln werden je nach Produkt unterschiedlich ausgeführt; cPanel-Weiterleitungen sind serverseitig. Prüfen Sie den tatsächlichen MTA und dessen Unterstützung für SRS und ARC.

Schritt 4: Microsoft-365-Richtlinien für externe Weiterleitung prüfen

Relevanz: bei Office 365 und passendem Code  |  Symptom: NDR 550 5.7.520

Microsoft 365 kann automatische externe Weiterleitung absichtlich durch Richtlinien sperren. Das begrenzt unter anderem Datenabfluss aus kompromittierten Konten. Eine Benutzerregel setzt solche Organisationskontrollen nicht außer Kraft. Nur berechtigte Administratoren sollten nach Prüfung eine möglichst eng begrenzte Ausnahme genehmigen; nicht pauschal für den ganzen Mandanten freischalten.

1. Mit berechtigtem Konto Microsoft 365 Defender öffnen; aktuelle Oberfläche prüfen.
2. Zu E-Mail & Zusammenarbeit → Richtlinien & Regeln → Bedrohungsrichtlinien → Antispam wechseln.
3. Die wirksame Richtlinie prüfen, einschließlich ausgehender Antispamrichtlinie (Standard); für eine Ausnahme vorzugsweise einen eng begrenzten Umfang wählen.
4. Schutzeinstellungen bearbeiten nur mit erforderlichen Rechten und Freigabe.
5. Regeln für automatische Weiterleitung auf Ein: Weiterleitung aktiviert nur im genehmigten Umfang setzen und weitere Kontrollen beachten.

Ist die Option gesperrt, können Rechte oder Organisationsvorgaben fehlen. Benutzeroptionen umgehen die Sperre nicht. Lassen Sie den zuständigen Mandantenadministrator die geltenden Regeln prüfen, ohne die Schutzpolitik eigenmächtig zu lockern.

Schritt 5: Routingschleifen suchen

Relevanz: bei Schleifenhinweisen  |  Symptom: Fehler 5.4.14 oder mehrere Kopien

Eine Schleife entsteht, wenn Server A an B weiterleitet und B zurück an A. Die Nachricht kann weitergereicht werden, bis ein Hop-Limit oder andere Schleifenkontrolle greift. Ein mögliches Muster ist catch-all von Domain A nach B mit einer Rückregel für bestimmte Adressen.

Prüfen Sie Header verzögerter oder doppelter Nachrichten auf:

• X-Loop
• X-MS-Exchange-Inbox-Rules-Loop
• Delivered-To mehrfach mit derselben Adresse.

Der Leitfaden zum Domain-catch-all erklärt das Routing. Jede Weiterleitung sollte einen dokumentierten Weg zu einem endgültigen Postfach haben. Weitere Aliase oder Relays sind nicht grundsätzlich verboten, müssen aber schleifenfrei und geprüft sein.

Schritt 6: Gmail-Zielbestätigung prüfen

Relevanz: bei noch inaktiver Regel  |  Symptom: Regel vorhanden, keine Weiterleitung

Bei privatem Gmail kann eine fehlende Zielbestätigung die Einrichtung verhindern. Google verlangt für diese Weiterleitungsfunktion die Bestätigung der Zieladresse. Prüfen Sie danach auch, ob Weiterleitung oder ein passender Filter tatsächlich aktiviert ist.

Aktion: Im Zielpostfach die Bestätigung von “Gmail Team” suchen, gegebenenfalls im Spamordner. Nur eine selbst veranlasste und geprüfte Anfrage bestätigen. Bei fehlender oder abgelaufener Nachricht unter Gmail-Einstellungen → Weiterleitung und POP/IMAP erneut anfordern und die Weiterleitungsoption kontrollieren.

Header für die Weiterleitungsdiagnose lesen

Kommt eine Nachricht im Spam an, wurde sie zugestellt, aber ihre Einstufung kann viele Ursachen haben. Authentication-Results liefert Authentifizierungsergebnisse des jeweiligen prüfenden Servers, nicht den vollständigen Grund jedes Weiterleitungsfehlers. Verwenden Sie vertrauenswürdige Ergebnisse zusammen mit Route und Logs.

Header anzeigen:

• Gmail: Nachricht öffnen → Dreipunktmenü → “Original anzeigen”
• Outlook: Datei → Eigenschaften → Internetkopfzeilen; aktuelle Produktversion beachten.

Illustratives Beispiel mit SRS und ARC; die vereinfachten Headerangaben sind keine vollständige Referenzsyntax:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@sender.com;
  spf=pass (google.com: domain of SRS0=ABCD=XY=sender.com@forwarder.com
            designates 1.2.3.4 as permitted sender)
  dmarc=pass (p=REJECT) dis=NONE header.from=sender.com
  arc=pass (i=1 spf=pass dkim=pass)

SRS0= in Return-Path kann eine SRS-Umschreibung erkennen lassen, beweist allein aber keine korrekte Verarbeitung oder From-Ausrichtung. Sein Fehlen beweist weder fehlende Umschreibung noch unvermeidbares DMARC-Scheitern. Prüfen Sie die tatsächliche Route und Authentifizierung. Googles Anforderungen seit 2024 betreffen bestimmte Versandkontexte und sind kein Beleg für eine einheitliche Richtlinie aller Geschäftsdomains.

Wenn Weiterleitungsprobleme das Geschäft betreffen

Eine fehlende Kundennachricht, ein Vertrag oder eine Supportanfrage kann unbemerkt bleiben, bis jemand nachfragt. Dokumentieren Sie wichtige Zustellwege und prüfen Sie Fehlerhinweise, statt aus fehlenden Rückläufern auf Erfolg zu schließen.

Einmalige manuelle Fehlersuche wird bei vielen Domains aufwendig. Neue Postfächer und geänderte Absenderrichtlinien können weitere Prüfungen verlangen. Google Postmaster Tools liefert je nach Berechtigung, Volumen und verfügbarer Datenbasis aggregierte Hinweise für Gmail, nicht vollständige Echtzeitdaten jeder Weiterleitung. Authentifizierungsergebnisse und tatsächliche Spam-Beschwerden sind unterschiedliche Signale, die für die Zustellanalyse getrennt geprüft werden sollten.

Wiederkehrende Ursachen statt nur Einzelfehler bearbeiten

Bei wiederkehrenden Problemen lohnt geeignete Infrastruktur mit geprüfter SRS- und ARC-Unterstützung. Das kann Authentifizierungsprobleme reduzieren, ersetzt aber weder laufende Überwachung noch spätere Fehlersuche.

Regelbasierter Ansatz: Weiterleitungen in Gmail oder cPanel einrichten, tatsächliche Serververarbeitung prüfen, Authentifizierung je Domain untersuchen und M365-Richtlinien kontrollieren.

TrekMail-Modell: Route im Dashboard festlegen und verfügbare SRS-Umschreibung sowie ARC-Verarbeitung am MTA prüfen. Die Annahme bleibt vom Empfänger abhängig.

TrekMail beschreibt Weiterleitung auf Postfix-Ebene mit SRS-Umschreibung und ARC-Verarbeitung vor erneuter Übermittlung. Prüfen Sie die aktuell eingesetzte Umsetzung, Signaturerhalt und Ergebnisse beim Empfänger. ARC bewahrt vorherige Authentifizierungsergebnisse, ersetzt aber keine ursprüngliche DKIM-Signatur und garantiert weder deren Erhalt noch Annahme durch Gmail, Outlook oder Yahoo.

Bei Dutzenden Kundendomains kann zentrale Konfiguration Verwaltung vereinfachen. Statt beispielsweise 30 Oberflächen einzeln zu bedienen, lassen sich verfügbare Routen zentral pflegen; ihre Wirkung muss trotzdem je Domain geprüft werden. Der Leitfaden zur Kunden-E-Mail-Verwaltung behandelt mehrdomainfähiges Routing und A→B→A-Schleifen aus Schritt 5.

Historische Preisbeispiele nennen Pro für $10 pro Monat mit 100 Domains und 50GB sowie Agency für $23.25 pro Monat mit 1,000+ Domains. Genannt wird eine 14-tägige Testphase. Prüfen Sie heutige Preise, Limits, Kartenpflicht, Testrechte und Verfügbarkeit von ARC und SRS, bevor Sie planen: Pläne auf trekmail.net/pricing vergleichen.

Wiederkehrende Weiterleitungsprobleme verdienen überprüfte Betriebsabläufe. Prüfen Sie Infrastruktur mit geeigneter SRS- und ARC-Unterstützung.