KeyHelp: Domain nur für den Mailversand nutzen, wenn der Empfang über Microsoft 365 oder einen anderen Anbieter läuft

Viele Kunden lassen ihre Postfächer bei Microsoft 365, Google Workspace oder einem anderen Mailanbieter, während die Website auf Ihrem KeyHelp-Server liegt. Dann soll der Server Kontaktformulare, Shop-Bestellungen und Systemmails im Namen der Domain verschicken, aber keine Mails für die Domain annehmen. Genau dafür gibt es in KeyHelp die Option „Domain kann ausschließlich für den Versand von E-Mails verwendet werden“. Diese Anleitung zeigt, was die Option technisch ändert, welche DNS-Einträge Sie zusätzlich anpassen müssen und an welchen Stellen Mails sonst im Nichts landen. Sie richtet sich an Administratoren eines Servers wie in KeyHelp installieren und absichern. Die Einrichtung beim externen Anbieter beschreiben wir nicht, sie hängt vom jeweiligen Dienst ab. Getestet haben wir mit KeyHelp 26.1.1 auf Debian 12.

Voraussetzungen

• KeyHelp ab Version 23.1. Laut Changelog kam die Option dort hinzu („Added option to allow email domains for email sending only“). Getestet mit KeyHelp 26.1.1 (Build 3698) auf Debian 12.
• Admin- oder Kundenzugang, die Option liegt im Bearbeiten-Dialog der Domain.
• Die Adresse des externen Mailservers für den MX-Eintrag und dessen SPF-Angabe. Beides nennt Ihnen der Anbieter in seiner Domain-Einrichtung.
• Zugriff auf das zuständige DNS, entweder den „DNS-Editor“ in KeyHelp oder die Verwaltung beim Domain-Anbieter.
• Optional SSH für die Prüfung mit postmap, dig und dem Mail-Log.

Schritt 1: Verstehen, warum der Server sonst lokal zustellt

Postfix fragt bei jeder Mail, ob die Empfänger-Domain eine eigene Mail-Domain ist. KeyHelp beantwortet das über die Datei /etc/postfix/mysql-virtual-mailbox-domains.cf mit dieser Abfrage:

SELECT 1 FROM domains WHERE domain='%s' AND is_email_domain='1'
  AND is_email_sending_only='0' AND is_disabled='0';

Solange die Domain als normale Mail-Domain gilt, stellt Postfix Mails an info@kunde1.example.de direkt in das Postfach auf dem Server zu, ohne den MX-Eintrag zu beachten. Liegt das echte Postfach bei einem anderen Anbieter, erreichen Kontaktformular-Mails der eigenen Website den Kunden nie. Sie stapeln sich in einem Postfach auf Ihrem Server, das niemand abruft.

Verifizieren: Prüfen Sie den Ausgangszustand:

postmap -q kunde1.example.de mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf

Die Ausgabe 1 bedeutet: Postfix hält die Domain für lokal.

Schritt 2: Die Option „nur Versand“ aktivieren

Öffnen Sie „Domains“, klicken Sie bei der Domain auf das Stiftsymbol und wechseln Sie in den Reiter „E-Mail“. Unter „E-Mail-Versand / -Empfang“ lassen Sie „Domain kann für E-Mail verwendet werden“ angehakt und setzen zusätzlich den Haken bei „Domain kann ausschließlich für den Versand von E-Mails verwendet werden“. Die zweite Option ist nur sichtbar, solange die erste aktiv ist. Klicken Sie auf „Speichern“.

KeyHelp erklärt im Formular selbst, was passiert: „Der Empfang von E-Mails wird stattdessen von einem externen E-Mail-Server verwaltet, der in den DNS-Einstellungen der Domain konfiguriert werden muss.“ Der zweite Halbsatz ist wörtlich zu nehmen, siehe Schritt 3.

Verifizieren: Nach etwa einer halben Minute liefert dieselbe postmap-Abfrage aus Schritt 1 keine Ausgabe mehr (Rückgabewert 1). Der Eintrag *@kunde1.example.de bleibt in /var/lib/rspamd/keyhelp/dkim/signing.table stehen, DKIM-Signierung läuft also weiter.

Schritt 3: MX und SPF im DNS umstellen

Die Option ändert die DNS-Zone nicht. Im Test stand nach dem Speichern weiter @ MX 10 mail in der Zone, also der eigene Server. Ändern Sie im „DNS-Editor“ (oder beim externen DNS-Anbieter) den MX-Eintrag auf den Mailserver Ihres Anbieters. Achten Sie auf den Punkt am Ende des Hostnamens, sonst hängt BIND die eigene Domain an. Unser Beispiel mit einem fiktiven Anbieter:

@   MX    10 mx1.mailanbieter.example.
@   TXT   "v=spf1 a ip4:192.0.2.50 -all"

Der SPF-Eintrag muss beide Absender erlauben: den KeyHelp-Server (hier über a, weil die Domain auf den Server zeigt) und den externen Anbieter, im Beispiel mit ip4:192.0.2.50. Bei großen Anbietern ist das meist ein include:-Eintrag, dessen genauen Wert Sie der Doku des Anbieters entnehmen. Das mx aus dem KeyHelp-Standard deckt nach der Umstellung nur noch den fremden MX ab und reicht für Ihren Server nicht mehr. Wie Sie SPF und DMARC im DNS-Editor sauber pflegen, zeigt KeyHelp: SPF, DKIM und DMARC für Kundendomains.

Den DKIM-Eintrag von KeyHelp behalten Sie bei. Signiert der externe Anbieter ebenfalls, braucht er einen eigenen Selektor. Nutzt er wie KeyHelp den Namen default, ändern Sie den Selektor in KeyHelp im Reiter „E-Mail“.

Verifizieren: dig +short @127.0.0.1 MX kunde1.example.de lieferte im Test 10 mx1.mailanbieter.example., dig +short @127.0.0.1 TXT kunde1.example.de den neuen SPF-Wert.

Schritt 4: Versand und Zustellung prüfen

Jetzt kommt der eigentliche Nachweis. Wir haben drei Wege getestet:

• Versand per SMTP-Anmeldung mit dem Postfach info@kunde1.example.de über Port 587: Anmeldung erfolgreich, Mail angenommen und mit DKIM-Signature: … d=kunde1.example.de signiert. Das Postfach dient also weiter als Versandkonto für Website, Shop oder Drucker.
• Mail aus der Website per sendmail als Webspace-Benutzer an info@kunde1.example.de: Postfix stellte nicht mehr lokal zu, sondern suchte den MX mx1.mailanbieter.example auf. Weil es den fiktiven Host nicht gibt, endete die Mail im Test mit „Name service error for name=mx1.mailanbieter.example“. Bei einem echten Anbieter wird sie dorthin zugestellt.
• Mail von außen über Port 25 von einer fremden IP: Abgewiesen mit 554 5.7.1 <info@kunde1.example.de>: Relay access denied. Ihr Server nimmt für die Domain nichts mehr an.

journalctl -u postfix@- --since "-5min" | grep "status="

Verifizieren: Im Log steht für Mails an die Domain ein relay= mit dem externen MX statt dovecot-lmtp. Schicken Sie zusätzlich aus dem Kontaktformular der Website eine Testmail und prüfen Sie, ob sie im Postfach beim Anbieter ankommt.

Schritt 5: Was mit den Postfächern auf dem Server passiert

Bestehende Postfächer der Domain bleiben erhalten. Die Anmeldung per IMAP funktionierte im Test weiter, das Postfach zeigte seine Ordner INBOX, Drafts, Junk und Trash. Neue Mails kommen darin aber nicht mehr an. Kunden sollten darin also nichts mehr erwarten. Haben Sie die Domain gerade von KeyHelp zu einem externen Anbieter umgezogen, holen Sie vorhandene Mails vorher dorthin. Im Kundenbereich unter „E-Mail-Adressen“ bleibt die Domain auswählbar, Kunden können also weitere reine Versandkonten anlegen.

Verifizieren: doveadm auth test info@kunde1.example.de meldet auth succeeded, der Posteingang des Postfachs wächst nach Testmails aber nicht mehr.

Typische Fehler

„loops back to myself“

Aktivieren Sie die Option, ohne den MX umzustellen, schickt Postfix die Mail an den MX, landet bei sich selbst und gibt auf. Im Test stand im Log: status=bounced (mail for kunde1.example.de loops back to myself). Stellen Sie zuerst den MX um oder beide Änderungen gleichzeitig.

„Temporary internal error“ in der Warteschlange

Eine Mail, die vor der Umstellung schon für die lokale Zustellung eingeplant war, hing im Test mit 451 4.3.0 <info@kunde1.example.de> Temporary internal error in der Warteschlange, weil Dovecot die Domain nicht mehr annahm. Prüfen Sie nach der Umstellung „E-Mails in Warteschlange“ im Dashboard.

Haken bei „Domain kann für E-Mail verwendet werden“ entfernt

Wer statt der Versand-Option den ersten Haken herausnimmt, verliert die Unterscheidung. KeyHelp speicherte das im Test ohne Warnung, obwohl ein Postfach existierte. Das Versand-Häkchen verschwand mit, ist danach aber nicht mehr aktiv. Setzen Sie für einen reinen Versand immer beide Haken.

Website-Mails landen beim Anbieter im Spam

Meist fehlt der KeyHelp-Server im SPF-Eintrag, weil nur der Eintrag des Anbieters übernommen wurde. Prüfen Sie, ob a oder die Server-IP enthalten ist.

Häufige Fragen

Muss ich die DNS-Zone in KeyHelp nutzen?

Nein. Liegt das DNS beim Domain-Anbieter, setzen Sie MX und SPF dort. Den DKIM-Wert übernehmen Sie aus dem Dialog „DKIM DNS-Eintrag“ im DNS-Editor.

Kann der Kunde die Option selbst setzen?

Ja. Im Test zeigte der Kundenbereich unter „Domains“ im Bearbeiten-Dialog denselben Reiter „E-Mail“ mit beiden Optionen und dem DKIM-Selektor. Den MX im „DNS-Editor“ kann der Kunde ändern, wenn sein Konto das Recht „DNS-Editor“ hat.

Gilt die Option auch für Subdomains?

Sie gilt je Domain-Eintrag. Die Systemsubdomain und die www-Subdomain blieben im Test unverändert.

Werden Weiterleitungen und Aliasse noch ausgewertet?

Nein, nicht für eingehende Mails, weil der Server die Domain nicht mehr annimmt. Weiterleitungen richten Sie beim externen Anbieter ein.

Testumfang

Wir haben auf KeyHelp 26.1.1 die Option „nur Versand“ aktiviert, MX und SPF umgestellt und Versand per SMTP-Anmeldung, Website-Mail und Eingang von außen mit swaks, sendmail und dem Postfix-Log geprüft. Auffällig: Die Option ändert den MX nicht, ohne Umstellung entsteht eine Mailschleife. Echte Zustellung zu Microsoft 365 haben wir nicht getestet. Senden Sie nach der Umstellung eine Testmail aus dem Kontaktformular.

Fazit

Mit der Option „ausschließlich für den Versand“ trennt KeyHelp sauber zwischen Website-Server und Mailanbieter: Postfix stellt nicht mehr lokal zu, Postfächer bleiben als Versandkonten nutzbar und DKIM signiert weiter. Die Hälfte der Arbeit liegt aber im DNS. Erst mit dem MX beim Anbieter und einem SPF-Eintrag für beide Absender kommen Mails an und gelten als echt.

Weiterführende Anleitungen und Quellen

• KeyHelp installieren und absichern: das kostenlose Hosting-Panel für eigene Server
• KeyHelp: SPF, DKIM und DMARC für Kundendomains einrichten und prüfen
• Exchange Online: SPF, DKIM und DMARC für die eigene Domäne
• KeyHelp Changelog (Keyweb)
• KeyHelp Knowledge Base: DNS-Zone bearbeiten
• Keyweb: KeyHelp, alle Funktionen im Überblick