E-Mail-Aliase: Adressen trennen und Weiterleitungen kontrollieren

Alias, Plus-Adresse und Weiterleitung sind verschiedene Dinge

RFC 5321 §3.9.1 beschreibt Aliasexpansion als Ersatz der Envelope-Empfänger; die Nachricht kann anschließend zugestellt oder weitergeleitet werden. Bei einer Liste nach §3.9.2 wird dagegen der Rückpfad für Fehlermeldungen auf die Listenverwaltung geändert. Die praktische Produktbezeichnung „Alias“ garantiert nicht, dass der Anbieter exakt dieselbe Funktion meint. RFC 5321 §3.9, RFC 5598 §5.1

Der Local-Part vor @ wird vom Zielsystem interpretiert. Ein Pluszeichen ist deshalb keine universelle Funktion jeder Adresse. RFC 5321 §2.3.11, RFC 5233

ARC übermittelt signierte Authentifizierungsangaben über Zwischenstationen. BIMI betrifft die optionale Logoanzeige. Keines der beiden Verfahren legt Ihre Aliasadressen an oder schützt deren Zugang.

Rollenadressen müssen zu Ihren Diensten passen

Rollenadressen wie support@ oder security@ bleiben beim Wechsel einzelner Mitarbeiter stabil. Sie brauchen Zuständige, Vertretung, Zugriffsregeln und einen tatsächlich bearbeiteten Eingang. Bei gemeinsamem Zugriff ist ein betreutes Gruppen- oder Funktionspostfach häufig geeigneter als eine Kopie an viele persönliche Konten.

RFC 2142 knüpft die Unterstützung der Namen an den jeweils angebotenen Dienst. Er definiert keine universelle Liste „fünf Pflichtaliase für jede Domain“ und ersetzt nicht RFC 822. Ein zusätzlicher security.txt-Kontakt kann Sicherheitsmeldungen erleichtern, ist aber ein eigener Kontaktmechanismus. RFC 2142 §§1–6, RFC 9116

Native Aliase: Empfang und Senden getrennt prüfen

Eine eingerichtete Empfangsadresse bedeutet nicht automatisch, dass Ihr Mailprogramm mit ihr senden oder antworten kann. Testen Sie ausgehendes From, sichtbaren Anzeigenamen, Reply-To und den tatsächlich zugestellten Header. Bei wichtigen Funktionsadressen gehören Vertretung und Wiederherstellung zum Test.

Quellen: Microsoft Aliase, Exchange-Grenzen, SendFromAliasEnabled, Plus-Adressen, Google Directory, Outlook.com.

Angekündigte Änderung bei Gmail: Google schreibt, dass „Send as“ für Fremdadressen wie Yahoo oder Outlook ab Januar 2027 entfallen soll; Workspace-Aliase und eigene weitere Gmail-Adressen seien nicht betroffen. Prüfen Sie diese Ankündigung vor einer darauf angewiesenen Umstellung erneut. Google: Senden mit anderer Adresse

Postfix: eine Zuordnung ist noch keine vollständige Einrichtung

Ein Ausschnitt für eine bereits korrekt eingebundene indizierte virtual_alias_maps-Tabelle könnte so aussehen:

# Ausschnitt /etc/postfix/virtual — erfundene Adressen
support@example.com    anna@example.net
rechnung@example.com   buchhaltung@example.net

Das sind externe Zieladressen; es findet Weiterleitung statt. Die Domain muss als passend betreute Aliasdomain eingerichtet sein, die Map eingebunden und mit dem zur Installation passenden Backend aktualisiert werden. Dieser Ausschnitt konfiguriert keinen ganzen Mailserver. Ersetzt oder erweitert man eine vorhandene Map, müssen bestehende Zuordnungen erhalten bleiben.

In indizierten Postfix-Tabellen gilt die dokumentierte Suchfolge, nicht die Zeilenposition: unter anderem exakter user@domain-Treffer vor user vor dem Catch-all @domain. Deshalb ist „Catch-all ans Dateiende, Postfix liest von oben nach unten“ für hash-/vergleichbare indizierte Tabellen falsch. Regexp-/PCRE-Tabellen haben andere Regeln. Postfix virtual(5), TABLE SEARCH ORDER

Lokale Systemaliase in aliases(5) sind ein anderer Mechanismus; nach einer Änderung ist dort newaliases vorgesehen. owner-name kann den Envelope-Absender für Listenbehandlung ändern. Vermischen Sie diese Dateien und ihre Aktualisierungsbefehle nicht. Postfix aliases(5)

Weiterleitung kann die Authentifizierung verändern

Beim externen Weiterleiten sieht der nächste Empfänger die IP des Weiterleiters. SPF für den ursprünglichen Rückpfad kann dann scheitern. Ein umgeschriebener Rückpfad, etwa mit SRS, kann SPF für die Weiterleitungsdomain bestehen lassen, stellt aber nicht automatisch das Alignment zur ursprünglichen sichtbaren From-Domain her. DKIM kann erhalten bleiben, wenn die signierten Teile nicht relevant verändert werden. RFC 7960 §3.2.1, RFC 7208 Anhang D

ARC kann dabei Eingangsergebnisse einer Zwischenstation übermitteln. Ob der Empfänger ihnen vertraut, ist seine Entscheidung. Ein Aliasdienst mit ARC ist deshalb keine Garantie gegen DMARC-Probleme. Testen Sie insbesondere Mailinglisten, Anhänge, automatische Antworten und Rückmeldungen von Zielpostfächern, soweit sie für Ihre Nutzung wichtig sind. Der fremde Weiterleiter gehört nicht pauschal in den SPF-Record des ursprünglichen Absenders.

Catch-all bewusst einsetzen

Catch-all vereinfacht das Anlegen neuer Adressen, erschwert aber die Unterscheidung zwischen geplanten und erfundenen Empfängern. Eine deaktivierte Einzeladresse kann über einen verbleibenden Catch-all weiterhin ankommen. Umgekehrt kann nach Abschalten des Catch-all eine bisher nur implizit genutzte wichtige Adresse verschwinden.

Postfix warnt vor zusätzlichem Spam und Rückläufern. Wer Nachrichten zunächst annimmt und später an gefälschte Rückpfade Unzustellbarkeitsnachrichten erzeugt, kann Backscatter verursachen. Explizit verwaltete Empfänger reduzieren dieses Risiko; die konkrete Annahme-/Weiterleitungsprüfung bleibt Sache des Servers. Postfix VIRTUAL_README

Vor Abschalten: tatsächlich benutzte Adressen erfassen, explizit anlegen, Empfang und Antwort prüfen, erst dann Catch-all entfernen. Bei Fehlern die fehlende konkrete Zuordnung wiederherstellen; ein unkontrollierter Catch-all ist kein guter dauerhafter Reparaturersatz.

Externe Aliasdienste nach dem tatsächlichen Datenfluss auswählen

Ein externer Dienst verarbeitet die weitergeleiteten Nachrichten. Seine Adresse kann die Hauptadresse gegenüber dem angeschriebenen Dienst abschirmen, macht den Verkehr aber nicht anonym und ist keine Ende-zu-Ende-Verschlüsselung. Auch Signaturtexte, frühere Zitate, Kontaktkarten oder ein falscher Antwortweg können die Hauptadresse offenlegen.

Quellen: SimpleLogin FAQ, addy.io eigene Domain, Apple: Adressen verwalten. Diese Beispiele sind keine Rangliste. Preise und Kontingente ändern sich; die Funktionsangaben haben den genannten Quellenstand.

Eine eigene Domain kann den Anbieterwechsel erleichtern, wenn Sie Kontrolle über Domain und Adressbestand behalten. Sie erhöht aber die Verantwortung für Verlängerung, DNS und Migration und kann als gemeinsame Domain mehrere Aliase miteinander verknüpfbar machen. Stellen Sie nicht unbemerkt die MX-Records einer produktiven Postfachdomain auf einen Aliasdienst um. Eine getrennte Subdomain kann die Zuständigkeit abgrenzen.

Welche Lösung passt zu welcher Aufgabe?

Unerwartete Nutzung ist ein Hinweis, kein Herkunftsbeweis

Kommt Spam an shop-7k2@example.com, das Sie nur einem Shop zugeordnet haben, grenzt dies Ihre Untersuchung ein. Es beweist nicht, dass genau dieser Shop Daten verkauft oder verloren hat. Die Adresse kann erraten, aus anderer Korrespondenz gesammelt, bei einem beteiligten Dienstleister sichtbar geworden oder bereits früher anders verwendet worden sein. Bei Plus-Adressen lässt sich der Zusatz zudem leicht entfernen.

1. Prüfen Sie den tatsächlich adressierten Empfänger in einem vertrauenswürdigen Zustellheader; das sichtbare To allein genügt nicht, etwa bei Bcc.
2. Vergleichen Sie das Aliasregister und mögliche Weitergaben oder frühere Nutzung.
3. Prüfen Sie unabhängig die Meldungen des betroffenen Dienstes. Ein Eintrag in einer Leak-Datenbank ist ein begrenzter zusätzlicher Befund; fehlender Eintrag ist keine Entwarnung.
4. Besteht Verdacht auf einen kompromittierten Zugang, sichern Sie das Konto: Kennwort, aktive Sitzungen, Wiederherstellungswege und gegebenenfalls wiederverwendete Zugangsdaten prüfen.
5. Legen Sie bei Bedarf einen neuen Alias an, ändern Sie ihn zuerst im Dienstkonto und testen Sie Anmeldung, Nachrichten und Wiederherstellung. Erst danach den alten Alias deaktivieren.
6. Dokumentieren Sie den Verdacht mit seiner Unsicherheit. Behaupten Sie keine sichere Verursachung durch den Dienst.

Have I Been Pwned kann bei der Recherche nach bekannten Datenlecks helfen. Übermitteln Sie nur eigene oder autorisiert untersuchte Adressen; dieses Kapitel verspricht keine vollständige Datenbankabdeckung, kostenlose Domainüberwachung oder einen bestimmten API-Tarif.

Aliasregister und Lebenszyklus pflegen

Ein kleines Register im passenden geschützten Verwaltungssystem genügt oft:

Das Register selbst kann sensible Zuordnungen enthalten. Begrenzen Sie Zugriff und bewahren Sie Wiederherstellungsdaten getrennt und sicher auf. Schützen Sie Zielpostfach, Aliasdienst und Registrar mit geeigneter starker Anmeldung. Wenn all Ihre Aliase im selben Konto ankommen, gefährdet dessen Übernahme weiterhin alle diese Nachrichten.

Datenschutz und Löschung getrennt behandeln

Das Deaktivieren eines Alias kann einen Zustellweg schließen. Es löscht keine bereits beim Dienst gespeicherten Nachrichten oder Zuordnungen und widerruft nicht automatisch eine dort erteilte Einwilligung. Auch ein Alias kann personenbezogen und durch Zusatzinformationen zuordenbar sein. Die rechtliche Einordnung von Datenflüssen, Rollen und Anbieterbeziehungen erfolgt über E-Mail-Compliance, nicht anhand des Landes im Anbieternamen.

Was ein öffentlicher Domaincheck nicht sehen kann

Der E-Mail Security Check liest öffentliche DNS- und begrenzte SMTP-Merkmale. Bekannte MX-Muster können einen Anbieterhinweis liefern. Er liest kein Aliasregister, prüft keine Rollenpostfächer, sendet keine Nachricht und testet keine Catch-all-Annahme. Auch ein erkanntes MX-Muster belegt nicht, welche konkreten Adressen existieren oder wohin sie weiterleiten. Alias-Hygiene erhält keine eigene Sicherheitswertung.