Prevent/Fix: Anleitung zur Konfiguration von lokalen Connectors

Lesezeit

3 Minuten

Die Inhalte auf dieser Seite wurden maschinell übersetzt.

Aktualisierte Anweisungen warnen davor, OnPremises-Eingangs-Connectoren mit Zertifikaten für Domains zu verwenden, die nicht vom Mandanten akzeptiert werden, oder IP-Adressen, die von mehreren Mandanten gemeinsam genutzt werden. Fehlkonfigurationen können den Mailfluss beeinträchtigen. Verwenden Sie eindeutige Clientzertifikate und Send-Connectoren pro Mandant und stellen Sie sicher, dass Drittanbieterdienste Zertifikate verwenden, die den akzeptierten Domains entsprechen.

Wir haben den Inhalt am 4. Februar 2026 aktualisiert. Vielen Dank für Ihre Geduld. 

Ursprünglich: Bitte fügen Sie hier keine Bilder ein. Fügen Sie Ihre hochauflösenden PNGs an die No-Reply-Bestätigungs-E-Mail an. Vielen Dank!

Wir wiederholen die Anleitung zu Connector-Einstellungen, um sicherzustellen, dass Kunden gesunde Konfigurationen verwenden. Die wichtigsten problematischen Konfigurationen, die wir sehen, sind:

  1. Wenn ein Mandant einen Inbound-Connector vom Typ OnPremises besitzt und der Connector eine zertifikatbasierte Authentifizierung mit einem Zertifikat durchführt, das einen Betreff/SAN für eine Domain enthält, die KEINE akzeptierte Domain des Mandanten ist.
  2. Wenn ein Mandant einen Inbound-Connector vom Typ OnPremises besitzt und der Connector eine IP-basierte Authentifizierung durchführt, die IP jedoch von On-Premises-Servern anderer Mandanten zur Verbindung mit Exchange Online verwendet wird.

Diese Anti-Muster treten typischerweise auf, wenn Sie einen Drittanbieterdienst verwenden, um E-Mails über Exchange Online zu relayen, können aber auch auftreten, wenn Ihre Organisation einen einzigen lokalen Exchange-Server verwendet, der mit mehreren Exchange Online-Mandanten verbunden ist.

Diese Konfigurationen können zu fehlerhaftem Mailfluss führen, da Exchange Online ein Multitenant-Dienst ist und für die Zuständigkeit der eingehenden Nachrichten auf deren Zuordnung angewiesen ist. Wenn Nachrichten über einen Inbound-Connector vom Typ OnPremises empfangen werden, erfolgt die Zuordnung nach folgender Prioritätsreihenfolge:

  1. Die Domain im TLS-Zertifikat, das vom sendenden Server präsentiert wird
  2. Die P1 MailFrom (Envelope-Sender) Domain
  3. Die P1 RcptTo (Empfänger) Domain

Wie sich das auf Ihre Organisation auswirkt:

Wir können interne Änderungen vornehmen, wie etwa Mandantenverschiebungen, ohne Vorankündigung, was den Mailfluss beeinträchtigen kann, wenn ein Mandant eine fehlerhafte Connector-Konfiguration hat. Das bedeutet, ein heute funktionierender falsch konfigurierter Connector kann unerwartet nicht mehr funktionieren.

Was Sie zur Vorbereitung tun müssen:

Wenn Sie einen einzelnen lokalen Exchange-Server verwenden, der mit mehreren Exchange Online-Mandanten verbunden ist, muss Ihre lokale Exchange-Umgebung für jeden eindeutigen Exchange Online-Mandanten, der zu Ihrer Organisation gehört, ein eindeutiges Clientzertifikat zum Senden verwenden. Sie müssen für jeden eindeutigen Mandanten in Exchange Online, an den Sie lokalen Datenverkehr weiterleiten wollen, einen eindeutigen Send Connector vor Ort konfigurieren: Send connectors in Exchange Server | Microsoft Learn. Außerdem sollten Sie bevorzugt Inbound-Connectoren vom Typ OnPremises in Exchange Online so konfigurieren, dass sie zertifikatbasierte statt IP-basierte Authentifizierung verwenden. Für beste Leistung sollten die Inbound-Connectoren in Exchange Online auf das eindeutige Clientzertifikat verweisen, das für diesen Connector-Pfad bestimmt ist.

Wenn Sie einen Drittanbieter-Add-on-Dienst verwenden müssen, um E-Mail-Nachrichten aus Ihrer Organisation zu verarbeiten und dann über Exchange Online zu relayen, muss der Drittanbieterdienst ein eindeutiges Zertifikat für Ihre Organisation unterstützen, und die Zertifikatdomain (im Subject Name oder SAN) muss eine akzeptierte Domain Ihrer Organisation sein. Zusätzlich müssen Sie Ihren Inbound-Connector vom Typ OnPremises aktualisieren, um die eindeutige Zertifikatdomain über die Eigenschaft TlsSenderCertificateName zu verwenden. Ein Beispiel hierfür ist, dass Ihre Organisation einen Drittanbieter-CRM-Cloud-Dienst verwendet, um E-Mails im Namen Ihrer Organisation an Postfächer Ihres Unternehmens oder andere externe Benutzer zu senden. Weitere Informationen finden Sie unter Szenario: Integrate Exchange Online with an email add-on service.

Wir sind für Sie da

Haben Sie Fragen oder benötigen Sie Unterstützung? Wir helfen gerne weiter.