E-Mail-Weiterleitung: Einrichtung und Fehlerbehebung (2026)

E-Mail-Weiterleitung gehört wahrscheinlich zu den ersten Funktionen, die Sie für eine eigene Domain einrichten. Und häufig ist sie auch die erste, die unbemerkt ausfällt.

Oberflächlich betrachtet ist der Vorgang simpel: Eine an info@yourdomain.com gesendete Nachricht wird an Ihr @gmail.com-Konto umgeleitet. In der Praxis ist eine Weiterleitung jedoch ein Vermittlungsvorgang, der direkt mit den zentralen Vertrauensmodellen des modernen Internets kollidiert: SPF, DKIM und DMARC. Bei einer fehlerhaften Konfiguration kommt die Nachricht nicht unbedingt mit einer auffälligen Fehlermeldung zurück. Sie verschwindet einfach.

Für einen Gründer kann eine defekte Weiterleitung bedeuten, dass E-Mails von Investoren verpasst werden. Für einen IT-Dienstleister, der 50 Kundendomains verwaltet, kann sie am Montagmorgen eine Welle von Supportanfragen auslösen.

Dieser Leitfaden erklärt, wie E-Mail-Weiterleitung auf Protokollebene tatsächlich funktioniert, warum sie auf vorhersehbare Weise scheitert und wie Sie eine Konfiguration aufbauen, die auch 2026 mit strengen DMARC-Richtlinien zurechtkommt.

Das Grundmodell: Warum E-Mail-Weiterleitung komplizierter ist, als sie wirkt

Bevor Sie eine defekte Weiterleitung reparieren können, müssen Sie verstehen, was auf der SMTP-Ebene geschieht. Es wird nicht einfach eine Notiz durchgereicht. Vielmehr wird ein Brief erneut versendet, und dieser Unterschied ist entscheidend.

Wenn Server A eine E-Mail an Ihren Server sendet, also Server B als Weiterleitungsserver, und Server B sie an das endgültige Ziel Server C übermittelt, ändert sich eine wesentliche Identität. Der Zielserver sieht die IP-Adresse von Server B und nicht die von Server A. Darin liegt die Ursache fast aller Weiterleitungsfehler.

Envelope und Header: die zwei Identitäten einer E-Mail

Jede E-Mail besitzt zwei getrennte Identitätsebenen, die durch eine Weiterleitung aus dem Gleichlauf geraten:

• Der Envelope (P1): Diese Ebene verwenden Mailserver für die technische Zustellung der Nachricht. Sie enthält den Return-Path und wird von SPF geprüft.
• Der Header (P2): Diese Ebene zeigt Ihr E-Mail-Programm als Absenderadresse an. DKIM und die Alignment-Prüfung von DMARC greifen darauf zurück.

Folgendes geht schief: Wenn Ihr Server eine Nachricht weiterleitet, baut er eine neue SMTP-Verbindung zum Ziel auf. SPF prüft die sendende IP-Adresse anhand des SPF-Eintrags des ursprünglichen Absenders, doch die IP-Adresse Ihres Weiterleitungsservers ist dort nicht autorisiert. SPF schlägt fehl. Verwendet der ursprüngliche Absender eine strenge DMARC-Richtlinie (p=reject) und haben Sie SRS nicht implementiert, weist der Zielserver die Nachricht vollständig ab.

Ein anschaulicher Vergleich: Alice schickt Bob einen Brief. Bob steckt Alices Brief in einen neuen Umschlag, trägt seine eigene Rücksendeadresse ein und schickt ihn an Carol. Carol fragt bei Alice nach, ob sie den Brief von Bobs Adresse gesendet hat. Alice verneint. Das ist ein DMARC-Fehler, auf den Carols Mailserver entsprechend reagiert.

Dieses Zusammenspiel von Envelope und Header ist die Grundlage. Jede in diesem Leitfaden beschriebene Lösung baut darauf auf.

E-Mail-Weiterleitung, Aliasse und Catch-all im Vergleich

Administratoren verwechseln diese drei Routingmethoden regelmäßig. Die falsche Wahl führt besonders schnell zu einer Meldung über verschwundene E-Mails, deren Diagnose drei Stunden dauert.

E-Mail-Weiterleitung

Eine an eine Adresse gesendete E-Mail wird an einen vollständig anderen Server zugestellt, zum Beispiel von contact@startup.com an founder@gmail.com. Dabei entsteht ein zusätzlicher Netzwerksprung. Authentifizierungsketten brechen, wenn sie nicht ausdrücklich berücksichtigt werden. Diese Variante eignet sich am besten, um mehrere Domains in einem Posteingang zusammenzuführen. Risiko: hoch ohne korrekte SRS- und ARC-Verarbeitung. Mehr zu den Abwägungen finden Sie in unserem ausführlichen Beitrag über die Kombination aus E-Mail-Alias und Weiterleitung.

E-Mail-Aliasse

Ein Alias ist ein weiterer Name für ein vorhandenes Postfach auf demselben Server. Nachrichten an support@company.com landen im selben Postfach wie Nachrichten an admin@company.com. Es gibt keinen zusätzlichen Netzwerksprung und keine Änderung der Authentifizierung. Das ist ideal, wenn eine Person mehrere Rollen übernimmt. Risiko: gering. Eine ausführlichere Entscheidungshilfe dazu, wann Aliasse nicht mehr genügen und ein eigenes Postfach erforderlich wird, bietet unser Vergleich von Alias und Postfach.

Catch-all (Wildcard-Routing)

Hierbei wird jede E-Mail angenommen, die an eine nicht vorhandene Adresse Ihrer Domain gesendet wird, also *@domain.com. Das kann Tippfehler oder einmalig verwendete Kampagnenadressen auffangen. Risiko: kritisch, wenn das Ziel direkt bei Gmail liegt. Jede Spamnachricht an Ihre Domain landet in Ihrem Posteingang, und Gmail wird Ihren Weiterleitungsserver irgendwann als Spamquelle einstufen. Wenn Sie Catch-all verwenden, sollten Sie die Funktion isolieren. Die Vor- und Nachteile behandeln wir vollständig in unserem Leitfaden zur Einrichtung geschäftlicher E-Mail.

Einrichtungsmuster: sinnvoll, problematisch oder unbrauchbar

Es gibt drei Möglichkeiten, eine E-Mail-Weiterleitung einzurichten. Zwei davon verursachen typischerweise Probleme. Eine ist für einen zuverlässigen Produktivbetrieb ausgelegt.

1. Routing beim Anbieter (der richtige Weg)

Dieses Routing erfolgt auf MTA-Ebene, bevor die Nachricht überhaupt ein Postfach erreicht. Der Server nimmt die E-Mail an, schreibt den Envelope mit SRS um und leitet sie sofort weiter. In diesem Modell ist keine kostenpflichtige Postfachlizenz erforderlich, und die Weiterleitung belegt üblicherweise keinen Postfachspeicher. SPF und ARC werden auf Infrastrukturebene verarbeitet.

Auf diesem Ansatz sollten Sie aufbauen. Die Weiterleitungsrouten von TrekMail funktionieren auf diese Weise: Sie legen das Ziel fest, während die Infrastruktur die Authentifizierungsheader verarbeitet. Die genauen Schritte finden Sie im Leitfaden zur Einrichtung der Postfachweiterleitung.

2. Postfachregeln (der alte Weg)

Sie richten ein vollständiges Benutzerkonto ein, bezahlen $6-$30/Monat für eine Lizenz, die Sie eigentlich nicht benötigen, melden sich an und erstellen eine Posteingangsregel: „Wenn eine Nachricht eintrifft, an X weiterleiten.“

In bestimmten Randfällen ist das sinnvoll: bedingte Weiterleitung, etwa „nur Rechnungen weiterleiten“, Audit-Anforderungen oder Situationen, in denen die Nachricht vor der Weiterleitung lokal gespeichert werden muss. In den meisten Konfigurationen bezahlen Sie jedoch einen Benutzerplatz nur für das Routing. Zudem bricht DMARC wie bei jeder anderen Weiterleitung, und Microsoft 365 kann automatische Weiterleitungen abhängig von Mandant und Richtlinie standardmäßig blockieren. Mehr dazu folgt im Abschnitt über Fehlerbilder.

3. Clientseitige Weiterleitung (vollständig vermeiden)

Hierbei handelt es sich um eine Regel in Outlook Desktop oder Apple Mail auf Ihrem lokalen Gerät. Ihr Laptop muss eingeschaltet, aktiv und mit dem Internet verbunden sein, damit die Weiterleitung erfolgt. Auf Reisen funktioniert sie nicht. Während eines Neustarts funktioniert sie nicht. Und sie funktioniert nicht um 2am, wenn die wichtige E-Mail eintrifft.

Für den Produktivbetrieb ist das in keinem Szenario die richtige Wahl. Wenn Sie derzeit darauf angewiesen sind, sollten Sie die Konfiguration jetzt korrigieren.

Checkliste für eine sichere Einrichtung

Bevor Sie eine Weiterleitungsroute aktiv schalten, führen Sie diese vier Prüfungen durch. Wird auch nur eine ausgelassen, wird sich das später bemerkbar machen.

1. Schleifentest

Stellen Sie sicher, dass die Zieladresse nicht zur Quelladresse zurückleitet. A→B→A ist eine Endlosschleife. Moderne Server erkennen das anhand von Hop-Limits und senden einen NDR mit 5.4.14 hop count exceeded. Zu diesem Zeitpunkt haben Sie Ihre Absenderreputation jedoch bereits belastet. Erfassen Sie deshalb alle Routen, bevor Sie live gehen.

2. Prüfung der Header

Senden Sie eine Testnachricht von einem externen Konto, etwa einem privaten Gmail- oder Yahoo-Konto oder einem anderen Konto außerhalb Ihrer Domain, an die weitergeleitete Adresse. Öffnen Sie am Ziel die vollständigen Nachrichtenheader und suchen Sie den Header Authentication-Results. Erwartet wird spf=pass aufgrund der SRS-Umschreibung oder dkim=pass. Wenn Sie dmarc=fail sehen, ist Ihre Weiterleitung nicht bereit für den Produktivbetrieb.

3. Reply-To-Test

Antworten Sie auf eine weitergeleitete Nachricht. Geht die Antwort an den ursprünglichen Absender oder an die Adresse Ihres Weiterleitungsservers? Sie muss den ursprünglichen Absender erreichen. Wenn sie an den Weiterleitungsserver geht, ist Ihre Envelope-Konfiguration falsch und erzeugt für alle Beteiligten einen verwirrenden Nachrichtenverlauf.

4. Prüfung der Richtlinie für ausgehende Nachrichten

Wenn Sie Microsoft 365 oder Google Workspace als Weiterleitungsziel verwenden, prüfen Sie in den Einstellungen des ausgehenden Spamfilters, ob automatische Weiterleitungen erlaubt sind. Bei M365 können sie abhängig von Mandant und Richtlinie standardmäßig blockiert sein. Bei einer falschen Konfiguration werden Ihre Weiterleitungen möglicherweise ohne Benachrichtigung des ursprünglichen Absenders verworfen.

Häufige Fehlerbilder

Wenn eine E-Mail-Weiterleitung ausfällt, geschieht dies fast immer auf eine dieser klar erkennbaren Arten. Wer das Muster kennt, spart sich eine Stunde zielloser Headeranalyse.

1. Stilles Verwerfen durch DMARC

Dies ist 2026 die häufigste Ursache für verschwundene E-Mails, und sie bleibt unsichtbar: kein NDR, kein Fehler, kein Hinweis. Die Nachricht kommt einfach nicht an.

Das Szenario: Eine Bank, ein Zahlungsdienstleister oder ein SaaS-Anbieter sendet eine E-Mail mit der strengen DMARC-Richtlinie p=reject an Ihre Domain. Sie leiten sie an Gmail weiter. Die IP-Adresse Ihres Weiterleitungsservers lässt SPF fehlschlagen. Ändert Ihr Server zusätzlich den Nachrichtentext, etwa durch einen Disclaimer, oder die Betreffzeile, etwa durch [External], bricht auch DKIM. SPF-Fehler + DKIM-Fehler = DMARC-Fehler. Gmail weist die Nachricht ab.

Die Lösung besteht darin, SRS auf dem Weiterleitungsserver zu implementieren, damit SPF besteht, und den Inhalt nicht zu verändern, damit DKIM intakt bleibt. Wenn Sie die Infrastruktur nicht kontrollieren können, benötigen Sie einen Weiterleitungsanbieter, der dies für Sie übernimmt. Wie DMARC-Fehler speziell in Weiterleitungsketten auftreten, erläutert unser Überblick über DMARC und sichere geschäftliche E-Mail ausführlicher.

2. Microsoft-Blockierung 550 5.7.520

Symptom: Der ursprüngliche Absender erhält einen NDR mit dem Code 550 5.7.520 Access denied, your organization does not allow external forwarding.

Der ausgehende Spamfilter von M365 tut damit genau das, wofür er vorgesehen ist: Er blockiert automatische Weiterleitungen an externe Adressen. Zur Behebung öffnen Sie das Microsoft Defender-Portal → Email & Collaboration → Policies & Rules → Threat policies → Anti-spam policies → Edit the outbound policy → Set "Automatic forwarding rules" to "On - forwarding is enabled."

Die Einstellung ist nicht intuitiv und bei Microsoft schwer zu finden. Der Fehlercode liefert jedoch eine präzise Diagnose: Wenn Sie ihn sehen, wissen Sie genau, wo Sie ansetzen müssen.

3. Abwesenheitsschleife

Benutzer A leitet an Benutzer B weiter. Benutzer B richtet eine automatische Antwort ein. Benutzer A schreibt Benutzer B eine E-Mail. Die automatische Antwort von Benutzer B geht an Benutzer A zurück. Der Server von Benutzer A leitet diese Antwort an Benutzer B weiter. Der Server von Benutzer B antwortet erneut.

Moderne Mailserver erkennen und stoppen dieses Verhalten anhand von Headern wie X-Loop und X-Auto-Response-Suppress. Bei älteren oder falsch konfigurierten Systemen können innerhalb weniger Minuten dennoch Tausende Nachrichten entstehen. Prüfen Sie deshalb beim Einrichten kontenübergreifender Weiterleitungen auch die automatischen Antworten.

4. DKIM-Bruch durch Inhaltsänderung

DKIM signiert einen kryptografischen Hash des Nachrichteninhalts. Sobald sich etwas im signierten Teil ändert, selbst wenn nur eine einzeilige Fußzeile ergänzt wird, ist die Signatur ungültig. Viele geschäftliche Mailsysteme hängen an jede ausgehende Nachricht einen rechtlichen Hinweis an. Wird dieser Disclaimer nach dem Erstellen der DKIM-Signatur ergänzt, ist die Signatur am Ziel ungültig.

Wenn Sie in den Headern einer weitergeleiteten Nachricht dkim=fail (body hash did not verify) sehen, ist dies fast immer die Ursache.

Diagnoseablauf: vom Symptom zur Lösung

Warum Weiterleitungen im Produktivbetrieb scheitern: SRS und ARC erklärt

Einfache Weiterleitungsregeln reichen für eine Produktivumgebung nicht aus. Sie benötigen eine Infrastruktur, die SRS und ARC versteht. Im Folgenden erfahren Sie genau, welche Aufgabe beide Verfahren erfüllen und warum beide wichtig sind.

SRS: Sender Rewriting Scheme

SRS behebt den SPF-Fehler, der durch den zusätzlichen Netzwerksprung entsteht. Ihr Weiterleitungsserver schreibt die Envelope-Absenderadresse um, sodass das Ziel SPF anhand Ihrer Domain statt anhand der Domain des ursprünglichen Absenders prüfen kann.

Vor SRS:

MAIL FROM: alice@bank.com

Nach der SRS-Umschreibung:

MAIL FROM: SRS0=hash=timestamp=bank.com=alice@forwarder.com

Der Zielserver führt die SPF-Prüfung für forwarder.com aus. Sie besteht, weil Ihr Server autorisiert ist. Unzustellbarkeitsnachrichten gelangen über die codierte Adresse weiterhin zu alice@bank.com zurück. Damit wird SPF erfüllt, ohne den Rücklaufpfad zu unterbrechen.

SRS ist unverzichtbar. Ohne SRS scheitert jede weitergeleitete Nachricht eines Absenders mit strengem SPF an der Authentifizierung am Ziel. Eine vollständige Erklärung zur Funktionsweise von SRS in Weiterleitungsketten finden Sie in unserem ausführlichen Leitfaden zur Einrichtung von E-Mail mit Ihrer Domain. Wenn Sie speziell an einen Gmail-Posteingang weiterleiten, lesen Sie unsere Schritt-für-Schritt-Anleitung, wie Sie Domain-E-Mail sicher an Gmail weiterleiten und dabei SRS sowie „Senden als“ konfigurieren.

ARC: Authenticated Received Chain

SRS behebt SPF, löst aber das DMARC-Alignment nicht vollständig. Hier kommt ARC ins Spiel. Mit ARC kann Ihr Weiterleitungsserver die Nachricht kryptografisch signieren und damit bestätigen: „Ich habe die Authentifizierung dieser Nachricht beim Empfang geprüft, und sie war gültig.“

Google und Microsoft berücksichtigen beide ARC-Siegel von vertrauenswürdigen Zwischenservern. Ist ein vertrauenswürdiges ARC-Siegel vorhanden, können diese Anbieter die Nachricht auch dann annehmen, wenn die ursprünglichen SPF- oder DMARC-Prüfungen aufgrund des Weiterleitungssprungs fehlschlagen würden. ARC ist gewissermaßen ein lückenloser Herkunftsnachweis für die E-Mail-Authentifizierung.

ARC ist in RFC 8617 definiert und bildet den aktuellen Standard, um Authentifizierung bei legitimen E-Mail-Weiterleitungen zu bewahren. Ohne ARC kann eine strenge DMARC-Richtlinie mit p=reject des ursprünglichen Absenders Ihre weitergeleiteten Nachrichten bei großen Anbietern blockieren, selbst wenn SRS eingerichtet ist.

Die Gefahrenzone bei Catch-all

Weiterleitungen werden häufig mit einer Catch-all-Konfiguration kombiniert, und diese Kombination verlangt eine besondere Warnung. Wenn Sie eine Catch-all-Wildcard auf Gmail richten, landet jede Spamnachricht an zufällige Adressen Ihrer Domain bei Gmail. Gmail wiederum sieht Ihren Weiterleitungsserver als Quelle. Dadurch sammeln sich schnell Spambeschwerden gegen Ihre IP-Adresse, was auch die Absenderreputation Ihrer Domain für legitime Nachrichten beeinträchtigt.

Wenn Sie Catch-all benötigen, isolieren Sie die Funktion in einem eigenen Postfach mit serverseitigem Spamfilter und leiten Sie sie nicht an einen persönlichen Posteingang weiter. Das vollständige Einrichtungsmuster finden Sie in unserem Leitfaden zur Einrichtung von E-Mail auf Ihrer Domain.

Die Rolle von TrekMail

Früher mussten Sie für E-Mail-Weiterleitungen entweder einen eigenen MTA mit SRS- und ARC-Unterstützung betreiben oder pro Benutzer Lizenzgebühren zahlen, nur um Nachrichten zu routen. Für Betreiber mit mehr als einigen wenigen Domains war keine dieser Optionen sinnvoll.

Sie zahlen Google oder Microsoft $6/user/month, benötigen 10 Weiterleitungsadressen und bezahlen möglicherweise für 10 ungenutzte Benutzerplätze. Alternativ stoßen Sie an Aliaslimits und müssen Umgehungslösungen verwalten. Das ist eine unnötige Abgabe auf simples Routing.

TrekMail setzt dagegen auf Hosting zum Pauschaltarif. Sie bezahlen einen Tarif und keine Benutzerplätze. Weiterleitungsrouten, Aliasse und Catch-all-Konfiguration sind laut Tarifbeschreibung enthalten. Sie werden auf Serverebene verwaltet, und SRS-konforme Weiterleitung ist in die Infrastruktur integriert. Sie legen die Route fest, während die Plattform Authentifizierungsheader, TLS-Durchsetzung und Zustellung verarbeitet. Im beschriebenen Tarifmodell fallen keine Gebühren pro Adresse an, und Sie müssen nicht mit Richtlinien für ausgehenden Spam ringen, um eine grundlegende Funktion nutzen zu können.

Für einen allein arbeitenden Gründer kann das bedeuten, hello@yourdomain.com bei passender Konfiguration in weniger als fünf Minuten zuverlässig zu Gmail zu routen, ohne einen vollständigen Mailserver einzurichten. Für ein Team können Routingänderungen im Dashboard erfolgen, sodass keine DNS-Archäologie nötig ist. Für eine Agentur mit 100+ Kundendomains lassen sich Weiterleitungsregeln zentral verwalten und einheitlich anwenden, was Authentifizierungsfehler und daraus entstehende Supporteskalationen am Freitag um 6pm reduzieren kann.

Laut der zum Zeitpunkt des Beitrags geltenden Tarifübersicht umfasst der Pro-Tarif ($10/month, oder $8/month bei jährlicher Zahlung) externes Catch-all und Postfachweiterleitung. Der Agency-Tarif ($29/month) ist für 1,000+ Domains ausgelegt und bietet API-Zugriff zur gebündelten Verwaltung von Routen. Für die kostenpflichtigen Tarife wird eine 14-day free trial genannt (Karte erforderlich).

Wie TrekMail Weiterleitungen in jeder Größenordnung handhabt, erfahren Sie auf trekmail.net.

Fazit

E-Mail-Weiterleitung ist keine Funktion, die man einmal einrichtet und dann vergessen kann. Sie ist ein aktiver Routingvorgang, der die grundlegenden Authentifizierungsmodelle des Internets berührt. Die Fehler sind vorhersehbar: SPF bricht durch den Wechsel der IP-Adresse, DKIM durch Inhaltsänderungen und DMARC durch fehlendes Alignment. Sobald Sie die Vorgänge auf Protokollebene verstehen, lassen sich diese Probleme beheben.

Die praktischen Erkenntnisse: Verwenden Sie serverseitige Weiterleitung mit SRS und ARC und niemals clientseitige Regeln. Prüfen Sie die Header vor dem Produktivstart. Achten Sie auf die Sperre durch die ausgehende M365-Richtlinie. Isolieren Sie Catch-all. Und wenn Sie E-Mail-Weiterleitungen für mehrere Domains verwalten, zahlen Sie nicht pro Benutzerplatz, nur um Nachrichten zu routen.

Mit der richtigen zugrunde liegenden Infrastruktur kann E-Mail-Weiterleitung zuverlässig funktionieren. Bei einer falschen Einrichtung verschwinden Ihre wichtigsten Nachrichten dagegen möglicherweise spurlos. Die Entscheidung ist nicht kompliziert.