E-Mail-Aliasse für Ihre Domain: 5 Konfigurationsprobleme prüfen

Ein Beispiel: Sie haben E-Mail-Aliasse Ihrer Domain eingerichtet - sales@yourcompany.com führt zu Ihrem Posteingang, support@ zum Helpdesk. Im Adminbereich sah alles richtig aus. Dann blieben Anfragen aus, ein Kunde meldete eine unzustellbare Nachricht, und Sie bemerkten, dass Sie seit drei Wochen mit Ihrer privaten Adresse antworteten.

Wenn ein Domain-E-Mail-Alias nicht funktioniert, sollten Sie neben Tippfehlern auch Routing und Authentifizierung prüfen. Ältere Weiterleitungsregeln können mit SPF, DKIM und DMARC in Konflikt geraten, ohne dass dies im Einrichtungsdialog deutlich wird.

Wenn Sie 550 5.7.520 oder 554 5.4.14 sehen oder Nachrichten trotz eines freundlichen 250 OK Ihres Servers verschwinden, lohnt sich eine systematische Prüfung. Dieser Leitfaden behandelt fünf häufige Fehlkonfigurationen, ihre typischen Fehlercodes und passende Lösungsansätze.

Wenn Sie zuerst die Grundlagen verstehen möchten - insbesondere den Unterschied zwischen Alias und Postfach -, lesen Sie Domain-E-Mail-Alias oder Postfach.

Funktioniert Ihr Domain-E-Mail-Alias wirklich nicht? Hier beginnen

Viele Aliasprobleme lassen sich einem von fünf Mustern zuordnen. Symptome und Fehlercodes helfen bei der Eingrenzung. Suchen Sie zunächst die passende Tabellenzeile, bevor Sie DNS, Routingregeln oder Verwaltungsrichtlinien ändern. Ein Fehlercode ist ein wichtiger Hinweis, aber nicht immer eine eindeutige Diagnose.

Warum Aliasse scheitern: das Problem der zwei Absenderadressen

Eine E-Mail besitzt verschiedene Absenderidentitäten; für dieses Problem sind zwei entscheidend. Der Envelope Sender (RFC 5321 MAIL FROM) dient Servern als Adresse für Unzustellbarkeitsmeldungen; seine Domain, beziehungsweise die anwendbare HELO-Identität, wird für SPF geprüft. Der Header Sender (RFC 5322 From:) ist die sichtbare Absenderadresse in Gmail oder Outlook. DMARC benötigt mindestens einen erfolgreichen SPF- oder DKIM-Mechanismus mit Domain-Alignment auf dieses From.

Bei interner Zustellung - etwa von sales@ an bob@ auf demselben Server - muss eine Aliasauflösung die Authentifizierung nicht beeinträchtigen. Bei externer Weiterleitung sieht der Zielserver dagegen die IP-Adresse des Weiterleiters. Bleibt der ursprüngliche Envelope Sender erhalten und ist diese IP nicht für dessen Domain autorisiert, kann SPF fehlschlagen. Bei p=reject in der ursprünglichen DMARC-Richtlinie kann eine Nachricht abgewiesen werden, wenn auch kein ausgerichtetes DKIM besteht. Quarantäne, Ablehnung und Unzustellbarkeitsmeldungen hängen von den beteiligten Servern ab; lautloses Verwerfen ist nicht zwangsläufig.

Fehlkonfiguration 1: externe Weiterleitung ohne SRS

Die Weiterleitung eines Domain-Alias an Gmail, Yahoo oder ein privates Outlook.com-Postfach kann SPF beeinträchtigen. Eine strenge DMARC-Richtlinie erhöht das Risiko, wenn keine andere ausgerichtete Authentifizierung erhalten bleibt. Im Zeitraum 2025-2026 ist dies ein wichtiges Fehlerbild, besonders bei Absendern mit p=reject.

Ein Beispiel: alice@bank.com schreibt an contact@yourdomain.com. Ihr Server leitet an you@gmail.com weiter. Gmail prüft SPF für bank.com. Die IP Ihres Weiterleiters ist dort nicht autorisiert, also kann SPF fehlschlagen. Bei p=reject kann Gmail die Nachricht ablehnen, sofern kein ausgerichtetes DKIM DMARC bestehen lässt. Ein zuvor von Ihrem Server gesendetes 250 OK bestätigt nur dessen Annahme; es beweist keine endgültige Zustellung und schließt eine spätere Fehlermeldung nicht aus.

Ein Lösungsbaustein: Sender Rewriting Scheme (SRS). SRS schreibt den Envelope Sender vor der Weiterleitung auf Ihre Domain um:

Ursprünglicher Envelope Sender: alice@bank.com
Nach der SRS-Umschreibung: SRS0=hash=TT=bank.com=alice@yourdomain.com

Gmail prüft SPF nun für yourdomain.com. Ist Ihr Server dafür autorisiert, kann SPF bestehen. SRS wird auf Serverebene aktiviert, etwa durch Ihren Hostinganbieter oder Mailadministrator. Für Postfix und Exim sind SRS-Integrationen verfügbar.

Wichtig: SRS kann SPF für die neue Envelope-Domain ermöglichen, stellt aber nicht die ursprüngliche DMARC-Ausrichtung wieder her. Für DMARC-Ausrichtung kann eine erhaltene, gültige DKIM-Signatur mit passender ursprünglicher From-Domain genügen. ARC (Authenticated Received Chain) liefert zusätzliche Informationen, sofern die Kette gültig ist und der Empfänger dem geprüften signierenden Vermittler vertraut; deren Verwendung liegt in seinem Ermessen und erzeugt keine Ausrichtung. Auch eine neue DKIM-Signatur einer anderen Domain behebt diese fehlende Ausrichtung nicht.

Die einfachere Architektur: Verzichten Sie, wenn möglich, auf externe Weiterleitung. Ein echtes IMAP-Postfach Ihrer Domain lässt sich direkt im mobilen Client öffnen. Externe Weiterleitung ist ein seit 2012 verbreitetes Muster, das unter moderner Authentifizierung zusätzliche Sorgfalt erfordert, aber nicht grundsätzlich unbrauchbar ist.

Fehlkonfiguration 2: Microsoft 365 blockiert externe Weiterleitung

Wenn Ihr Alias extern weiterleitet und Absender 550 5.7.520 Access denied erhalten, prüfen Sie die Richtlinien von Microsoft. Die Standardeinstellung „Automatic - System-controlled“ des ausgehenden Spamfilters in Exchange Online blockiert automatische externe Weiterleitung. Diese Einschränkung soll unter anderem Datenabfluss verhindern; zusätzliche Richtlinien können ebenfalls eine Rolle spielen.

Änderung im Verwaltungsportal:

1. Öffnen Sie das Microsoft 365 Defender-Portal
2. Navigieren Sie zu: Email & collaboration → Policies & rules → Threat policies → Anti-spam
3. Prüfen Sie Anti-spam outbound policy (Default); eine Änderung wirkt organisationsweit, bevorzugen Sie eine auf freigegebene Konten begrenzte Richtlinie
4. Setzen Sie „Automatic forwarding rules“ nur in der genehmigten Richtlinie auf On - Forwarding is enabled

Aktivieren Sie die Weiterleitung nur mit entsprechender Berechtigung und für freigegebene Konten. Erstellen Sie dafür möglichst eine auf diese Konten begrenzte ausgehende Richtlinie. Der folgende PowerShell-Befehl ändert dagegen den organisationsweiten Standard; prüfen Sie zuvor Sicherheitsanforderungen und weitere Einschränkungen.

Alternative mit PowerShell:

Connect-ExchangeOnline
Set-HostedOutboundSpamFilterPolicy -Identity Default -AutoForwardingMode On

Fehlkonfiguration 3: die Routingschleife

Routingschleifen können 554 5.4.14 Hop Count Exceeded auslösen. Die Nachricht wandert zwischen Adressen hin und her, bis ein Server sein konfiguriertes Hop-Limit erreicht - in einer Beispielumgebung etwa 15-20 Hops, nicht als allgemeingültiger Grenzwert. Dann kann der ursprüngliche Absender eine Unzustellbarkeitsmeldung erhalten, ohne dass die Nachricht Ihr Postfach erreicht.

Eine häufige Ursache ist eine vergessene Posteingangsregel im Zielpostfach:

Serveralias: info@ → admin@
Postfachregel für admin@: alles zur Archivierung an info@ weiterleiten
Ergebnis: Schleife bis zum Erreichen des Hop-Limits

Prüfen Sie auch einen vor zwei Jahren eingerichteten Abwesenheitsassistenten oder eine vergessene Regel „alles zur Archivierung an info@“. Das sind mögliche Beispiele, keine feste Fehlerursache. Kontrollieren Sie sowohl serverseitige Aliasse als auch Posteingangsregeln im Client. In Exchange sind Transportregeln im Admin Center relevant. In Google Workspace sollten Sie „Filters and Blocked Addresses“ der betroffenen Konten prüfen.

Die strukturelle Lösung besteht darin, eine erneute Verarbeitung desselben Alias zu verhindern. Prüfen Sie, wann Ihr Server Aliasse auflöst und Benutzerregeln ausführt. Eine Umleitung, die den ursprünglichen Empfänger erhält, kann je nach Routingmodell erneut denselben Alias auslösen. Verwenden Sie einen eindeutigen Zustellpfad und prüfen Sie dessen Verhalten, statt allein auf die Bezeichnung „redirect“ oder „deliver to“ zu vertrauen.

Fehlkonfiguration 4: die falsche „Send As“-Identität

Ein Alias, der nur empfängt, erfüllt nicht jeden Anwendungsfall. Wenn Sie auf eine Nachricht an sales@yourcompany.com antworten und beim Empfänger bob.smith@yourcompany.com im From-Feld erscheint, wird Ihre gewünschte Rollenidentität nicht verwendet. Das kann Ihnen im eigenen Postausgang leicht entgehen.

Prüfung in Google Workspace:

1. Öffnen Sie User Settings → Accounts → „Send mail as“
2. Fügen Sie die Aliasadresse hinzu
3. Prüfen Sie „Treat as an alias“ je nach Identitätszweck. Für eine eigene weitere Adresse kann die Option passen, für eine getrennte Identität ein anderes Verhalten gewünscht sein. Das Deaktivieren garantiert keinen Schutz der Hauptadresse; kontrollieren Sie From, Reply-To und vollständige Header anhand einer Testnachricht.

Prüfung in Microsoft 365:

M365 unterscheidet das Senden von Postfachaliasen, „Send As“ und „Send on behalf“. Eine Anzeige wie „Bob im Auftrag von Sales“ hängt von Berechtigungen und Clientverhalten ab. Für das Senden von Aliasadressen kann ein Administrator diese Organisationsoption aktivieren:

Connect-ExchangeOnline
Set-OrganizationConfig -SendFromAliasEnabled $true

Diese Einstellung gilt für Exchange Online, nicht für Exchange auf eigenen Servern. Sie ersetzt keine „Send As“-Berechtigung und entfernt nicht allgemein jede „im Auftrag von“-Anzeige; auch die Unterstützung des verwendeten Clients muss geprüft werden.

Fehlkonfiguration 5: Kollision mit Catch-all-Regeln

Ein Catch-all (*@domain.com) erfasst Adressen ohne spezifische Zuordnung. Wenn Ihre Routinglogik eine allgemeine Regel vor einer passenden Einzelregel auswählt, kann eine Nachricht im falschen Postfach landen, ohne einen offensichtlichen Fehler auszulösen.

Bei indizierten Postfix-Tabellen für virtual_alias_maps wird normalerweise zuerst die genaue Adresse und danach der Domain-Catch-all gesucht, nicht einfach die Datei von oben nach unten ausgewertet. Die folgende Reihenfolge dient der Übersicht:

# /etc/postfix/virtual
billing@yourdomain.com    finance@yourdomain.com
support@yourdomain.com   helpdesk@yourdomain.com
@yourdomain.com          catchall@yourdomain.com

postmap /etc/postfix/virtual && postfix reload

Den Catch-all zuletzt aufzuführen ist hier eine lesbare Darstellung, keine universelle Prioritätsregel. Bei geordneten PCRE-Maps ist die Reihenfolge relevant; bei MySQL-basierten Aliaszuordnungen bestimmen die tatsächliche Abfrage und das Lookup-Verfahren, welche Treffer bevorzugt werden. Prüfen Sie, dass genaue Adressen vor dem Catch-all berücksichtigt werden; bloße Zeilenreihenfolge genügt nicht unbedingt. Der berechtigte Administrator sollte vor dem Neuaufbau und Neuladen Sicherungen erstellen, vorhandene Maps erhalten und den unterstützten Maptyp, Treffer sowie die Konfiguration testen.

Erweiterte Fehlersuche: vollständige Header lesen

Wenn eine Nachricht ohne erkennbare Fehlermeldung verschwindet, untersuchen Sie die vollständigen Header einer Nachricht, die etwa im Spamordner angekommen ist. Der Header Authentication-Results zeigt die vom jeweiligen Empfänger ermittelten Authentifizierungsergebnisse. Ergänzen Sie diese Hinweise durch Zustellprotokolle und Quarantäneprüfungen.

In Gmail: Nachricht öffnen → Dreipunktmenü → „Show original“. Suchen Sie den Authentifizierungsblock:

Fehlerbeispiel - SRS fehlt:

Authentication-Results: mx.google.com;
  spf=softfail (domain of transition does not designate
    192.0.2.1 as permitted sender) smtp.mailfrom=alice@bank.com;
  dmarc=fail action=quarantine header.from=bank.com;

smtp.mailfrom lautet weiterhin alice@bank.com. Wenn die IP zu Ihrem Weiterleiter gehört, wurde der Envelope Sender auf diesem Pfad nicht durch SRS umgeschrieben.

Erfolgsbeispiel - SRS aktiv:

Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=SRS0=HHH=TT=bank.com=alice@yourdomain.com;
  dmarc=pass header.from=bank.com;

Die Envelope-Adresse wurde umgeschrieben, und SPF besteht für yourdomain.com. Das gezeigte DMARC-Ergebnis setzt eine weitere ausgerichtete Authentifizierung voraus, etwa eine erhaltene gültige DKIM-Signatur der ursprünglichen From-Domain. Der verkürzte Header zeigt diese Signatur nicht; SRS allein erklärt den DMARC-Erfolg nicht.

Um die SMTP-Annahme einer Aliasadresse zu prüfen, können Sie swaks verwenden. Der folgende Aufruf kann eine Testnachricht senden. Ersetzen Sie die Platzhalter durch autorisierte Adressen und Server unter Ihrer Kontrolle, statt fremde Identitäten zu verwenden:

swaks --to sales@yourdomain.com --from test@external.com --server mx.yourdomain.com

250 OK beim Empfängerkommando bestätigt nur die Annahme dieses Empfängers, nicht die endgültige Annahme der nach DATA übertragenen Nachricht, die Existenz eines Alias oder die Zustellung. 550 User Unknown weist darauf hin, dass der Server diesen Empfänger ablehnt; prüfen Sie Aliaszuordnung und Empfängervalidierung.

Vorbeugung: Routing vereinfachen und Hops reduzieren

Viele Aliasprobleme lassen sich durch eine einfachere Architektur vermeiden. Zwei Leitlinien reduzieren typische Fehlerquellen.

Regel 1: externe Weiterleitung möglichst vermeiden. Geschäftliche Nachrichten können im Postfach der Geschäftsdomain bleiben, das Sie per IMAP auf dem Telefon öffnen. Externe Weiterleitung kann SPF beeinträchtigen, Daten über weitere Anbieter führen und zusätzliche Absenderkonfiguration erfordern. Wägen Sie ihren Nutzen gegen diese Risiken ab.

Regel 2: Aliasketten auf einen Hop verkürzen.

Jeder zusätzliche Hop bietet eine weitere Gelegenheit für Schleifen, Headeränderungen oder Authentifizierungsprobleme. Ein direkter Zustellpfad ist deshalb ein sinnvolles Ziel, auch wenn nicht jede Infrastruktur mit nur einem Hop auskommt.

Für zeitlich begrenzte oder kampagnenspezifische Adressen kann Plus-Adressierung - etwa bob+newsletter@domain.com - neue Aliasse ersparen. Ob und wie TrekMail, Gmail oder Exchange sie unterstützen, hängt vom Anbieter und den Kontoeinstellungen ab; prüfen Sie die aktuelle Dokumentation. Manche Webformulare lehnen außerdem das Zeichen + ab, weshalb diese Methode nicht überall funktioniert.

Mehr zu den Vor- und Nachteilen von Aliasen und Weiterleitung finden Sie unter E-Mail-Alias-Weiterleitung.

Wenn das Preismodell Teil des Problems ist

Preise pro Benutzer können eigene Postfächer teuer erscheinen lassen. Dann entstehen Aliasse, um eine weitere Lizenz zu sparen, und anschließend möglicherweise Stunden an Aufwand für SRS, Headerprüfung und Weiterleitungsrichtlinien. Das ist ein möglicher Zielkonflikt, nicht die Ursache jeder Aliasarchitektur. Funktionsaliasse erfordern nicht automatisch eine zusätzliche Benutzerlizenz; prüfen Sie auch Gruppen und gemeinsam genutzte Postfächer nach den Bedingungen des Anbieters.

TrekMail verwendet Kontotarife, nicht allgemein einen eigenen Preis pro Domain oder Postfach. Im historischen Starter-Beispiel ($3.50/Monat) lassen sich sales@, support@ und billing@ innerhalb der Tarifgrenzen als eigene IMAP-Postfächer mit separaten Zugängen und Absenderadressen anlegen. Gemeinsamer Speicher auf Kontoebene kann mit einzelnen Postfachquoten verbunden sein. Prüfen Sie aktuelle Grenzen und Funktionen. Eigene Postfächer können das Routing vereinfachen; die Clientkonfiguration bleibt wichtig. Nur im beschriebenen Nano-Modell benötigen alle ausgehenden Nachrichten einschließlich Antworten Ihren eigenen SMTP-Anbieter. Managed SMTP in bezahlten Tarifen hängt von den tatsächlichen Rechten ab.

Für Agenturen beschreibt dieses historische Beispiel den Pro-Plan ($10/Monat) mit 100 Domains. Prüfen Sie aktuelle Domain-, Postfach- und Speichergrenzen. Ein verfügbarer IMAP-Migrationsassistent kann mit autorisiertem Zugang und kompatibler Quelle Nachrichten aus Gmail oder cPanel kopieren. Prüfen Sie Sicherungen, Ordner und Nachrichten sowie die letzte Differenzsynchronisation vor dem DNS-Wechsel. Kontakte und Kalender benötigen einen eigenen Migrationsplan. Eine folgenlose Umstellung ist nicht zugesichert.

Wenn Sie erstmals Domain-E-Mail einrichten, führt Sie E-Mail mit eigener Domain erstellen durch den Ablauf. Unter TrekMail-Preise prüfen Sie aktuelle Kontotarife, Grenzen und Rechte. Die im ursprünglichen Beitrag beschriebene 14-tägige Testphase eines kostenpflichtigen Tarifs mit erforderlicher Kreditkarte ist keine verbindliche Zusage heutiger Bedingungen.

Fazit

Fünf häufige Fehlerbilder sind SPF-Probleme bei externer Weiterleitung ohne SRS, Richtlinienblockaden in Microsoft 365, Routingschleifen durch vergessene Regeln, falsche Absenderidentitäten und Catch-all-Kollisionen. Fehlercodes helfen bei der Diagnose; die passende Lösung hängt jedoch von Routing, Authentifizierung und Empfängerverhalten ab.

Wenn diese Probleme immer wieder auftreten, prüfen Sie neben der Konfiguration auch die Architektur und das Preismodell. Vielleicht pflegen Sie aufwendige Umwege, obwohl direkte Postfächer besser zum Anwendungsfall passen.

Für weitere Grundlagen und Fehlersuche lesen Sie E-Mail-Weiterleitung einrichten und reparieren.