Microsoft 365 und Plesk-Mail unter einer Domain betreiben: Anleitung für KMU in Kärnten

Ihre Domain gehört schon zu Microsoft 365, aber einzelne Postfächer sollen weiter auf dem eigenen Plesk-Server liegen. Die Frage ist selten, ob das technisch geht, sondern wie Sie es ohne Mailverlust und ohne DMARC-Ablehnungen aufbauen. Diese Anleitung zeigt die komplette Konfiguration mit Exchange Online, Plesk und IONOS-DNS, so dass auch ein IT-Einsteiger sie nachvollziehen kann.

Was Sie in diesem Artikel erfahren:

• Wie Microsoft 365 und Plesk dieselbe Domain per Internal Relay teilen
• In welcher Reihenfolge Sie umstellen, damit es keinen größeren Ausfall gibt
• Wie Zertifikat, Connector, DKIM, SPF und DMARC zusammenspielen
• Welche Fehlermeldungen typisch sind und wie Sie sie beheben

Alle Beispiele nutzen die Platzhalter mustermann.example, mustermann.onmicrosoft.com und die Dokumentations-IP 203.0.113.10. Ersetzen Sie diese Werte durch Ihre eigenen. Den DKIM-Schlüssel übernehmen Sie niemals aus einer Anleitung: Plesk erzeugt für jede Installation einen eigenen.

---

Wie funktioniert der Mailbetrieb mit Microsoft 365 und Plesk unter einer Domain?

Der MX-Eintrag zeigt ausschließlich auf Microsoft 365. Exchange Online nimmt jede eingehende Nachricht an, stellt bekannte Empfänger selbst zu und leitet unbekannte Empfänger per Connector an Plesk weiter. Für Nachrichten von Plesk an das Microsoft-Postfach braucht Plesk einen reinen Weiterleitungseintrag.

Ziel und Ergebnis

Für mustermann.example laufen zwei Systeme parallel:

Adresse	Zielsystem
office@mustermann.example	Microsoft 365 / Exchange Online
max.mustermann@mustermann.example	Plesk
erika.musterfrau@mustermann.example	Plesk
example1@mustermann.example	Plesk
example2@mustermann.example	Plesk
example3@mustermann.example	Plesk

Der Weg einer eingehenden Nachricht sieht so aus:

Internet
   |
   v
Microsoft 365 / Exchange Online
   |
   +-- Empfänger ist office@mustermann.example
   |      -> Zustellung ins Microsoft-Postfach
   |
   +-- Empfänger ist Microsoft unbekannt
          -> Internal-Relay-Connector
          -> mail.mustermann.example
          -> Plesk-Postfach

In der Gegenrichtung braucht Plesk einen Trick, weil es mustermann.example als lokale Domain behandelt:

max.mustermann@mustermann.example
   -> Plesk erkennt mustermann.example als lokale Domain
   -> lokaler Eintrag office@mustermann.example
   -> Weiterleitung an office@mustermann.onmicrosoft.com
   -> Microsoft-Postfach office@mustermann.example

Ohne diese Weiterleitung würde Plesk versuchen, office@mustermann.example lokal zuzustellen, und scheitern.

Alle Zustellwege im Überblick

Diese Tabelle ersetzt das große Ablaufdiagramm und zeigt jeden Weg samt der zuständigen Prüfung:

Von	Nach	Weg	Relevante Prüfung
Internet	office@	MX → Exchange Online → Postfach	Exchange Online Protection
Internet	Plesk-Adresse	MX → Exchange Online → Internal Relay → Connector → Plesk	TLS-Zertifikat, Postfix-Empfängerprüfung
Microsoft-Postfach	extern	Microsoft-365-Ausgang	Microsoft-DKIM (selector1/selector2), SPF
Microsoft-Postfach	Plesk-Adresse	Connector → Plesk	TLS-Zertifikat
Plesk-Postfach	extern	Plesk-SMTP (Port 587)	Plesk-DKIM (default), SPF mit Plesk-IP
Plesk-Postfach	office@	Plesk-Forwarder → onmicrosoft-Adresse → Exchange Online	Forwarder ohne Mailbox
Internet	unbekannte Adresse	Connector → Plesk lehnt mit SMTP 550 ab	kein Catch-all

Wirklich unbekannte Empfänger lehnt Plesk weiterhin mit SMTP 550 ab. Der Forwarder für office ist nur nötig für Nachrichten, die auf Plesk entstehen.

Welche Begriffe müssen Sie kennen?

Sechs Begriffe tragen die ganze Konfiguration:

• MX-Eintrag: sagt anderen Mailservern, wohin neue Nachrichten für die Domain gehen. Hier zeigt er auf Microsoft 365.
• Accepted Domain: legt fest, wie Exchange Online mit der Domain umgeht. Bei Authoritative müssen alle Empfänger in Microsoft 365 existieren. Bei InternalRelay stellt Microsoft bekannte Empfänger selbst zu und leitet unbekannte weiter. Für den geteilten Betrieb ist InternalRelay erforderlich.
• Connector: die kontrollierte SMTP-Verbindung von Microsoft 365 zu Plesk mit Zielserver, Zieldomain und TLS-Prüfung.
• Smart Host: der Zielserver des Connectors, hier mail.mustermann.example.
• SPF: veröffentlicht, welche Server für die Domain senden dürfen. Microsoft 365 und die Plesk-IP müssen enthalten sein.
• DKIM und DMARC: DKIM signiert ausgehende Mails, DMARC legt fest, was mit Mails ohne gültige SPF- oder DKIM-Ausrichtung passiert. Bei p=reject werden sie abgewiesen.

Genau deshalb müssen SPF und DKIM funktionieren, bevor Sie produktiv von Plesk aus senden. Mehr zur E-Mail-Authentifizierung finden Sie auch auf unserer Seite IT-Sicherheit für KMU in Kärnten.

Wenn Sie wissen möchten, ob ein geteilter Mailbetrieb für Ihr Unternehmen sinnvoll ist oder ob ein reiner Umzug besser passt, helfen wir weiter: IT-Support und Betreuung in Kärnten

---

Was brauchen Sie vorab – und in welcher Reihenfolge stellen Sie um?

Sie brauchen einen Microsoft-365-Tenant mit Exchange Online, einen Plesk-Server mit Postfix und Dovecot sowie Zugriff auf das öffentliche DNS. Halten Sie unbedingt die Reihenfolge ein: Erst Zertifikat und Connector, dann die Domain auf Internal Relay umstellen, zuletzt DKIM und SPF ergänzen.

Voraussetzungen

Microsoft 365

• Tenant mit Exchange Online und ein Exchange-Administratorkonto
• lizenziertes Postfach office@mustermann.example
• interne Tenant-Domain mustermann.onmicrosoft.com

Plesk

• Plesk Obsidian auf Linux mit Postfix (SMTP) und Dovecot (IMAP/POP3)
• Let’s-Encrypt-/SSL-It!-Erweiterung
• SSH-Zugriff mit sudo oder als root
• öffentliche Server-IP 203.0.113.10
• Port 25 von außen erreichbar, Port 80 für die http-01-Validierung von Let’s Encrypt

DNS

• Domainverwaltung beim DNS-Anbieter, im Beispiel IONOS
• mustermann.example, www und mail zeigen auf den Plesk-Server
• MX zeigt auf Microsoft 365

Die empfohlene Reihenfolge ohne großen Ausfall

1. Aktuellen DNS-Bestand exportieren oder vollständig als Screenshot sichern.
2. Bestand und DNS prüfen.
3. Plesk-Maildienste und Ports prüfen.
4. Gültiges TLS-Zertifikat für mail.mustermann.example installieren.
5. Plesk-Testpostfach erstellen.
6. Microsoft-Connector erstellen, die Domain aber zunächst Authoritative lassen.
7. TLS-Verbindung validieren.
8. Domain auf InternalRelay umstellen.
9. Connector erneut vollständig validieren.
10. Eingehende Zustellung zu Plesk testen.
11. Plesk-DKIM aktivieren und im DNS veröffentlichen.
12. SPF um die Plesk-IP ergänzen.
13. Ausgehende Zustellung von Plesk testen.
14. Auf Plesk den Weiterleitungseintrag für das Microsoft-Postfach anlegen.
15. Alle Zustellwege testen und anschließend aufräumen.

Der MX-Eintrag muss in diesem Beispiel nicht umgestellt werden, weil er bereits auf Microsoft 365 zeigt.

DNS und Netzwerk vom Plesk-Server aus prüfen

Prüfen Sie zuerst, ob die Namen auf die richtige IP zeigen und welche Einträge existieren:

for h in mustermann.example www.mustermann.example mail.mustermann.example; do
  echo "$h -> $(dig +short A "$h" | tr '\n' ' ')"
done

hostname -I
curl -s https://ifconfig.me
dig +short NS mustermann.example
dig +short MX mustermann.example
dig +short TXT mustermann.example

Erwartet werden die öffentliche IP 203.0.113.10, die Nameserver Ihres DNS-Anbieters, ein MX auf mustermann-example.mail.protection.outlook.com und ein SPF-Eintrag, der zunächst nur Microsoft 365 erlaubt.

Danach prüfen Sie die Maildienste und lauschenden Ports:

sudo /opt/psa/admin/sbin/mailmng --features | grep SMTP_Server
sudo systemctl is-active postfix
sudo systemctl is-active dovecot
sudo ss -lntp | grep -E ':(25|465|587|993|995)\b'

Erwartet: SMTP_Server = Postfix, beide Dienste active und Listener auf 25, 465, 587, 993 und 995. Zur lokalen Firewall:

sudo ufw status verbose
sudo iptables -L INPUT -n -v

Im Beispielsystem war UFW inaktiv und die INPUT-Policy stand auf ACCEPT. Fail2ban-Regeln für Postfix und Dovecot sind normal.

Port 25 testen Sie von einem Windows-PC außerhalb des Servers:

Test-NetConnection mail.mustermann.example -Port 25

Erwartet ist TcpTestSucceeded : True. Lauscht der Server lokal, der externe Test schlägt aber fehl, prüfen Sie Firewalls beim Hoster oder in der Cloud.

---

Wie richten Sie das TLS-Zertifikat für den Plesk-Mailserver richtig ein?

Der Microsoft-Connector akzeptiert nur ein gültiges Zertifikat, das den Hostnamen mail.mustermann.example enthält. Fordern Sie in Plesk ein Let’s-Encrypt-Zertifikat ohne Wildcard per http-01 an und weisen Sie es dem Mailserver ausdrücklich zu. Erst danach liefern Postfix und Dovecot es aus.

Warum liefert Plesk oft das falsche Zertifikat aus?

In vielen Installationen haben Website und Mailserver getrennte Zertifikate. Die Website hatte im Beispiel bereits ein gültiges Zertifikat, Postfix und Dovecot lieferten aber weiterhin das alte, selbstsignierte und abgelaufene Plesk-Zertifikat. Prüfen Sie das so:

echo | openssl s_client -starttls smtp -connect 127.0.0.1:25 \
  -servername mail.mustermann.example 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

Fehlerhafter Ausgangszustand:

subject=... CN=Plesk ...
issuer=... CN=Plesk ...
notAfter=<Datum in der Vergangenheit>
No extensions in certificate

Microsoft meldet dann bei der Connector-Prüfung:

SubjectMismatch
Expected Subject: mail.mustermann.example
Presented Subject: CN=Plesk

Wildcard-Zertifikat: Warum wir davon abraten

Ein Wildcard-Zertifikat *.mustermann.example braucht die Validierung dns-01, also einen TXT-Eintrag _acme-challenge im DNS. Liegt das DNS bei einem externen Anbieter wie IONOS, kann Plesk die Zone nicht selbst ändern. Die spätere automatische Erneuerung würde deshalb scheitern.

Wenn Sie es trotzdem versuchen, beachten Sie diese Stolpersteine:

• Klicken Sie erst auf Get it free, wenn der neue TXT-Wert bei allen Nameservern sichtbar ist.
• Laden Sie die Plesk-Seite vorher nicht neu, sonst erzeugt Plesk ein neues Token.
• Ein alter TXT-Wert kann die Validierung verhindern.

Kontrolle an allen autoritativen Nameservern:

for ns in $(dig +short NS mustermann.example); do
  echo "== $ns"
  dig +short TXT _acme-challenge.mustermann.example @"$ns"
done

Zertifikat ohne Wildcard neu ausstellen und dem Mailserver zuweisen

Zuerst diagnostizieren Sie, was zugewiesen ist:

postconf smtpd_tls_cert_file tls_server_sni_maps
ls /etc/dovecot/conf.d/ | grep -i mustermann
plesk bin certificate --list -domain mustermann.example
plesk bin domain --info mustermann.example | grep -i -E 'certificate|mail service'

Im Beispiel verwendete Postfix /etc/postfix/postfix.pem, und für die Domain gab es keinen passenden Dovecot-SNI-Eintrag. Das neue Zertifikat war nicht als Mailserver-Zertifikat gebunden.

In Plesk gehen Sie auf Websites & Domains → mustermann.example → SSL/TLS Certificates → Let’s Encrypt → Reissue und wählen:

Option	Einstellung
Secure the domain name mustermann.example	an
Secure the wildcard domain *.mustermann.example	aus
Include a www subdomain	an
Secure webmail	optional/an
Secure mail mail.mustermann.example	an
Assign the certificate to the mail domain	an
DANE support	aus
Domain validation method	HTTP (http-01)

Danach weisen Sie das Zertifikat serverweit dem Maildienst zu:

sudo plesk bin mailserver --set-certificate "Lets Encrypt mustermann.example" \
  -certificate-repository mustermann.example

Bei Erfolg gibt der Befehl nichts aus und endet mit Exit-Code 0. Die Option -certificate-repository ist nötig, weil Plesk sonst im Server-Repository sucht, das Zertifikat aber im Repository der Domain liegt. Ohne sie erscheint Unable to find the certificate.

Der Befehl gilt als Standard für den Mailserver, und Postfix sowie Dovecot werden neu geladen. Andere Domains mit eigenen SNI-Zertifikaten bleiben grundsätzlich unberührt, prüfen Sie sie nach der Änderung trotzdem stichprobenartig. Ein Rückbau wäre mit sudo plesk bin mailserver --set-certificate "default certificate" möglich, wurde hier aber nicht getestet. Prüfen Sie vorher den tatsächlichen Zertifikatsnamen.

Das Ergebnis ist ein Zertifikat mit den SAN-Einträgen mustermann.example, www, mail und webmail, ausgestellt von Let’s Encrypt. Plesk erneuert es automatisch, ohne manuelle DNS-Aktion.

Alle Ports kontrollieren

SMTP mit STARTTLS:

for p in 25 587; do
  echo "=== SMTP :$p"
  echo | openssl s_client -starttls smtp -connect 127.0.0.1:$p \
    -servername mail.mustermann.example 2>/dev/null \
    | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
done

Direktes TLS:

for p in 465 993 995; do
  echo "=== :$p"
  echo | openssl s_client -connect 127.0.0.1:$p \
    -servername mail.mustermann.example 2>/dev/null \
    | openssl x509 -noout -subject -enddate
done

Den öffentlichen Hostnamen verifizieren Sie von außen:

echo | openssl s_client -connect mail.mustermann.example:25 -starttls smtp \
  -servername mail.mustermann.example -verify_hostname mail.mustermann.example 2>&1 \
  | grep -E 'Verification:|Verify return code'

echo | openssl s_client -connect mail.mustermann.example:993 \
  -servername mail.mustermann.example -verify_hostname mail.mustermann.example 2>&1 \
  | grep -E 'Verification:|Verify return code'

Erwartet:

Verification: OK
Verify return code: 0 (ok)

Zum Schluss prüfen Sie noch die Website, damit die Änderung dort nichts kaputtgemacht hat:

for h in mustermann.example www.mustermann.example; do
  echo "-- $h"
  echo | openssl s_client -connect "$h":443 -servername "$h" \
    -verify_hostname "$h" 2>&1 | grep 'Verification:'
  echo | openssl s_client -connect "$h":443 -servername "$h" 2>/dev/null \
    | openssl x509 -noout -enddate -ext subjectAltName
done

systemctl is-active postfix dovecot nginx

Erneuerungsfehler finden Sie später im Plesk-Log:

grep -E 'letsencrypt|sslit' /var/log/plesk/panel.log \
  | grep ERR \
  | grep mustermann \
  | tail -20

---

Wie verbinden Sie Microsoft 365 per Connector und Internal Relay mit Plesk?

Legen Sie in Exchange Online einen Outbound-Connector zum Plesk-Mailserver an, validieren Sie ihn, während die Domain noch Authoritative ist, und stellen Sie sie erst dann auf InternalRelay um. Danach leitet Microsoft alle unbekannten Empfänger automatisch an Plesk weiter.

Plesk-Testpostfach anlegen

Ein Testpostfach dient nur der Validierung und kann danach gelöscht werden. In Plesk gehen Sie so vor:

1. Websites & Domains → mustermann.example → Mail Settings öffnen.
2. Mailservice für die Domain aktivieren.
3. Mail → Create Email Address öffnen.
4. plesk-test@mustermann.example erstellen und ein sicheres Passwort setzen.
5. Optional ein kleines Quota verwenden, zum Beispiel 100 MB.

Exchange Online PowerShell vorbereiten

Öffnen Sie PowerShell auf einem Administrator-PC und installieren Sie das Modul:

Install-Module ExchangeOnlineManagement -Scope CurrentUser

Falls Skripte nur lokal für dieses Fenster erlaubt werden müssen:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned -Force

Diese Einstellung gilt nur für den aktuellen PowerShell-Prozess und verfällt beim Schließen des Fensters. Anschließend laden Sie das Modul und melden sich mit einem Exchange-Administratorkonto an:

Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline -ShowBanner:$false

Prüfen Sie den Ausgangszustand der Domain und vorhandene Connectoren, damit kein doppelter oder widersprüchlicher Connector entsteht:

Get-AcceptedDomain -Identity mustermann.example |
  Format-List Name,DomainName,DomainType,Default

Get-OutboundConnector |
  Format-List Name,Enabled,ConnectorType,RecipientDomains,SmartHosts,TlsSettings,TlsDomain

Ausgangszustand im Beispiel:

DomainType : Authoritative
Default    : True

Den Connector zu Plesk erstellen

New-OutboundConnector `
  -Name "Microsoft 365 zu Plesk mustermann" `
  -ConnectorType OnPremises `
  -RecipientDomains "mustermann.example" `
  -SmartHosts "mail.mustermann.example" `
  -UseMxRecord $false `
  -TlsSettings DomainValidation `
  -TlsDomain "mail.mustermann.example" `
  -IsTransportRuleScoped $false `
  -CloudServicesMailEnabled $true `
  -Enabled $true

Die wichtigsten Parameter im Überblick:

• RecipientDomains: Der Connector gilt für Empfänger unter mustermann.example.
• SmartHosts: Zustellziel ist der Plesk-Server.
• UseMxRecord $false: Nicht dem MX folgen, sondern ausdrücklich den Smart Host verwenden.
• DomainValidation: Zertifikatskette und Hostname werden geprüft.
• TlsDomain: Das Zertifikat muss mail.mustermann.example enthalten.
• Enabled $true: Connector sofort aktivieren.

Die Konfiguration kontrollieren Sie mit Get-OutboundConnector -Identity "Microsoft 365 zu Plesk mustermann" | Format-List Name,Enabled,ConnectorType,RecipientDomains,SmartHosts,TlsSettings,TlsDomain. Die offizielle Referenz finden Sie in der Microsoft-Dokumentation zu Connectoren im Mailfluss.

Erste Validierung: Warum ein 550 hier normal ist

Validate-OutboundConnector `
  -Identity "Microsoft 365 zu Plesk mustermann" `
  -Recipients "plesk-test@mustermann.example"

Solange die Domain Authoritative ist, kann die TLS-Verbindung schon klappen, während die Testmail mit 550 5.1.10 RESOLVER.ADR.RecipientNotFound scheitert. Das ist erwartbar: Exchange kennt das Plesk-Testpostfach nicht und darf bei einer autoritativen Domain keine unbekannten Empfänger weiterleiten. Ein Zertifikatsfehler wie SubjectMismatch wäre dagegen nicht normal. Dann korrigieren Sie zuerst den Abschnitt zum Zertifikat.

Domain auf Internal Relay umstellen

Stellen Sie erst um, wenn folgende Punkte erfüllt sind:

• Das Plesk-Testpostfach existiert.
• Port 25 ist von außen erreichbar.
• Der Connector existiert und ist aktiviert.
• TLS-Verbindung und Zertifikatprüfung sind erfolgreich.

Dann:

Set-AcceptedDomain -Identity mustermann.example -DomainType InternalRelay

Get-AcceptedDomain -Identity mustermann.example |
  Format-List Name,DomainName,DomainType

Erwartet ist DomainType : InternalRelay. Die Microsoft-Dokumentation zu Accepted Domains erklärt die Domain-Typen im Detail. Validieren Sie den Connector jetzt erneut:

Validate-OutboundConnector `
  -Identity "Microsoft 365 zu Plesk mustermann" `
  -Recipients "plesk-test@mustermann.example"

Erwartet ist IsTaskSuccessful : True. Im erfolgreichen Test wurden Auflösung zu 203.0.113.10, TCP-Verbindung auf Port 25, SMTP EHLO, TLS-Zertifikat samt Hostname, die Zustellung mit 250 2.1.5 Ok und TLS 1.3 bestätigt.

Markieren Sie den Connector danach als validiert:

Set-OutboundConnector `
  -Identity "Microsoft 365 zu Plesk mustermann" `
  -IsValidated $true `
  -LastValidationTimestamp (Get-Date).ToUniversalTime()

Get-OutboundConnector -Identity "Microsoft 365 zu Plesk mustermann" |
  Format-List Name,Enabled,IsValidated,LastValidationTimestamp

Rückbau bei einem Problem

Gibt es Probleme, stellen Sie die Domain sofort zurück:

Set-AcceptedDomain -Identity mustermann.example -DomainType Authoritative

Danach werden unbekannte Empfänger wieder bei Microsoft abgewiesen. Den Connector können Sie zur Fehlersuche aktiviert lassen oder bewusst deaktivieren:

Set-OutboundConnector -Identity "Microsoft 365 zu Plesk mustermann" -Enabled $false

Eingehende Zustellung testen

Prüfen Sie im Plesk-Webmail von plesk-test@mustermann.example, ob diese drei Nachrichten angekommen sind:

1. die Microsoft-Connector-Testmail
2. eine Nachricht von einem Microsoft-365-Postfach
3. eine Nachricht von Gmail oder einem anderen externen Anbieter

Kommen alle drei an, funktionieren beide Wege:

Microsoft 365 -> Plesk
Internet      -> Microsoft 365 -> Plesk

---

Wie setzen Sie DKIM, SPF und DMARC, damit Plesk-Mails nicht abgelehnt werden?

Aktivieren Sie DKIM in Plesk und veröffentlichen Sie den Schlüssel im DNS. Ergänzen Sie außerdem im einzigen SPF-Eintrag der Domain die Plesk-IP zusätzlich zu Microsoft 365. Erst wenn SPF, DKIM und DMARC bei einem Test bestehen, senden Sie produktiv von Plesk aus.

Plesk-DKIM aktivieren

Da die autoritativen Nameserver bei IONOS liegen, kann Plesk die DKIM-Einträge nicht selbst veröffentlichen. In Plesk gehen Sie so vor:

1. Websites & Domains → mustermann.example → Mail → Mail Settings öffnen.
2. Use DKIM spam protection system to sign outgoing email messages aktivieren.
3. Apply klicken.
4. How to configure external DNS öffnen.
5. Die dort angezeigten beiden TXT-Einträge kopieren.

Plesk zeigt Werte in dieser Form an. Der Schlüssel ist hier nur ein Platzhalter:

default._domainkey.mustermann.example. IN TXT "v=DKIM1; p=MIIBIjANBgkq...(Ihr eigener Schlüssel)...IDAQAB;"

_domainkey.mustermann.example. IN TXT "o=-"

Bei IONOS ergänzt das Portal den Domainnamen automatisch. Geben Sie deshalb nur diese Hostnamen ein:

Typ	Hostname bei IONOS	Wert
TXT	default._domainkey	nur v=DKIM1; p=...;
TXT	_domainkey	o=-

Häufiger Fehler: Fügen Sie nicht die komplette Zonendateizeile als Wert ein. Der Wert darf nicht mit default._domainkey.mustermann.example. IN TXT beginnen. Er muss direkt mit v=DKIM1; p= starten.

Fügen Sie keine eigenen Anführungszeichen hinzu, IONOS stellt sie in der Anzeige selbst dar. Lange TXT-Werte werden im DNS technisch in mehrere Abschnitte geteilt, Resolver setzen sie automatisch wieder zusammen.

SPF für Microsoft 365 und Plesk

Es darf nur einen SPF-Eintrag für die Hauptdomain geben. Der endgültige Eintrag lautet:

v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com ~all

Die Bestandteile:

• ip4:203.0.113.10: Plesk darf senden.
• include:spf.protection.outlook.com: Microsoft 365 darf senden.
• ~all: Andere Quellen sind nicht autorisiert, in der Einführungsphase als Softfail.

Steht später zweifelsfrei fest, dass keine weiteren Versanddienste im Spiel sind, können Sie ~all bewusst auf -all verschärfen. Die Grundlagen stehen im SPF-Standard RFC 7208.

IONOS-Besonderheit: Der alte SPF-Eintrag gehörte zum automatisch verwalteten IONOS-Service „Microsoft Office 365“ und lautete v=spf1 include:spf.protection.outlook.com ~all. IONOS warnt beim Ersetzen, dass der Service für diesen DNS-Eintrag deaktiviert wird. Die Ersetzung ist korrekt, wenn in der Liste der entfernten Einträge ausschließlich der alte SPF-Eintrag steht. Möchte IONOS zusätzlich MX-, Autodiscover- oder DKIM-Einträge entfernen, brechen Sie den Vorgang ab und prüfen die Konfiguration erneut.

Welche DNS-Einträge sind für den Mailbetrieb entscheidend?

Typ	Hostname	Wert	Zweck
A	@	203.0.113.10	Website/Hauptdomain auf Plesk
A	*	203.0.113.10	nicht explizite Subdomains, darunter derzeit mail, auf Plesk
MX	@	mustermann-example.mail.protection.outlook.com	gesamte eingehende Mail zuerst zu Microsoft 365
CNAME	autodiscover	autodiscover.outlook.com	automatische Konfiguration für das Microsoft-Postfach
CNAME	selector1._domainkey	selector1-mustermann-example._domainkey.mustermann.onmicrosoft.com	Microsoft-DKIM
CNAME	selector2._domainkey	selector2-mustermann-example._domainkey.mustermann.onmicrosoft.com	Microsoft-DKIM
TXT	@	v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com ~all	erlaubt Versand von Plesk und Microsoft
TXT	_dmarc	v=DMARC1; p=reject; rua=mailto:dmarc@mustermann.example; ruf=mailto:dmarc@mustermann.example	DMARC-Richtlinie
TXT	default._domainkey	v=DKIM1; p=...	öffentlicher Plesk-DKIM-Schlüssel
TXT	_domainkey	o=-	Plesk-DKIM-Richtlinie

Der Wildcard-A-Eintrag deckt zwar mail.mustermann.example ab, bei einem Neuaufbau ist ein ausdrücklicher Eintrag aber übersichtlicher:

mail  A  203.0.113.10

Die DMARC-Details regelt RFC 7489. Weitere Microsoft-Einträge gehören zu Geräteverwaltung und Kommunikationsdiensten und dürfen Sie im Rahmen der Mail-Split-Konfiguration nicht löschen:

Typ	Hostname	Zweck
CNAME	enterpriseenrollment	Geräteverwaltung
CNAME	enterpriseregistration	Geräteregistrierung
CNAME	lyncdiscover	Microsoft-Kommunikationsdienste
CNAME	sip	Microsoft-Kommunikationsdienste
SRV	_sip._tcp	SIP-Dienst
SRV	_sip._tls	SIP über TLS
SRV	_sipfederationtls._tcp	SIP-Föderation

Website- und Anwendungseinträge gehören nicht zum Mail-Split. Im Beispiel sind das etwa diese Hosts:

Hostname	Ziel
www	203.0.113.10
shop, www.shop	203.0.113.10
erp	203.0.113.10
www.erp	erp.mustermann.example
wiki	203.0.113.20 (anderer Server)
app	203.0.113.20 (anderer Server)

Aufräumkandidaten im DNS

Sichtbar waren zwei ACME-bezogene TXT-Einträge:

_acme-challenge
acme-challenge

Das Zertifikat wird nun per HTTP-Validierung erneuert, die alten DNS-01-Token sind daher überflüssig. Stellen Sie vor dem Löschen sicher, dass kein anderes Zertifikat oder ACME-Client sie nutzt. Der Hostname ohne führenden Unterstrich (acme-challenge) ist für die Standardprüfung ohnehin nicht korrekt.

Ausgehenden Plesk-Versand testen

Testen Sie erst, wenn SPF und DKIM öffentlich sichtbar sind. Unter Windows:

Resolve-DnsName mustermann.example -Type TXT
Resolve-DnsName default._domainkey.mustermann.example -Type TXT
Resolve-DnsName _domainkey.mustermann.example -Type TXT

Auf Linux:

dig +short TXT mustermann.example
dig +short TXT default._domainkey.mustermann.example
dig +short TXT _domainkey.mustermann.example

Senden Sie dann aus einem Plesk-Postfach an Gmail und öffnen Sie dort über das Drei-Punkte-Menü Original anzeigen. Erwartet ist:

SPF:   PASS
DKIM:  PASS
DMARC: PASS

Im Beispiel bestanden alle drei Prüfungen.

---

Wie erreichen Plesk-Postfächer das Microsoft-Postfach – und wie testen Sie alles?

Legen Sie in Plesk einen reinen Forwarder ohne Mailbox für office an, der auf die onmicrosoft-Adresse des Microsoft-Postfachs zeigt. Danach prüfen Sie alle sieben Zustellwege mit der Testmatrix. Erst wenn jede Zeile das erwartete Ziel erreicht, ist das Setup produktiv.

Interne Microsoft-Adresse ermitteln

Get-Mailbox office@mustermann.example |
  Select-Object -ExpandProperty EmailAddresses

Relevante Ausgabe:

SMTP:office@mustermann.example
smtp:office@mustermann.onmicrosoft.com

Die Weiterleitungsadresse ist daher office@mustermann.onmicrosoft.com.

Reinen Forwarder in Plesk erstellen

In der Plesk-Oberfläche gehen Sie so vor:

1. Mail → Create Email Address öffnen.
2. Adresse office unter mustermann.example anlegen.
3. Can be used to log in to Plesk deaktivieren.
4. Mailbox deaktivieren.
5. Optional als Beschreibung Weiterleitung zu Microsoft 365 eintragen und speichern.
6. office@mustermann.example öffnen und die Registerkarte Forwarding wählen.
7. Switch on mail forwarding aktivieren.
8. Ziel office@mustermann.onmicrosoft.com eintragen und speichern.

Ist die lokale Mailbox deaktiviert, erscheint Do not deliver copies of forwarded emails to the Plesk mailbox ausgegraut. Das ist korrekt, denn ohne lokale Mailbox kann Plesk keine Kopie speichern.

Optional geht es per Plesk-CLI. Prüfen Sie vorher, ob der Eintrag schon existiert, und legen Sie ihn nicht blind doppelt an:

sudo plesk bin mail -u office@mustermann.example \
  -forwarding true \
  -forwarding-addresses add:office@mustermann.onmicrosoft.com \
  -delivery false

Einsteigern empfehlen wir die Oberfläche, weil dort Mailbox- und Weiterleitungsstatus sichtbar sind. Zum Test senden Sie aus einem Plesk-Postfach an office@mustermann.example. Die Nachricht muss ausschließlich im Microsoft-365-Postfach ankommen.

Die vollständige Testmatrix

Nr.	Absender	Empfänger	Erwartetes Ziel
1	Gmail	office@mustermann.example	Microsoft 365
2	Gmail	Plesk-Adresse	Microsoft 365 → Connector → Plesk
3	Microsoft-Postfach	Gmail	Internet über Microsoft 365
4	Plesk-Postfach	Gmail	Internet über Plesk, SPF/DKIM/DMARC PASS
5	Microsoft-Postfach	Plesk-Adresse	Connector → Plesk
6	Plesk-Postfach	office@mustermann.example	Plesk-Forwarder → onmicrosoft.com → Microsoft
7	Internet	nicht existierende Adresse	Plesk lehnt Empfänger ab, kein Catch-all

Wiederholen Sie alle produktiven Wege nach jeder Änderung an DNS, Zertifikat oder Connector.

---

Was tun bei Fehlern – und wie bleibt das Setup im Betrieb stabil?

Die meisten Probleme haben drei Ursachen: ein falsches Zertifikat, eine noch autoritative Domain oder fehlerhafte DNS-Einträge für SPF und DKIM. Im Betrieb kommt es vor allem darauf an, die automatische Zertifikatserneuerung im Blick zu behalten und für Plesk-Nutzer den richtigen Servernamen zu konfigurieren.

Häufige Fehler und ihre Lösung

SubjectMismatch oder Presented Subject: CN=Plesk

Ursache: Postfix liefert das selbstsignierte Plesk-Standardzertifikat. Das Zertifikat muss mail.<domain> im SAN enthalten und dem Mailserver zugewiesen sein. Kontrollieren Sie mit openssl s_client.

550 5.1.10 RESOLVER.ADR.RecipientNotFound

Ursache: Die Exchange-Domain ist noch Authoritative oder der Empfänger wurde falsch geschrieben. Prüfen Sie Connector und TLS, stellen Sie die Domain auf InternalRelay und legen Sie das Testpostfach in Plesk an.

Gmail zeigt DKIM FAIL

Mögliche Ursachen:

• Der DKIM-TXT-Wert wurde falsch kopiert.
• Der Zonendatei-Präfix default._domainkey... IN TXT wurde irrtümlich als Wert gespeichert.
• Der DNS-Wert passt nicht mehr zum Plesk-Schlüssel.
• Die DNS-Änderung ist noch nicht weltweit sichtbar.

SPF FAIL

Prüfen Sie, ob es nur einen SPF-Eintrag gibt, ob die öffentliche Versand-IP enthalten ist und ob das Microsoft-include nicht fehlt.

Plesk kann an office@mustermann.example nicht zustellen

Ursache: Plesk behandelt die Domain lokal und kennt das Microsoft-Postfach nicht. Erstellen Sie einen reinen Forwarder auf office@<tenant>.onmicrosoft.com.

Connector-Validierung erreicht Plesk nicht

Prüfen Sie:

• mail.<domain> löst zur richtigen IP auf.
• Postfix lauscht auf 0.0.0.0:25 oder der öffentlichen IP.
• Port 25 ist von außen erreichbar.
• Der Hoster blockiert SMTP nicht.
• Fail2ban oder die Firewall sperrt Microsoft nicht aus.

Betrieb und Wartung

Zertifikat: Plesk versucht ungefähr 30 Tage vor Ablauf automatisch zu erneuern. Port 80 und die HTTP-Erreichbarkeit müssen dafür bestehen bleiben. Kontrollieren Sie nach der ersten automatischen Erneuerung das Zertifikat auf SMTP und IMAP erneut.

Mailservername: Mailprogramme müssen mail.mustermann.example verwenden. Der Serverhostname des Hosters, hier server01.hoster.example, ist nicht im Zertifikat enthalten. Wer diesen Namen als Mailserver einträgt, erhält eine Hostnamenwarnung.

Autodiscover: autodiscover.mustermann.example zeigt auf Microsoft 365. Für das Microsoft-Postfach ist das korrekt, Plesk-Benutzer müssen ihre Konten gegebenenfalls manuell konfigurieren. Typische Einstellungen:

Funktion	Server	Port	Verschlüsselung
IMAP	mail.mustermann.example	993	TLS
SMTP Submission	mail.mustermann.example	587	STARTTLS
SMTPS, falls benötigt	mail.mustermann.example	465	TLS

Logs: Das Plesk-Mailprotokoll lesen Sie mit sudo tail -f /var/log/plesk/maillog, die Postfix-Warteschlange mit sudo postqueue -p. Den Message Trace von Exchange Online finden Sie im Exchange Admin Center unter Mail flow → Message trace. Beenden Sie die PowerShell-Sitzung danach sauber:

Disconnect-ExchangeOnline -Confirm:$false

Aus der Beratungspraxis in Kärnten zeigt sich immer wieder: Der Aufbau ist kein Hexenwerk, aber ein einziger vergessener DNS-Eintrag reicht, damit Mails im Nichts landen. Wer eine vollständig selbst betriebene Alternative sucht, findet sie im Beitrag zum eigenen E-Mail-Server mit Mailcow für KMU in Kärnten. Wie sich Microsoft 365 gegen europäische Alternativen schlägt, ordnen wir im Vergleich Euro-Office vs. Microsoft 365 ein. Und wenn Sie auf dem Plesk-Server noch mehr selbst betreiben wollen, hilft der Beitrag zu Self-Hosting-Tools auf dem Plesk-Server. Die Grundkonfiguration eines Plesk-Postfachs beschreibt außerdem die Seite Plesk-Mail einrichten. Die offizielle Referenz dazu ist die Plesk-Dokumentation.

---

Fazit: Geteilter Mailbetrieb funktioniert, wenn die Reihenfolge stimmt

Microsoft 365 und Plesk lassen sich unter einer Domain dauerhaft und stabil betreiben. Entscheidend sind ein gültiges Mailserver-Zertifikat, ein sauber validierter Connector, InternalRelay erst nach erfolgreichem Test sowie ein SPF- und DKIM-Setup, das beide Systeme abdeckt. Der Plesk-Forwarder für das Microsoft-Postfach schließt die Lücke in Gegenrichtung.

Die Praxis zeigt jedoch: Die Anleitung ist schnell abgearbeitet, die Fehlersuche im DNS und in den TLS-Details kostet dagegen Zeit. Nehmen Sie jetzt Kontakt auf – wir analysieren Ihre Situation und zeigen den nächsten Schritt.

Der Beitrag richtet sich an Geschäftsführer:innen, IT-Verantwortliche und technikaffine Administrator:innen in Kärntner KMU, die Microsoft 365 und einen eigenen Plesk-Mailserver kombinieren möchten oder müssen.