E-Mail-Weiterleitung über Aliasse: Risiken und Lösungen

Sie haben eine E-Mail-Weiterleitung über einen Alias eingerichtet: contact@yourdomain.com verweist auf Ihr Gmail-Konto. Monatelang funktioniert alles. Dann schreibt ein Kunde wegen eines unterschriebenen Vertrags. Die Nachricht kommt bei Ihnen nicht an. Erst drei Wochen später erfahren Sie davon, als der Auftrag bereits verloren ist.

Bei Ihnen erscheint weder eine Fehlermeldung noch ein Eintrag im Spamordner. Nur eine fehlende Nachricht und eine verpasste Gelegenheit.

So kann sich die Kombination aus Alias und Weiterleitung auswirken, wenn strenge DMARC-Richtlinien greifen. Solche Fehler können für den Empfänger unbemerkt bleiben. Wer die Abläufe auf Protokollebene versteht, kann die Risiken gezielt reduzieren. Dieser Leitfaden erklärt die Fehlerstellen, nennt konkrete Fehlercodes für Ihre Protokolle und beschreibt zwei Verfahren, die die Authentifizierung weitergeleiteter Nachrichten unterstützen.

Für die Grundlagen beginnen Sie mit dem Leitfaden zur Einrichtung und Fehlerbehebung bei E-Mail-Weiterleitungen. Dieser Artikel behandelt die möglichen Fehler.

Was eine E-Mail-Weiterleitung über einen Alias tatsächlich macht

Ein E-Mail-Alias ist eine Routingregel ohne eigenen Posteingang, eigene Anmeldung oder eigene Speicherquote. Wenn jemand an sales@yourdomain.com schreibt, nimmt Ihr Mailserver die Nachricht entgegen und leitet sie an ein anderes Ziel weiter, häufig ein privates Gmail- oder Outlook-Konto. Für Funktionsadressen kleiner Unternehmen ist das eine verbreitete pragmatische Lösung. Bei externer Weiterleitung können allerdings Nachrichten verloren gehen, ohne dass der Empfänger es bemerkt.

Die externe Alias-Weiterleitung öffnet für eingehende Nachrichten eine neue SMTP-Verbindung zum Ziel. Dieser zusätzliche Übertragungsschritt kann Probleme verursachen: Ihr Server übermittelt eine Nachricht, die er nicht selbst erstellt hat, und muss mit den vorhandenen Authentifizierungsinformationen umgehen.

Die zwei Ebenen einer E-Mail

Jede E-Mail hat zwei getrennte Ebenen, die im Alltag kaum auffallen. Ihr Unterschied erklärt, warum Weiterleitungen die Authentifizierung beeinträchtigen können.

Wenn client@bank.com an Ihren Alias sales@yourdomain.com schreibt, versendet der Server von bank.com die Nachricht. Im Beispiel besteht SPF die Prüfung, weil bank.com seine eigenen Versand-IP-Adressen autorisiert hat.

Wenn Ihr Server die Nachricht an founder@gmail.com weiterleitet, öffnet er eine neue SMTP-Verbindung. Der verbindende Server ist nun Ihrer. Ohne Umschreibung bleibt der Envelope-Absender unverändert; im Header steht weiterhin client@bank.com.

Gmail prüft SPF für bank.com anhand der IP-Adresse Ihres Servers, die bank.com nicht autorisiert hat. SPF schlägt fehl. Steht im DMARC-Eintrag von bank.com p=reject und besteht auch keine passende DKIM-Prüfung, kann Gmail die Nachricht gemäß seiner Empfangsrichtlinie ablehnen. Das bedeutet nicht zwingend sofortiges Löschen ohne Rückmeldung: Eine Fehlermeldung kann den ursprünglichen Absender erreichen, während Sie als Alias-Empfänger nichts erfahren.

Drei Fehlerarten bei der Alias-Weiterleitung

Weiterleitungen können auf verschiedenen Ebenen scheitern. Jede Fehlerart hat eigene Symptome und erfordert andere Maßnahmen.

1. SPF-Fehler

SPF prüft, ob die IP-Adresse der SMTP-Verbindung durch den DNS-Eintrag der Domain von MAIL FROM beziehungsweise HELO autorisiert ist. Beim Weiterleiten sieht das Ziel Ihre IP statt der ursprünglichen Versand-IP. Bleibt der ursprüngliche Envelope-Absender erhalten und ist Ihre IP dort nicht autorisiert, schlägt SPF am Ziel fehl. Damit beginnt das Authentifizierungsproblem.

2. DMARC-Ablehnung

DMARC verlangt, dass entweder SPF oder DKIM besteht und zur Domain im From:-Header passt. Im beschriebenen Szenario ist SPF bereits fehlgeschlagen. Werden unterwegs signierte Inhalte verändert, etwa durch angehängte Fußzeilen oder Änderungen signierter Header, kann auch die ursprüngliche DKIM-Signatur ungültig werden. Besteht keine ausgerichtete Authentifizierung mehr, kann der Empfänger die DMARC-Richtlinie anwenden: p=quarantine empfiehlt Quarantäne, häufig den Spamordner; p=reject empfiehlt die Ablehnung.

3. Unbemerkter Nachrichtenverlust

Der ungünstigste Fall: Das Ziel verwirft die Nachricht, ohne einen NDR, also einen Unzustellbarkeitsbericht, zurückzusenden. Der ursprüngliche Absender erhält keine Fehlermeldung, und Ihr Posteingang bleibt leer. Dieses Verhalten hängt vom Empfangssystem ab. Für Sie können solche Fehler jedenfalls unsichtbar bleiben, weshalb eine Weiterleitung lange zuverlässig wirkt, bis eine wichtige Nachricht fehlt.

Fehlercodes für die Suche in Ihren SMTP-Protokollen

Wenn weitergeleitete Nachrichten fehlen, prüfen Sie die SMTP-Protokolle oder bitten Sie Ihren Hoster um NDR-Daten. Diese drei Codes können auf Probleme mit Weiterleitungen hinweisen.

Microsoft-365-Sperre (5.7.520)

Microsoft Exchange Online kann automatische externe Weiterleitungen aufgrund der mandantenweiten Sicherheitsrichtlinien blockieren. Die übliche Standardeinstellung soll unbefugten Datenabfluss verhindern, betrifft aber auch legitime Weiterleitungen. Prüfen Sie die aktuelle Konfiguration Ihres Mandanten.

550 5.7.520 Access denied, Your organization does not allow external forwarding.

Maßnahme: Prüfen Sie im Microsoft-365-Defender-Portal die ausgehende Spamfilterrichtlinie und erlauben Sie externe Weiterleitungen nur für berechtigte Fälle. Auch Umleitungsregeln müssen die geltenden Richtlinien erfüllen; sie sind kein verlässlicher Weg, eine Sicherheitssperre zu umgehen.

Routingschleife (5.4.14 / 5.4.6)

Eine Schleife entsteht beispielsweise, wenn zwei Aliasse aufeinander verweisen oder ein Catch-all an ein Ziel weiterleitet, das wiederum Nachrichten an Ihre Domain zurückschickt.

554 5.4.14 Hop count exceeded - possible mail loop

Maßnahme: Prüfen Sie Ihre Transportregeln. Ein typisches Risiko ist ein Catch-all für *@yourdomain.com, dessen Ziel auf sämtliche eingehenden Nachrichten automatisch antwortet. Zusammen mit ungünstigen Rückleitungen kann daraus wiederholter Nachrichtenverkehr entstehen; eine automatische Antwort allein ist nicht unbedingt eine Transportschleife.

DMARC-Authentifizierungsfehler (550 5.7.1)

Der Zielserver hat die weitergeleitete Nachricht wegen fehlender, zur Absenderdomain passender DMARC-Authentifizierung abgelehnt. Die Weiterleitung kann dafür verantwortlich sein.

550-5.7.1 Unauthenticated email from bank.com is not accepted due to domain's DMARC policy.

Dieser Fehler kann bei einer durch Weiterleitung beeinträchtigten DMARC-Prüfung auftreten, beweist aber allein nicht die Ursache. Prüfen Sie Header und Protokolle, SRS und ARC auf dem Mailserver sowie die ursprüngliche DKIM-Signatur und relevante DNS-Einträge. Ein einzelner DNS-Eintrag ist keine universelle Lösung.

Die Maßnahmen: SRS und ARC

Eine lokale Freigabeliste hebt die Richtlinie des Zielservers nicht auf. Dieser berücksichtigt die veröffentlichte DMARC-Richtlinie des ursprünglichen Absenders und seine eigenen Regeln. SRS und ARC sind ergänzende Verfahren auf MTA-Ebene, also im Mail Transfer Agent, die Weiterleitungen unterstützen können. Bei gehosteter E-Mail muss Ihr Anbieter sie implementieren; eine Zustellgarantie bieten sie nicht.

SRS (Sender Rewriting Scheme)

SRS schreibt den Envelope-Absender, der im Return-Path abgebildet wird, vor der Weiterleitung auf Ihre Domain um. Die SPF-Prüfung am Ziel kann dann bestehen, wenn Ihr Server im SPF-Eintrag dieser Domain korrekt autorisiert ist.

Ohne SRS:
Envelope From: client@bank.com
Versand-IP: Ihr Weiterleitungsserver
SPF-Ergebnis im Beispiel: FAIL, Ihre IP steht nicht im Eintrag von bank.com

Mit SRS:
Envelope From: SRS0=Hash=TT=bank.com=client@yourdomain.com
Versand-IP: Ihr Weiterleitungsserver
SPF-Ergebnis im Beispiel: PASS, Ihre IP ist für yourdomain.com autorisiert

SRS nimmt außerdem einen Hash und einen Zeitstempel in die umgeschriebene Adresse auf. Die Prüfung dieser Angaben und eine begrenzte Gültigkeitsdauer, häufig einige Tage, helfen, missbräuchliche Wiederverwendung zu begrenzen. Der Schutz hängt von der Implementierung ab und schließt Missbrauch nicht vollständig aus.

ARC (Authenticated Received Chain)

SRS kann SPF am Ziel ermöglichen, stellt aber den DMARC-Domainabgleich für SPF nicht wieder her. DMARC vergleicht die Domain im From:-Header (bank.com) mit den Authentifizierungsergebnissen. Nach SRS enthält der Envelope yourdomain.com, während im From:-Header weiterhin bank.com steht. Diese Domains passen nicht zusammen. Der SPF-Domainabgleich für DMARC scheitert; eine gültige, passende DKIM-Signatur kann DMARC dennoch bestehen lassen.

ARC, definiert in RFC 8617, ergänzt eine kryptografisch überprüfbare Kette von Authentifizierungsinformationen. Ihr Server versiegelt die Ergebnisse, die beim Empfang vorlagen, und signiert den ARC-Satz vor der Weitergabe. Er dokumentiert damit beispielsweise, dass SPF und DKIM bei ihm bestanden haben, sofern das tatsächlich der Fall war.

Gmail und Outlook können ARC-Siegel vertrauenswürdiger Weiterleiter bei ihrer Entscheidung berücksichtigen. Sie prüfen die ARC-Kette und können die dokumentierten ursprünglichen Ergebnisse heranziehen, obwohl die aktuelle DMARC-Prüfung fehlschlägt. Ob sie die Nachricht annehmen, hängt von ihrem Vertrauen in den Weiterleiter und den übrigen Empfangsregeln ab.

Keines der Verfahren ist lediglich eine DNS-Einstellung, auch wenn die zugehörige Authentifizierung DNS-Einträge benötigen kann. Ohne SRS-Umschreibung und ARC-Versiegelung auf Transportebene kann die externe Alias-Weiterleitung bei strengen DMARC-Richtlinien besonders anfällig sein. Ob DMARC besteht, hängt auch von einer erhaltenen, passenden DKIM-Signatur ab.

Zwei betriebliche Fallstricke

Auch mit SRS und ARC können zwei verbreitete Konfigurationen weiterhin Probleme verursachen.

Die falsche Absenderidentität beim Antworten

Weiterleitung wirkt nur in Empfangsrichtung. Wenn Sie eine weitergeleitete Nachricht in Gmail öffnen und antworten, kann als From-Adresse founder@gmail.com statt sales@yourdomain.com verwendet werden. Der Kunde sieht dann Ihre private statt Ihrer geschäftlichen Adresse.

Abhilfe: Richten Sie in Gmail unter Einstellungen → Konten die Funktion „Senden als“ ein. Hinterlegen Sie die Alias-Adresse und die Versand-SMTP-Zugangsdaten Ihrer Domain, sofern diese Konfiguration unterstützt wird. Prüfen Sie anschließend, ob Gmail über den gewünschten Server sendet und Antworten Ihre Domainadresse zeigen. Verbindungsdetails finden Sie in den Einstellungen für TrekMails verwalteten SMTP-Versand.

Das kann funktionieren, erfordert im beschriebenen Ablauf aber drei zusätzliche Einrichtungsschritte pro Konto. Wenn Sie das SMTP-Passwort ändern, müssen die gespeicherten Zugangsdaten gegebenenfalls ebenfalls aktualisiert werden.

Die Catch-all-Falle bei externer Weiterleitung

Leiten Sie einen Catch-all (*@yourdomain.com) möglichst nicht extern weiter. Spammer testen regelmäßig zufällige lokale Adressteile bekannter Domains, etwa billing@, admin@ und noreply12345@. Ein Catch-all nimmt diese Nachrichten entgegen und kann sie an das externe Ziel weiterreichen.

Wenn Ihr Server täglich Tausende Spamnachrichten an Gmail weiterleitet, kann das seine IP-Reputation beeinträchtigen. Dann können auch legitime Nachrichten im Spamordner landen, einschließlich der Nachrichten Ihrer regulären Postfächer. Die Wiederherstellung einer beschädigten Reputation kann Wochen dauern, nachdem ihr Aufbau Monate beansprucht hat.

Wenn Sie einen Catch-all benötigen, verwenden Sie einen lokalen Posteingang und prüfen Sie ihn manuell. Die Dokumentation zur Postfachweiterleitung in TrekMail erläutert die Konfiguration. Eine lokale Ablage reduziert die externe Spamverstärkung, ersetzt aber keine Filterung und laufende Kontrolle.

Alias-Weiterleitung oder eigenes Postfach: Was passt?

Der Leitfaden zu Domain-Alias und Postfach bietet die ausführliche Entscheidungshilfe. Hier die Kurzfassung speziell für Weiterleitungen:

Problematisch ist es, eine Alias-Weiterleitung dauerhaft als Ersatz für ein Postfach einzusetzen, nur um Kosten zu senken. Bei nutzerabhängigen Preisen ist dieser Anreiz nachvollziehbar. Ohne solche Gebühren entsteht oft vermeidbarer Betriebsaufwand: zusätzliche Einstellungen, Sonderfälle und Authentifizierungsfehler, die ausgerechnet bei wichtigen Nachrichten auffallen können.

Wie TrekMail Weiterleitungen handhabt

Wer SRS und ARC selbst betreibt, muss je nach Architektur beispielsweise Postfix-Routing und SRS-Dienste einrichten, ARC-Signaturschlüssel verwalten und deren Rotation betreuen. Das ist eine Aufgabe für die Serveradministration, die viele Betreiber lieber ihrem Hoster überlassen.

Im Funktionsstand der Quelle verwendet die Postfachweiterleitung der TrekMail-Tarife Pro und Agency eine Transportschicht mit OpenARC. Für die unterstützten Weiterleitungen ist automatische ARC-Versiegelung vorgesehen; das Ziel wird im Dashboard eingestellt. Diese Verarbeitung erfolgt auf MTA-Ebene, nicht über eine bloße Änderung Ihrer DNS-Einträge. Prüfen Sie die aktuelle Tarifverfügbarkeit und die genaue Unterstützung von SRS und ARC.

In vielen Fällen ist es allerdings einfacher, ganz auf Weiterleitung zu verzichten. Das in der Quelle beschriebene TrekMail-Preismodell berechnet keine separate Nutzer- oder Postfachgebühr. Für ein Postfach support@yourdomain.com verändert sich der Preis dort nicht allein dadurch, ob eine Person oder zehn Personen darauf zugreifen; Tarifgrenzen und sichere Zugriffsverwaltung bleiben zu beachten. Damit entfällt innerhalb dieser Bedingungen der Kostenanreiz, an ein privates Gmail-Konto weiterzuleiten und bei jeder neuen Domain „Senden als“ einzurichten.

• Kleine und mittlere Unternehmen: Richten Sie für support@ einen eigenen IMAP-Zugang ein. Direkter Zugriff vereinfacht die Trennung der Identitäten. Prüfen Sie die Antwortadresse im Client; eine separate „Senden als“-Konfiguration lässt sich so häufig vermeiden.
• Agenturen: Erstellen Sie eigene Postfächer für die Funktionsadressen Ihrer Kunden, statt an private Mitarbeiterkonten weiterzuleiten. Mit passenden Zugriffsrechten und korrekt eingerichteten Clients kann Ihr Team direkt zugreifen und unter einer einheitlichen Absenderadresse antworten.

Wenn Sie SPF, DKIM und DMARC für Ihre Domains neu einrichten, behandelt der Leitfaden zu den Sicherheitsgrundlagen geschäftlicher E-Mail die grundlegende Authentifizierung an einem Ort.

Fazit

Eine E-Mail-Weiterleitung über einen Alias kann für wenig kritische Anwendungen ausreichen. In folgenden Situationen steigt das Risiko:

1. Der ursprüngliche Absender verwendet strenges DMARC (p=quarantine oder p=reject) und es besteht keine passende Authentifizierung
2. Ihr Weiterleitungsserver verwendet kein SRS, sodass SPF am Ziel bei unverändertem Envelope-Absender scheitern kann
3. Ihr Weiterleitungsserver verwendet kein ARC; SRS allein stellt den SPF-Domainabgleich für DMARC nicht wieder her, erhaltenes passendes DKIM kann DMARC aber bestehen lassen
4. Sie leiten einen Catch-all extern weiter und verstärken damit möglicherweise Spam
5. Sie müssen mit der Alias-Adresse antworten, was die Weiterleitung allein nicht ermöglicht

Die Maßnahmen sind passende Protokollunterstützung beim Hoster, insbesondere SRS und ARC, oder ein eigenes Postfach mit direkter Anmeldung statt des Weiterleitungsalias. Bei Preisen pro Nutzer wirkt die Weiterleitung auf dem Papier attraktiv. Im pauschalen TrekMail-Preismodell der Quelle entfällt dieser Kostenanreiz innerhalb der jeweiligen Tarifgrenzen.

In der Quelle beginnt TrekMails Pro-Tarif bei $10/Monat: bis zu 100 Domains, Postfachweiterleitung mit ARC-Versiegelung und keine separate Postfachgebühr. Für die dort beschriebene kostenlose Testphase von 14 Tagen ist eine Kreditkarte erforderlich, für Nano nicht. Prüfen Sie die aktuellen Preise, Funktionen und Bedingungen.