E-Mail-Alias: Definition, Einrichtung und bewährte Praxis

Wenn Sie ein Unternehmen führen, benötigen Sie mehr E-Mail-Adressen, als Sie Mitarbeiter haben. Sie brauchen sales@ für Interessenten, support@ für Supportanfragen und billing@ für Rechnungen. Der herkömmliche Weg: für jede Adresse ein eigenes Postfach bezahlen. Das bedeutet drei Benutzerplätze, drei monatliche Gebühren und drei zu verwaltende Anmeldungen.

Die intelligentere Lösung ist ein E-Mail-Alias. Mit einem E-Mail-Alias erstellen Sie professionelle, rollenbasierte E-Mail-Identitäten, ohne zusätzliche Benutzerplätze zu bezahlen oder separate Anmeldungen zu verwalten. Eine fehlerhafte Einrichtung kann jedoch Ihre primäre Identität offenlegen, SPF- und DMARC-Probleme verursachen oder eine Routingschleife erzeugen, durch die E-Mails unter Umständen ohne sichtbaren Hinweis verloren gehen.

Dieser Leitfaden behandelt alle wichtigen Aspekte: was ein E-Mail-Alias technisch tatsächlich ist, welche Anwendungsfälle sich lohnen, wie das Routing per SMTP funktioniert, das bei vielen Konfigurationen heikle Thema „Senden als“, häufige Fehlkonfigurationen und die schrittweise Einrichtung von E-Mail-Aliassen in TrekMail.

Was ist ein E-Mail-Alias?

Ein E-Mail-Alias ist eine virtuelle Weiterleitungsadresse, die auf ein bestehendes Postfach verweist. Er besitzt weder eigenen Speicherplatz noch eigene Anmeldedaten oder eine unabhängige Identität. Wenn eine Nachricht an der Aliasadresse eingeht, prüft der Server seine Routingtabelle und bestimmt das von Ihnen konfigurierte Zielpostfach, noch bevor der Nachrichtentext vom sendenden Server übertragen wird.

Sie melden sich nicht bei einem E-Mail-Alias an. Sie melden sich beim Postfach an, an das er weiterleitet. Der Alias ist lediglich eine Anweisung auf Serverebene: Wenn eine Nachricht für diese Adresse eingeht, lege sie dort ab.

Drei Dinge, die ein E-Mail-Alias nicht ist:

• Kein Postfach. Dem Alias selbst ist kein Speicherplatz zugeordnet. Wenn Sie den E-Mail-Alias löschen, geht kein Nachrichtenverlauf verloren, denn die Nachrichten wurden stets im Zielpostfach zugestellt.
• Keine Weiterleitungsregel. Eine Weiterleitung übermittelt Nachrichten an einen externen Server. Ein E-Mail-Alias routet Nachrichten intern innerhalb des E-Mail-Systems Ihrer Domain. Dadurch entsteht durch den Alias selbst kein zusätzliches SPF- oder DMARC-Risiko.
• Kein gemeinsam genutzter Posteingang. Mehrere E-Mail-Aliasse können auf ein Postfach verweisen. Das ist jedoch nicht dasselbe wie ein gemeinsam genutzter Posteingang, in dem mehrere Benutzer zusammen eine gemeinsame Warteschlange bearbeiten.

Die Rezeption als Vergleich: Ihr primäres Postfach ist Ihr Büro. Ein E-Mail-Alias ist lediglich ein weiteres Namensschild an der Tür. Ob jemand an „Die Gründerin“, „Den Vertriebsleiter“ oder „Bob“ schreibt, alle Nachrichten landen im selben Raum. Der Alias organisiert den eingehenden Verkehr professionell, ohne dass Sie ein größeres Büro oder ein höheres Budget benötigen.

Technisch wird ein E-Mail-Alias als Eintrag in der Alias-Tabelle des Mailservers umgesetzt (bei Postfix: virtual_alias_maps; bei Exim: ein Router-Eintrag; bei gehosteten Plattformen: eine Routingregel). Wenn der SMTP-Daemon des Servers eine eingehende Verbindung verarbeitet, prüft er diese Tabelle während der Phase RCPT TO. Findet er die eingehende Adresse in der Alias-Tabelle, schreibt er den Zustellpfad intern und für den Absender unsichtbar um.

E-Mail-Alias, E-Mail-Weiterleitung und Postfach im Vergleich

Ein E-Mail-Alias unterscheidet sich in einem entscheidenden Punkt von einer E-Mail-Weiterleitung: Er belässt die Nachricht im E-Mail-System Ihrer Domain, während eine Weiterleitung sie an einen externen Server übermittelt. Dabei können SPF- und DMARC-Risiken entstehen, aufgrund derer legitime Nachrichten je nach Richtlinien und Implementierung abgewiesen oder aussortiert werden können. Ein Postfach unterscheidet sich von beiden: Es besitzt eigenen Speicherplatz, eigene Anmeldedaten und eine vollständig unabhängige Identität. Wer diese drei Konzepte verwechselt, zahlt möglicherweise zu viel oder riskiert fehlende E-Mails.

Der Entscheidungsweg ist unkompliziert: Bleibt die E-Mail in Ihrer Domain, verwenden Sie einen E-Mail-Alias. Muss sie einen anderen Mailserver erreichen, verwenden Sie eine Weiterleitung. Prüfen Sie zuvor jedoch, ob Ihr Anbieter SRS und ARC unterstützt, da Nachrichten von Absendern mit strengen DMARC-Richtlinien andernfalls einem erhöhten Risiko der Ablehnung oder Aussortierung unterliegen. Muss sich eine Person anmelden, ihren Posteingang unabhängig verwalten oder einen klaren Prüfpfad haben, erstellen Sie ein echtes Postfach.

Den vollständigen Entscheidungsrahmen finden Sie unter Domain-E-Mail-Alias oder Postfach: So treffen Sie die richtige Wahl.

Anwendungsfälle, die wirklich relevant sind

Die besten Alias-Konfigurationen lösen ein echtes betriebliches Problem und dienen nicht nur der Optik. Die folgenden Muster lohnen sich.

1. Rollenbasiertes Routing (der professionelle Auftritt)

Ein Einzelgründer muss nicht wie ein Einzelgründer auftreten. Erstellen Sie info@, press@, accounts@ und sales@ als E-Mail-Aliasse und leiten Sie alle an Ihr primäres Postfach. So vermitteln Sie unmittelbar den Eindruck eines kleinen Teams. Wenn Sie später tatsächlich einen Vertriebsmitarbeiter einstellen, löschen Sie den E-Mail-Alias sales@ und erstellen für diese Person ein echtes Postfach. Unter den jeweils aktuellen Tarifbedingungen ist dafür keine aufwendige Umstellung nötig, und die Übergabe bleibt sauber.

2. Die Strategie zur Anbieter-Nachverfolgung

Geben Sie Ihre primäre geschäftliche E-Mail-Adresse keinem Anbieter, dem Sie nicht vollständig vertrauen. Erstellen Sie stattdessen einen E-Mail-Alias pro Anbieter: hubspot@yourdomain.com, linkedin@yourdomain.com, surveygizmo@yourdomain.com. Wenn Spam an linkedin@ eintrifft, erkennen Sie, über welchen Anbieter die Adresse möglicherweise weitergegeben oder offengelegt wurde. Löschen Sie diesen E-Mail-Alias, beenden Sie die Störung und lassen Sie den Rest Ihrer Einrichtung unverändert.

Das entspricht im E-Mail-Bereich einem Canary Token. Je nach Tarif verursacht die Einrichtung keine Zusatzkosten und kann viel Zeit bei der Fehlersuche sparen, wenn die Datenbank eines Anbieters kompromittiert wird. Solche Vorfälle sind im Betrieb stets als realistisches Risiko einzuplanen.

3. Tippfehlervarianten und frühere Adressen

Sie heißen Michael. Manche Personen werden an micheal@yourdomain.com schreiben. Ihr Unternehmen hat im letzten Jahr seine Marke geändert, und Sie erhalten weiterhin E-Mails an die alte Domain. E-Mail-Aliasse helfen in beiden Fällen. Ordnen Sie häufige Schreibfehler und frühere Adressen dem aktuellen Posteingang zu. So fallen weniger Nachrichten durchs Raster, und Sie müssen nicht zwei Systeme kontrollieren.

4. Plus-Adressierung (Alias ohne Einrichtung)

Viele moderne E-Mail-Systeme, darunter TrekMail, Gmail und Microsoft 365, unterstützen nach den jeweils aktuellen Produktbedingungen die in RFC 5233 definierte Plus-Adressierung. Lautet Ihre Adresse bob@company.com, können Sie bob+newsletter@company.com oder bob+support-ticket@company.com ohne administrative Konfiguration verwenden. Die Nachricht landet weiterhin in Bobs Posteingang, während das Subadress-Tag eine automatische Filterung ermöglicht.

Der Nachteil: Manche Webformulare lehnen das Zeichen + ab. Plus-Adressierung funktioniert häufig zuverlässig zum Filtern und Nachverfolgen, wird jedoch nicht überall akzeptiert. Erstellen Sie für formelle rollenbasierte Adressen stattdessen einen regulären E-Mail-Alias.

5. Agentur- und Multi-Domain-Verwaltung

Wenn Sie E-Mails für mehrere Kunden verwalten oder eine Agentur betreiben, in der jeder Kunde eine eigene Domain besitzt, stellt sich die Frage nach E-Mail-Aliassen pro Domain anders. Bei einem Abrechnungsmodell pro Benutzer bedeutet jede Rollenadresse (support@clientdomain.com, billing@clientdomain.com) potenziell Kosten für einen weiteren Benutzerplatz, die entweder auf der Kundenrechnung erscheinen oder Ihre Marge verringern. Mit dem Pauschaltarif von TrekMail können Sie E-Mail-Aliasse über alle Kundendomains hinweg erstellen, ohne dass dadurch nach den derzeit geltenden Tarifbedingungen zusätzliche Gebühren pro Postfach entstehen. Ein Dashboard, ein Pauschalpreis und keine separate Postfachgebühr pro Domain. Teams, die Dutzende Kundendomains verwalten, finden weitere Informationen unter skalierbares Multi-Domain-E-Mail-Hosting.

6. Abteilungsrouting bei wachsenden Teams

Mit dem Wachstum des Teams werden Adressen auf Abteilungsebene für Routing und Verantwortlichkeit wichtig. hr@, legal@ und finance@ können zunächst jeweils als Alias auf das Postfach des zuständigen Mitarbeiters verweisen oder später zu einem gemeinsam genutzten Postfach umgeleitet werden, wenn das Team groß genug ist. Ein E-Mail-Alias lässt sich unter den jeweils geltenden Tarifbedingungen kostengünstig erstellen und bei einem Rollenwechsel schnell umleiten. Dafür sind normalerweise weder DNS-Änderungen noch ein erneutes Onboarding erforderlich.

Wie ein E-Mail-Alias Nachrichten routet (SMTP-Mechanik)

Ein E-Mail-Alias greift in der Phase RCPT TO einer SMTP-Verbindung, noch bevor der Nachrichtentext übertragen wird. Wenn der Server des Absenders RCPT TO: <sales@yourdomain.com> sendet, prüft Ihr Mailserver seine Alias-Tabelle, findet den Routingeintrag für sales, schreibt den internen Zustellpfad zum Zielpostfach um und akzeptiert die Verbindung mit 250 OK. Der ursprüngliche Header To: in der Nachricht bleibt erhalten. Nur der interne Zustellpfad ändert sich.

Schritt für Schritt:

1. Ein externer Server verbindet sich mit Ihrem MX-Server und öffnet eine SMTP-Sitzung.
2. Der sendende Server übermittelt: RCPT TO: <sales@yourdomain.com>
3. Ihr Server prüft seine Alias-Tabelle. Es gibt kein Postfach namens sales, aber eine Alias-Regel, die zu bob@yourdomain.com routet.
4. Ihr Server akzeptiert die Verbindung (250 OK) und stellt die Nachricht in Bobs Postfach zu.
5. Bobs E-Mail-Client zeigt To: sales@yourdomain.com an. Der ursprüngliche Header bleibt unverändert.
6. Der sendende Server erfährt nicht, dass der E-Mail-Alias existiert. Es entstehen keine zusätzlichen SMTP-Sitzungen und normalerweise keine sichtbaren Unzustellbarkeitsmeldungen.

Bei Postfix, einem weitverbreiteten Open-Source-MTA, wird dies über virtual_alias_maps umgesetzt, eine Nachschlagetabelle, die Aliasadressen realen Postfächern zuordnet. Andere MTAs lösen dies anders (Exim verwendet Router-Konfigurationen, Haraka pluginbasiertes Routing), das Konzept ist jedoch identisch. Der E-Mail-Alias ist eine serverseitige Umschreibungsregel, die aufgelöst wird, bevor eine Nachricht gespeichert wird.

Ein wichtiges Detail: Die Alias-Auflösung basiert auf der Envelope-Adresse, also der im SMTP-Befehl RCPT TO verwendeten Adresse, und nicht zwingend auf dem Header To:. Eine an eine Mailingliste gesendete Nachricht kann To: list@example.com, aber RCPT TO: member@yourdomain.com enthalten. Der Alias wird durch RCPT TO ausgelöst, nicht durch den Header.

Das Problem mit „Senden als“: Antworten über Ihren Alias

Der Empfang über einen E-Mail-Alias ist unkompliziert. Beim Antworten über die Aliasadresse scheitern jedoch viele Konfigurationen. Wenn Bob eine an sales@yourdomain.com gesendete Nachricht erhält und auf „Antworten“ klickt, lautet die standardmäßige Absenderadresse bob@yourdomain.com. Damit wird der professionelle Auftritt, den der E-Mail-Alias ermöglichen sollte, sofort beeinträchtigt. Der Empfänger sieht Bobs persönliche Adresse statt der Rollenadresse.

Die großen Plattformen handhaben die Konfiguration von „Senden als“ unterschiedlich:

Google Workspace

Öffnen Sie Gmail-Einstellungen → Konten → „Senden als“ → Weitere E-Mail-Adresse hinzufügen. Geben Sie den Alias ein. Deaktivieren Sie im Konfigurationsdialog die Option „Als Alias behandeln“. Damit weisen Sie Google an, tatsächlich über die Aliasadresse zu senden, statt sie nur als Anzeigenamen zu verwenden. Bleibt das Kontrollkästchen aktiviert, kann bei Antworten je nach aktueller Google-Konfiguration weiterhin Ihre primäre Adresse im Absenderfeld erscheinen. Diese häufige Fehlerquelle sollten Sie anhand der aktuellen Einstellungen Ihres Kontos prüfen.

Microsoft 365

In der Vergangenheit war dafür ein PowerShell-Befehl durch den Mandantenadministrator erforderlich: Set-OrganizationConfig -SendFromAliasEnabled $true. Ohne diese Einstellung konnten Antworten „Bob im Auftrag von Vertrieb“ anzeigen. Das ist technisch korrekt, legt jedoch die primäre Adresse offen und wirkt in externer Kommunikation möglicherweise unprofessionell. Microsoft führte 2024 eine native Option im Admin Center ein. Prüfen Sie bei älteren Mandanten dennoch anhand der aktuellen Microsoft-Dokumentation und Mandanteneinstellungen, ob die Funktion aktiviert ist.

TrekMail

Nach den derzeit dokumentierten Funktionen unterstützt TrekMail dies nativ. Sie können mehrere Absenderadressen für ein Postfach konfigurieren und die aktive Absenderadresse direkt in Ihrem E-Mail-Client auswählen, etwa in Outlook, Thunderbird, Apple Mail oder Webmail, ohne eine zusätzliche serverseitige Konfiguration vorzunehmen. Der E-Mail-Alias sollte nach korrekter Einrichtung als auswählbare Absenderadresse erscheinen. Vollständige Angaben zur Client-Einrichtung finden Sie unter IMAP-/SMTP-Einstellungen. Prüfen Sie vor der Einrichtung stets die aktuelle Dokumentation.

Fehlkonfigurationen, die den E-Mail-Verkehr beeinträchtigen

E-Mail-Aliasse sind konzeptionell einfach, in der Praxis aber überraschend anfällig für Konfigurationsfehler. Drei Fehlkonfigurationen verursachen einen großen Teil der Probleme.

1. Die Catch-all-Falle

Ein Catch-all-E-Mail-Alias (*@yourdomain.com) akzeptiert jede an Ihre Domain gesendete Nachricht, auch Nachrichten an nicht vorhandene Adressen. Das klingt nach einem Sicherheitsnetz, bringt jedoch erhebliche Nachteile mit sich.

Spammer verwenden Directory Harvest Attacks (DHA): Sie senden massenhaft Nachrichten an zufällig erzeugte lokale Adressteile Ihrer Domain. Ohne Catch-all weist Ihr Server unbekannte Adressen während der SMTP-Sitzung mit 550 5.1.1 User unknown zurück. Mit einem Catch-all-E-Mail-Alias akzeptiert Ihr Server dagegen alles. Dadurch kann das Spamaufkommen stark steigen, Filter können überlastet werden und legitime Nachrichten lassen sich im Rauschen schwerer erkennen.

Wenn Sie ein Sicherheitsnetz für tatsächlich fehlgeleitete E-Mails benötigen, leiten Sie das Catch-all an ein dediziertes Quarantänepostfach und niemals an den Posteingang eines echten Benutzers. Die TrekMail-Dokumentation erläutert die Abwägungen ausführlich: Einrichtung und Risiken eines Catch-all-Posteingangs.

2. Die Routingschleife

Dieses Problem ist weniger offensichtlich. Sie richten support@ als E-Mail-Alias ein, der zu bob@yourdomain.com routet. Bob fährt in Urlaub und konfiguriert sein Postfach so, dass alle Nachrichten automatisch an support@ weitergeleitet werden, weil er erwartet, dass das Team sie während seiner Abwesenheit bearbeitet.

Damit entsteht eine Schleife:

support@ stellt an bob@ zu → bob@ leitet an support@ weiter → stellt an bob@ zu → leitet an support@ weiter → …

Mailserver erkennen dies üblicherweise nach einer gewissen Zeit. Postfix zählt die Hops. Überschreitet eine Nachricht den Grenzwert, kann der Server eine Unzustellbarkeitsmeldung mit 5.4.14 Hop count exceeded erzeugen. Die ursprüngliche Nachricht erreicht dann möglicherweise nicht das vorgesehene Zielpostfach. Die Lösung: Dokumentieren Sie bestehende Alias- und Weiterleitungsbeziehungen, bevor Sie Abwesenheits- oder automatische Weiterleitungsregeln konfigurieren. Leiten Sie ein Postfach niemals an einen E-Mail-Alias zurück, der wiederum zu demselben Postfach routet.

3. Offenlegung der Identität bei „Allen antworten“

Sie sind Mitglied einer Mailingliste, die an marketing@yourdomain.com sendet. Der E-Mail-Alias routet zu Ihrem primären Posteingang bob@yourdomain.com. Sie klicken auf „Allen antworten“, ohne Ihre Absenderadresse auf den Alias umzustellen. Nun sehen alle Empfänger in diesem Verlauf bob@yourdomain.com statt marketing@. In sensiblen Branchen wie Recht, Medizin oder Finanzen ist dies ein echtes Datenschutzrisiko und nicht nur ein kleines Ärgernis.

Abhilfe schafft die oben beschriebene Konfiguration von „Senden als“. Wenn Sie sensible rollenbasierte Kommunikation bearbeiten, sollten Sie anstelle eines E-Mail-Alias ein dediziertes Postfach erwägen: separate Anmeldung, separate Identität und ein geringeres Risiko versehentlicher Offenlegung.

Die Kombination aus Alias und Weiterleitung: SPF, DMARC und SRS

Wenn Sie einen E-Mail-Alias mit einer externen Weiterleitung kombinieren, zum Beispiel contact@yourdomain.com auf Ihr privates Gmail-Konto, können Authentifizierungskonflikte entstehen. Dadurch besteht das Risiko, dass legitime Nachrichten abhängig von Absender-, Weiterleitungs- und Empfängersystem abgewiesen oder aussortiert werden. Diese Einrichtung ist verbreitet, und auftretende Fehler sind oft schwer zu diagnostizieren.

Was fehlschlagen kann und weshalb:

SPF-Fehler: Ihr Weiterleitungsserver übermittelt die Nachricht über die IP-Adresse Ihres Servers an Gmail. Die Domain des ursprünglichen Absenders, beispielsweise bank.com, veröffentlicht einen SPF-Eintrag, der die IP-Adresse Ihres Servers nicht autorisiert. Gmail kann deshalb einen SPF-Fehler feststellen, obwohl die ursprüngliche Nachricht legitim war. Die Nachricht stammte von einer autorisierten Quelle, aber Ihr Server steht nicht in der SPF-Liste von bank.com.

DMARC-Ablehnung: Wenn bank.com eine strenge DMARC-Richtlinie (p=reject) veröffentlicht, kann Gmail die weitergeleitete Nachricht ablehnen, wenn weder SPF noch DKIM die für DMARC erforderliche Gültigkeit und Ausrichtung zur sichtbaren Absenderdomain erreicht. DKIM kann ungültig werden, wenn ein Weiterleitungsserver die Nachricht verändert, etwa eine Fußzeile hinzufügt, die Kodierung ändert oder den Nachrichtentext neu umbrechen lässt. Wenn dadurch die DKIM-Signatur nicht mehr stimmt und zugleich kein ausgerichtetes SPF-Ergebnis vorliegt, schlägt DMARC fehl; bei p=reject kann dies zu einer endgültigen Ablehnung führen.

Zwei Mechanismen können dieses Risiko mindern, erfordern jedoch beide die Unterstützung des Hostinganbieters:

• SRS (Sender Rewriting Scheme): Der Weiterleitungsserver schreibt den Envelope-Absender (MAIL FROM) auf Ihre Domain um. Die SPF-Prüfung kann am Ziel dann für diesen Envelope-Absender erfolgreich sein, weil die Nachricht nun von Ihrer Domain statt von der Domain des ursprünglichen Absenders zu kommen scheint. Unzustellbarkeitsmeldungen werden so kodiert, dass sie den ursprünglichen Absender weiterhin erreichen. SRS allein stellt jedoch nicht die DMARC-Ausrichtung zur unveränderten sichtbaren Absenderdomain her.
• ARC (Authenticated Received Chain): Der Weiterleitungsserver ergänzt eine kryptografisch gesicherte Verarbeitungskette. Sie hält die vor der Weiterleitung ermittelten Authentifizierungsergebnisse fest und schützt deren Integrität entlang weiterer Stationen. Zielserver mit ARC-Unterstützung können diese Information bei der Bewertung eines bekannten, vertrauenswürdigen Vermittlers berücksichtigen. ARC ist in RFC 8617 dokumentiert.

Viele günstige Domainregistrare und ältere Shared-Hosting-Angebote unterstützen ARC nicht; auch SRS ist nicht überall verfügbar. Wenn Sie Aliasse auf solchen Plattformen extern weiterleiten, besteht für legitime E-Mails von Absendern mit strenger DMARC-Richtlinie ein erhöhtes Risiko, abgewiesen oder aussortiert zu werden. Ob dabei eine Unzustellbarkeitsmeldung erzeugt wird, hängt vom beteiligten System ab. TrekMail gibt derzeit an, bei weitergeleiteten E-Mails sowohl SRS als auch ARC zu unterstützen. Prüfen Sie vor der Einrichtung die aktuellen Leistungsmerkmale.

Die vollständige technische Erklärung dieses Szenarios finden Sie unter E-Mail-Alias-Weiterleitung: Abwägungen und Lösungen sowie im ausführlicheren Leitfaden zur Einrichtung und Fehlerbehebung von E-Mail-Weiterleitungen.

E-Mail-Aliasse in TrekMail einrichten

E-Mail-Aliasse werden in TrekMail nach der derzeitigen Produktstruktur auf Domainebene verwaltet. Sie erstellen sie pro Domain und leiten sie an ein Postfach derselben Domain. Im Folgenden finden Sie die vollständige Einrichtungsfolge. Prüfen Sie ergänzend die aktuelle Produktdokumentation.

Schritt 1: Domain hinzufügen und DNS konfigurieren

Wenn Ihre Domain noch nicht in TrekMail vorhanden ist, fügen Sie sie im Dashboard unter Domains → Domain hinzufügen hinzu. TrekMail erzeugt nach der derzeitigen Einrichtung die erforderlichen DNS-Einträge für Sie: MX, SPF, DKIM und DMARC. Übertragen Sie diese in das Bedienfeld Ihres DNS-Anbieters. Die vollständigen aktuellen Eintragswerte finden Sie unter erforderliche DNS-Einträge. Die DNS-Propagation ist häufig innerhalb einer Stunde abgeschlossen, kann jedoch je nach TTL, Cache und Anbieter länger dauern. TrekMail zeigt eine grüne Statusprüfung an, sobald die Einträge erkannt wurden.

Schritt 2: Zielpostfach erstellen

Ein E-Mail-Alias benötigt ein Zustellziel. Erstellen Sie zunächst Ihr Zielpostfach: Öffnen Sie Postfächer → Postfach hinzufügen und legen Sie Adresse und Passwort fest. In diesem Posteingang landen die über den E-Mail-Alias gerouteten Nachrichten. Bei TrekMail löst die Erstellung eines Postfachs nach den derzeit veröffentlichten Tarifbedingungen keine neue Gebühr pro Benutzer aus, sondern nutzt den gemeinsamen Speicherplatz Ihres Tarifs. Prüfen Sie vorab die aktuellen Tarifdetails.

Schritt 3: E-Mail-Alias erstellen

Navigieren Sie im Domain-Dashboard zu Aliasse → Alias hinzufügen. Geben Sie den lokalen Teil des E-Mail-Alias ein, beispielsweise sales, und wählen Sie das Zielpostfach aus der Dropdownliste. Speichern Sie die Einstellung. Der E-Mail-Alias sollte unmittelbar aktiv sein. Dafür sind normalerweise weder DNS-Änderungen noch eine Wartezeit für die Übernahme erforderlich.

Sie können so viele Aliasse erstellen, wie Ihr jeweils aktueller Tarif zulässt. Zum Zeitpunkt der beschriebenen Konditionen unterstützt Starter unbegrenzt viele Aliasse pro Domain, ohne Gebühr pro Alias. Prüfen Sie die aktuellen Tarifbedingungen, bevor Sie sich auf dieses Limit verlassen.

Schritt 4: „Senden als“ im E-Mail-Client konfigurieren

Wenn Sie über die Aliasadresse antworten und nicht nur Nachrichten darüber empfangen möchten, fügen Sie den Alias in Ihrem Client als Absenderidentität hinzu:

• Thunderbird: Konten-Einstellungen → Weitere Identitäten → Hinzufügen. Geben Sie die Aliasadresse ein. Verwenden Sie denselben SMTP-Server und dieselben Anmeldedaten wie für Ihr primäres Postfach.
• Outlook (Desktop): Nach der serverseitigen Konfiguration sollte der Alias gemäß der beschriebenen Einrichtung automatisch als auswählbare Absenderadresse erscheinen. Falls er nicht angezeigt wird, öffnen Sie Datei → Kontoeinstellungen → E-Mail → Weitere Einstellungen und prüfen Sie die Option „Von-Header einschließen“. Bezeichnungen und Verfügbarkeit können sich je nach aktueller Outlook-Version unterscheiden.
• Apple Mail: Mail → Einstellungen → Accounts → Ihr Konto auswählen → Accountinformationen. Fügen Sie die Aliasadresse im Feld „E-Mail-Adresse“ als kommagetrennten Wert hinzu. Apple Mail sollte sie anschließend als Absenderoption anbieten. Prüfen Sie bei neueren Versionen die aktuelle Menüführung.
• Webmail: In der Webmail-Oberfläche von TrekMail können Sie nach der beschriebenen Funktion die Absenderadresse aus einer Dropdownliste auswählen. Der E-Mail-Alias erscheint dort, sobald er im Dashboard konfiguriert wurde.

Die derzeit dokumentierten IMAP-/SMTP-Einstellungen von TrekMail sind clientübergreifend einheitlich: IMAP über Port 993 (SSL/TLS), SMTP über Port 587 (STARTTLS). Vollständige und aktuelle Angaben finden Sie in der Dokumentation zu den IMAP-/SMTP-Einstellungen.

Schritt 5: Ende-zu-Ende-Test durchführen

Senden Sie von einem externen Konto eine Testnachricht an Ihren neuen E-Mail-Alias. Bestätigen Sie, dass sie im Zielpostfach eingeht. Antworten Sie anschließend mit dem E-Mail-Alias als Absenderadresse und prüfen Sie, ob der Empfänger die Aliasadresse und nicht die Adresse des primären Postfachs sieht. Wird die falsche Absenderadresse angezeigt, kontrollieren Sie die Konfiguration von „Senden als“ in Ihrem Client.

Die gesamte Einrichtung von einer bereits per DNS konfigurierten Domain bis zu einem funktionsfähigen E-Mail-Alias kann bei reibungslosem Ablauf ungefähr drei Minuten dauern. Die tatsächliche Dauer hängt jedoch von Umgebung, Berechtigungen und Client ab.

Der herkömmliche Weg und der TrekMail-Weg

Die Verwaltung von E-Mail-Aliassen klingt unkompliziert, bis sie in großem Umfang erfolgt oder ein Abrechnungsmodell pro Benutzer jede neue Rollenadresse zu einem eigenen Kostenpunkt macht.

Der herkömmliche Weg (Google Workspace / Microsoft 365)

Sie zahlen pro Benutzer. Google Workspace Business Starter kostet in der beschriebenen Preisübersicht $6/user/month; Microsoft 365 Business Basic bewegt sich dort in einem ähnlichen Bereich. Das ist eine Abrechnung pro Person, nicht pro Domain oder Alias. Der E-Mail-Alias selbst ist möglicherweise kostenlos, für das Zielpostfach ist jedoch ein kostenpflichtiger Benutzerplatz erforderlich. Preise, Währung, Abrechnungszeitraum und Leistungsumfang können sich ändern und regional abweichen. Prüfen Sie daher die aktuellen Anbieterpreise.

Viele kleine Teams verwenden als Behelfslösung sämtliche E-Mail-Aliasse in einem einzigen Benutzerkonto. info@, sales@, billing@ und support@ sind dann allesamt Aliasse des Gründerpostfachs. Das kann zusätzliche Kosten für Benutzerplätze vermeiden, führt jedoch zu einem unübersichtlichen Posteingang. Alles landet an einer Stelle, wichtige Interessenten gehen zwischen Abrechnungsbenachrichtigungen leichter unter und klare Zuständigkeiten fehlen.

Für Agenturen ist die Situation noch schwieriger. Die Verwaltung von E-Mail-Aliassen über Hunderte Kundenmandanten kann separate Administrationsoberflächen pro Kunde, PowerShell-Skripte für „Senden als“-Berechtigungen und Lizenzen pro Benutzer bedeuten, die auf jeder Rechnung erscheinen. Eine neue Rollenadresse für einen Kunden erfordert dann entweder eine weitere Lizenz oder den Verzicht auf dedizierten Speicherplatz für diese Rolle. Die genauen Abläufe hängen von den aktuellen Funktionen und Lizenzbedingungen des jeweiligen Anbieters ab.

Der TrekMail-Weg

TrekMail verwendet nach der beschriebenen Preisstruktur ein Pauschalmodell für das Domainhosting. Sie zahlen für den Dienst und nicht pro Benutzer. Der Starter-Tarif kostet in dieser Preisangabe $3.50/month und deckt mit gemeinsamem Speicherplatz bis zu 50 Domains ab. Das Hinzufügen eines weiteren E-Mail-Alias oder Postfachs erzeugt danach keinen neuen Rechnungsposten. Preise, Limits und enthaltene Funktionen können sich ändern. Prüfen Sie deshalb vor dem Kauf die aktuellen Tarifbedingungen.

Da zusätzliche Postfächer nach den derzeit beschriebenen TrekMail-Tarifbedingungen keine Zusatzkosten verursachen, können Sie support@ ein eigenes dediziertes Postfach geben, statt die Adresse als Alias auf den bereits überfüllten Posteingang des Gründers zu legen. Das ermöglicht einen besseren Prüfpfad und einen übersichtlicheren Posteingang. Wenn Sie eine Supportkraft einstellen, können Sie ihr die Anmeldedaten übergeben, ohne E-Mail-Aliasse neu zu konfigurieren, den Benutzerplatz zu erweitern oder die Rechnung zu ändern. Prüfen Sie vorab die aktuellen Tarif- und Funktionsbedingungen.

Für Agenturen, die Kunden-E-Mails in großem Umfang verwalten, deckt der Agency-Tarif in der beschriebenen Preisübersicht für $23.25/month 1,000+ Domains ab und umfasst Massenimport sowie API-Zugriff. Rechnerisch liegt der Preis pro Domain damit bei wenigen Cent. Das ist ein grundlegend anderes Modell als eine Lizenzierung pro Benutzer und kann sich deutlich auf die Marge auswirken. Preise, Limits und Funktionen können sich ändern. Prüfen Sie die aktuellen Konditionen.

Tarifdetails finden Sie unter trekmail.net/pricing.

Kurzübersicht

Nutzen Sie diese Tabelle für eine schnelle Entscheidung:

Drei wichtige Regeln:

1. Internes Routing = E-Mail-Alias. Externes Routing = Weiterleitung. Verwenden Sie keine Weiterleitung, wenn ein E-Mail-Alias ausreicht. Andernfalls erhöhen Sie unnötig das Risiko von SPF-/DMARC-Problemen.
2. Konfigurieren Sie „Senden als“, bevor Sie Kommunikation über einen Alias beginnen. Eine Antwort, die Ihre primäre Adresse offenlegt, untergräbt den professionellen Auftritt.
3. Leiten Sie ein Catch-all niemals an den Posteingang eines echten Benutzers. Verwenden Sie ein Quarantänepostfach oder verzichten Sie vollständig auf das Catch-all.

Fazit

Ein E-Mail-Alias ist eines der nützlichsten Werkzeuge in einer geschäftlichen E-Mail-Einrichtung und zugleich eines, das häufig falsch konfiguriert wird. Bei korrekter Einrichtung erhalten Sie eine professionelle E-Mail-Präsenz mit mehreren Identitäten, je nach Tarif ohne Zusatzkosten oder zusätzliche Anmeldungen und ohne zusätzliches Zustellrisiko durch den internen Alias selbst. Bei falscher Einrichtung drohen Routingschleifen, offengelegte Identitäten und ein erhöhtes Risiko, dass extern weitergeleitete Nachrichten aufgrund der DMARC-Richtlinie des Absenders auf Empfängerseite abgewiesen oder aussortiert werden.

Kurz zusammengefasst:

• Verwenden Sie einen E-Mail-Alias für Rollenadressen, Anbieter-Nachverfolgung und Tippfehlervarianten.
• Verwenden Sie ein echtes Postfach, wenn Sie eine separate Anmeldung, dedizierten Speicherplatz oder einen sauberen Prüfpfad benötigen.
• Vermeiden Sie Catch-alls, sofern Sie keine kontrollierte Quarantänestrategie haben.
• Wenn Sie einen E-Mail-Alias extern weiterleiten, prüfen Sie, ob Ihr Anbieter SRS und ARC unterstützt. Bei vielen älteren Hostingangeboten ist das nicht der Fall.
• Konfigurieren Sie stets „Senden als“, bevor Sie einen Alias in der externen Kommunikation verwenden.

Wenn Sie nur für einige wenige Rollenadressen pro Benutzer zahlen, ist das Kostenmodell möglicherweise unvorteilhaft. Beim derzeit beschriebenen Pauschalmodell von TrekMail zahlen Sie für die Domain und nicht pro Postfach oder E-Mail-Alias. Der Starter-Tarif kostet in dieser Preisangabe $3.50/month für bis zu 50 Domains. Der Nano-Tarif erfordert laut der beschriebenen Konditionen keine Kreditkarte und hat keinen Testzeitraum, sondern ist kostenlos, mit 10 Domains und 5GB gemeinsamem Speicherplatz. Preise, Limits und Bedingungen können sich ändern. Prüfen Sie deshalb die aktuellen Tarifangaben.

Wenn Sie verwaltetes SMTP, gemeinsamen Speicherplatz und eine vollständige E-Mail-Alias-Verwaltung über mehrere Domains benötigen, umfassen die kostenpflichtigen Tarife nach den beschriebenen Konditionen einen kostenlosen Testzeitraum von 14 Tagen. Zum Start ist eine Kreditkarte erforderlich. Prüfen Sie die aktuellen Bedingungen und testen Sie die vollständige Plattform unter trekmail.net oder vergleichen Sie alle Tarife unter trekmail.net/pricing.