Modul 3 · 3.3
Deutsch
Aliasse, Weiterleitungen und Catch-all: praktisch, aber nicht ohne Risiko
Modul 3: Ihr Postfach verwalten · Lesezeit: 11 Minuten
Lernziel: Nach dieser Lektion können Sie zwischen einem Postfach, einem Alias, einer Weiterleitung und einem Catch-all wählen und erklären, warum das Weiterleiten an eine externe Adresse und ein Catch-all die Zustellung Ihrer Mail beeinträchtigen können.
Kernbegriffe: Postfach, Alias, Forwarder (Weiterleitung), interne und externe Weiterleitung, SPF schlägt bei Weiterleitung fehl, SRS (Sender Rewriting Scheme), DKIM bei Weiterleitung, ARC (RFC 8617), Catch-all, Wörterbuchangriff, Backscatter, Versenden im Namen einer anderen Adresse
Vier Möglichkeiten, eine Adresse funktionieren zu lassen
Wenn Sie offerte@example.com funktionieren lassen möchten, haben Sie vier Möglichkeiten:
| Option | Was es ist | Wann sinnvoll |
|---|---|---|
| Postfach | Ein eigener Speicherort mit eigenem Passwort. Sie können sich dort anmelden. | Jemand muss selbst damit arbeiten, oder die Mail muss separat aufbewahrt werden. |
| Alias | Ein zweiter Name für ein bestehendes Postfach. Mail an offerte@ landet im Postfach von info@. | Eine Person mit mehreren Adressen. |
| Forwarder (Weiterleitung) | Mail an die Adresse wird an eine oder mehrere andere Adressen weitergeleitet. Es wird nichts aufbewahrt. | Eine Adresse, die bei mehreren Kollegen ankommen soll; eine alte Adresse, die weiter funktionieren muss. |
| Catch-all | Alle Mail an nicht existierende Adressen landet bei einer Adresse. | Fast nie (siehe unten). |
In manchen Panels ist ein Alias technisch dasselbe wie eine Weiterleitung an eine Adresse auf demselben Server. Der entscheidende Unterschied ist: bleibt die Mail auf demselben Server, oder geht sie nach außen?
Weiterleiten innerhalb Ihrer eigenen Domain: kein Problem
Leiten Sie offerte@example.com an info@example.com weiter, und stehen beide auf demselben Server, dann liefert der Server die Mail einfach in das Postfach von info@ aus. Es geht nichts über das Internet, es wird nichts erneut geprüft. Das ist sicher und zuverlässig.
Weiterleiten nach außen: hier entstehen Probleme
Anders wird es, wenn Sie an eine Adresse bei einem anderen Anbieter weiterleiten, zum Beispiel eine private Adresse bei Gmail oder Outlook.com. Dann versendet Ihr Server die Mail erneut, diesmal an Gmail. Und Gmail prüft die Mail, als käme sie von Ihrem Server.
Angenommen: klant@example.net sendet eine Mail an info@example.com. Ihr Server leitet sie an Gmail weiter. Was sieht Gmail?
- Absender (From):
klant@example.net. - Envelope-Absender: weiterhin
klant@example.net, es sei denn, Ihr Server schreibt ihn um. - Versendender Server: Ihr Server, zum Beispiel
192.0.2.25.
Gmail schaut im SPF-Record von example.net nach. Dort steht Ihr Server natürlich nicht. SPF schlägt fehl. Hat example.net eine DMARC-Richtlinie p=reject, und befindet sich keine gültige DKIM-Signatur auf der Mail, dann weist Gmail die Mail zurück. Ihr Server erhält eine Bounce-Nachricht zurück, und die geht an... den ursprünglichen Absender, der nun eine Fehlermeldung von Ihrem Server erhält.
Es gibt drei Mechanismen, die das abmildern:
1. DKIM übersteht es (meistens)
Eine DKIM-Signatur (Lektion 4.3) befindet sich in der Mail selbst. Leitet Ihr Server die Mail unverändert weiter, stimmt die Signatur von example.net noch. DMARC gelingt dann über DKIM, auch wenn SPF fehlschlägt. Deshalb ist DKIM so wichtig: Es ist das Einzige, das eine Weiterleitung übersteht.
Es geht jedoch schief, wenn der weiterleitende Server die Mail verändert: einen Text am Ende hinzufügen ("weitergeleitet von..."), den Betreff anpassen ([SPAM] davor) oder die Formatierung umwandeln. Dann stimmt die Signatur nicht mehr.
2. SRS schreibt den Envelope-Absender um
Mit SRS (Sender Rewriting Scheme) ändert der weiterleitende Server den Envelope-Absender in eine Adresse auf seiner eigenen Domain, zum Beispiel:
SRS0=HHH=TT=example.net=klant@example.comJetzt schaut Gmail im SPF-Record von example.com nach, und dort steht Ihr Server tatsächlich. SPF gelingt. Kommt es zu einer Bounce-Nachricht, kann Ihr Server die Adresse zurückübersetzen und die Bounce-Nachricht an den eigentlichen Absender senden.
Achtung: SRS löst SPF, aber nicht DMARC. Die Alignment-Prüfung (Lektion 4.4) vergleicht die Domain des Envelope-Absenders mit der From-Adresse. Das ist jetzt example.com gegenüber example.net: nicht ausgerichtet. DMARC muss also weiterhin über DKIM gelingen.
3. ARC: eine Erklärung des Vermittlers
ARC (Authenticated Received Chain, RFC 8617, experimentell) lässt einen Vermittler festhalten, was er gesehen hat: "als diese Mail bei mir ankam, bestanden SPF, DKIM und DMARC". Der weiterleitende Server signiert diese Erklärung. Der Endempfänger kann entscheiden, dieser Erklärung zu vertrauen, wenn er dem Vermittler vertraut. Große Empfänger wie Gmail und Microsoft nutzen ARC, aber Sie können sich nicht darauf verlassen: Es ist eine Kulanz, kein Recht.
Und der Spam?
Es gibt noch ein Problem, und das ist oft das größte. Ihr Spamfilter hält nicht alles zurück. Allen Spam, der durchkommt, leitet Ihr Server nun an Gmail weiter. Für Gmail sieht es so aus, als würde Ihr Server Spam versenden. Darunter leidet die Reputation Ihres Servers (und beim Shared Hosting: die aller Kunden auf diesem Server). Gmail stuft danach auch Ihre echte Mail eher als Spam ein.
Was ist besser?
Möchten Sie Ihre geschäftliche Mail in der Gmail- oder Outlook-App lesen? Fügen Sie das Postfach dann als IMAP-Konto hinzu (Modul 2). Die App ruft die Mail direkt von Ihrem Server ab. Es wird nichts weitergeleitet, nichts schlägt fehl, und es geht kein Spam nach außen. Müssen Sie dennoch weiterleiten, stellen Sie den Spamfilter streng vor der Weiterleitung ein.
Catch-all: warum fast nie
Ein Catch-all fängt alle Mail an nicht existierende Adressen auf. Ein Tippfehler wie inof@example.com kommt dann trotzdem an. Das klingt praktisch, aber:
- Spam. Spammer senden massenhaft Mail an erfundene Adressen auf bestehenden Domains (
a.jansen@,sales2@,xkq7@). Das nennt man einen Wörterbuchangriff. Ohne Catch-all weist Ihr Server das alles sofort zurück. Mit Catch-all kommt alles an, oft Hunderte pro Tag. - Keine Fehlermeldung mehr. Wer sich bei Ihrer Adresse vertippt, erhält keine Bounce-Nachricht und denkt, seine Mail sei angekommen. Ohne Catch-all weiß er sofort, dass die Adresse falsch ist.
- Weiterleiten macht es schlimmer. Ein Catch-all, das an Gmail weiterleitet, sendet all diesen Spam an Gmail.
- Backscatter. Ein Server, der zunächst alles annimmt und erst später feststellt, dass eine Adresse nicht existiert, sendet eine Bounce-Nachricht an den (gefälschten) Absender. Das nennt man Backscatter: Fehlermeldungen an unschuldige Menschen, und ein Grund, auf einer Blocklist zu landen.
Möchten Sie ein paar zusätzliche Adressen auffangen, etwa einen häufigen Tippfehler oder eine alte Adresse? Richten Sie dafür einzelne Aliasse oder Weiterleitungen ein. Verwenden Sie pro Website oder Webshop eine eigene Adresse (webshop-x@), um zu sehen, wer Ihre Adresse weiterverkauft? Richten Sie diese Adresse dann als Alias ein, sobald Sie sie verwenden.
Versenden von einem Alias aus
Ein Alias kann auch als Absender dienen. Sie möchten zum Beispiel als offerte@example.com antworten, während Sie als info@ angemeldet sind. Das ist möglich, aber:
- Viele Mailserver prüfen heutzutage, welche Absenderadresse zu welchem Login gehört. Sie dürfen dann nur von Ihrer eigenen Adresse sowie den Aliassen oder Weiterleitungen versenden, die auf Ihr Postfach verweisen. Eine beliebige andere Adresse wird abgelehnt ("account can not send emails from ..."). Das schützt vor Missbrauch.
- In Ihrem E-Mail-Programm fügen Sie den Alias als zusätzliche Identität hinzu (Thunderbird: Identitäten verwalten; Apple Mail: zusätzliche Adressen beim Konto, durch Kommas getrennt; Outlook: das Feld Von einblenden und die Adresse eingeben).
- SPF, DKIM und DMARC funktionieren ganz normal, solange der Alias auf derselben Domain liegt und Sie über Ihren eigenen Server versenden.
In der Praxis: so sieht es in einem Panel aus
In DirectAdmin richten Sie Weiterleitungen bei E-Mail-Funktionen, E-Mail-Weiterleitungen ein. Das Catch-all finden Sie bei Erweiterte Funktionen, Catch-All-E-Mail; dort ist "Catch-all deaktivieren" die empfohlene Einstellung (Mail an nicht existierende Adressen wird abgelehnt). Haben Sie nur eine Domain ohne Paket, finden Sie Weiterleitungen in Mein WebOké bei Meine Domains, Weiterleitungen. Andere Panels (cPanel, Plesk, Microsoft 365, Google Workspace) haben vergleichbare Bereiche, manchmal unter Namen wie "Aliasse", "Weiterleitungen" oder "Gruppen".
Zusammenfassung
- Ein Alias oder eine Weiterleitung innerhalb desselben Servers ist sicher.
- Weiterleiten nach außen bricht SPF. SRS stellt SPF wieder her, aber nicht die DMARC-Alignment; nur eine intakte DKIM-Signatur rettet die Mail, und ARC kann helfen.
- Weitergeleiteter Spam schadet der Reputation Ihres Servers. Lesen Sie externe Mail lieber über IMAP in der App.
- Ein Catch-all zieht Spam an, verdeckt Tippfehler und kann Backscatter verursachen. Verwenden Sie einzelne Aliasse.
- Versenden von einem Alias aus ist möglich, im Rahmen der Regeln Ihres Servers.
Quiz
Aufgabe
Aufgabe O3.3: Bestandsaufnahme Ihrer Adressen. Erstellen Sie eine Liste aller Adressen auf Ihrer Domain: Postfächer, Aliasse, Weiterleitungen und ob ein Catch-all aktiviert ist. Vermerken Sie bei jeder Weiterleitung, ob sie innerhalb Ihrer eigenen Domain bleibt oder nach außen geht (Gmail, Outlook.com, ein anderes Unternehmen). Beantworten Sie anschließend: Welche externe Weiterleitung können Sie durch ein IMAP-Konto in der App ersetzen, und ist ein Catch-all aktiviert, das ausgeschaltet werden könnte? Füllen Sie die Checkliste aus.
Aufgabe O3.3: Bestandsaufnahme Ihrer Adressen
Diese Aufgabe machen Sie selbst; niemand prüft sie nach. Haken Sie ab, was Sie erledigt haben, und markieren Sie die Aufgabe als erledigt.
Interne Aliasse und Weiterleitungen sind sicher. Externes Weiterleiten bricht SPF (SRS löst SPF, nicht das Alignment; DKIM übersteht es, wenn die Mail nicht verändert wird; ARC ist eine Kulanz). Weitergeleiteter Spam schadet dem Ruf des Servers. Ein Catch-all zieht Wörterbuchangriffe an und kann Backscatter verursachen.
Ihre Haken und Notizen bleiben nur in diesem Browser; wir senden sie nirgendwohin. Sind Sie angemeldet, speichern wir in Meine Kurse nur, dass Sie die Aufgabe erledigt haben.
Weiterführende Informationen
Die Schritte in diesen Artikeln gelten für die Panels von WebOké; bei anderen Anbietern funktioniert es ähnlich.
- DirectAdmin Anleitung 7.5: E-Mail-Weiterleitungen: Mail an eine andere Adresse weiterleiten
- DirectAdmin Anleitung 7.6: Catch-All-E-Mail: Mail an nicht existierende Adressen
- E-Mails an eine andere Adresse weiterleiten (Weiterleitungen, Catch-All nicht empfohlen)
- E-Mails von mehreren Aliassen senden, Fehler: Account xxx can not send emails from
- WebOké Anleitung 5.9: E-Mail- und Domain-Weiterleitungen
- Kostenloser DNS-Kurs 4.3: SPF: wer darf im Namen Ihrer Domain E-Mails versenden?
- RFC 8617 (ARC), RFC 7208 Anhang D (SPF und Vermittler wie Weiterleiter)
