Exchange-Hybrid: Warum scheitert der Mail-Flow? Connector, Zertifikat, TLS und der Weg zur Diagnose

Welche Connectoren der HCW anlegt

Der Hybrid Configuration Wizard (HCW) erstellt für den Mailflow zwischen Exchange On-Premises und Exchange Online zwei Connectoren in Exchange Online (EOP) und mindestens einen Send Connector On-Premises. Er erzwingt dabei TLS mit Zertifikatsvalidierung. Ohne diese Connectoren funktioniert die Zustellung zwischen den Welten nicht zuverlässig.

In Exchange Online entstehen ein Inbound-Connector „von On-Premises“ (Quelle: On-Premises, Erkennung über Zertifikat oder – seltener – IP) und ein Outbound-Connector „zu On-Premises“ (Ziel: On-Premises, TLS mit Zertifikatsprüfung). On-Premises legt der HCW einen Send Connector „Outbound to Office 365“ an, der zum EOP-MX-Endpunkt (*.mail.protection.outlook.com) sendet und TLS per Zertifikat nutzt. Ein separater Receive Connector On-Premises ist in der Regel nicht erforderlich; die vorhandenen Frontend-Receive-Connectoren nehmen Verbindungen von EOP entgegen, sofern TLS und Zertifikat korrekt aktiv sind.

Option „Centralized Mail Transport“ (CMT): Aktiviert man CMT, leitet Exchange Online auch ausgehende Internetmails zurück an On-Premises (Outbound-Connector in EOP). Ohne CMT sendet Exchange Online externe Mails direkt ins Internet; der EOP-→On-Prem-Connector wird dann nur für Empfänger im On-Prem-Adressraum genutzt.

Zertifikats- und TLS-Anforderungen richtig prüfen

Für Hybrid-Mailflow verlangt Exchange Online eine erfolgreiche Zertifikatsprüfung. Das On-Prem-Zertifikat muss von einer öffentlichen vertrauenswürdigen CA stammen, für SMTP aktiviert sein, noch gültig sein und den erwarteten Namen im Subject oder in der SAN-Liste tragen (z. B. mail.firma.tld). Exchange Online akzeptiert ausschließlich TLS 1.2; TLS 1.0/1.1 werden verworfen.

• Exchange Online prüfen: Im neuen Exchange Admin Center → Nachrichtenfluss → Connectors den Inbound- und Outbound-Connector öffnen. Kontrollieren, dass „Immer TLS verwenden“ gesetzt ist, der Inbound-Connector „Durch Zertifikat prüfen“ verwendet und der erwartete Zertifikatsname hinterlegt ist (TlsSenderCertificateName). Beim Outbound-Connector muss TlsSettings=CertificateValidation und TlsDomain auf den On-Prem-Zertifikatsnamen zeigen.
• On-Premises Zertifikat prüfen: EAC On-Premises → Server → Zertifikate. Zertifikatstatus „Gültig“, Private Key vorhanden, Dienst „SMTP“ zugewiesen. Der Zertifikatsname (Subject/SAN) muss exakt mit den Werten in den EOP-Connectoren übereinstimmen.
• Sende-Connector On-Premises: In der Exchange Management Shell kontrollieren: Get-SendConnector „Outbound to Office 365“ | fl SmartHosts,Fqdn,TlsAuthLevel,TlsCertificateName,ProtocolLoggingLevel. SmartHosts muss auf den EOP-MX-Endpunkt zeigen; ProtocolLoggingLevel im Fehlerfall auf Verbose setzen.
• TLS 1.2: Auf den Exchange-Transport-Servern TLS 1.2 im Betriebssystem aktivieren und ältere Protokolle deaktivieren, falls Sicherheitsrichtlinien dies verlangen.

Schnelle Fehlersuche bei Warteschlangen und NDRs

• Message Trace in Exchange Online: Admin Center → Nachrichtenfluss → Nachrichtenablaufverfolgung. Auf Fehlercodes wie „TLS failed“, „451 4.4.0“ oder „Connector not found“ achten. Details zeigen häufig Zertifikatsnamen oder IP, gegen die geprüft wurde.
• Transport-/Protokoll-Logs On-Premises: Für den Send Connector: Set-SendConnector „Outbound to Office 365“ -ProtocolLoggingLevel Verbose. Für den relevanten Receive Connector: Set-ReceiveConnector „Default Frontend <Servername>“ -ProtocolLoggingLevel Verbose. Logs unter den in Get-TransportService ausgewiesenen Pfaden analysieren (SMTPReceive/SmtpSend).
• Firewall/IDS prüfen: Kein TLS-Inspection/SSL-Proxy zwischen EOP und Exchange. EOP-IP-Bereiche vollständig erlauben (eingehend und ausgehend), keine Port-25-NAT-Timeouts.
• Remote Connectivity Analyzer: Den „Office 365 SMTP“-Test gegen das On-Prem-Endpoint-Zertifikat ausführen, um SAN/Chain/Handshake zu validieren.

Drittanbieter-Spamfilter zwischen On-Prem und EOP

Geräte oder Cloud-Filter zwischen On-Premises und EOP verändern den Sichtpfad. Exchange Online sieht dann das Zertifikat des Filters – nicht das der Exchange-Server. Der Inbound-Connector in EOP muss entsprechend umgestellt werden (Zertifikat des Filters hinterlegen oder alternativ nach ausgehenden IPs des Filters scopen). Gleiches gilt für den EOP-Outbound-Connector: TlsDomain muss zum präsentierten Zertifikat des Filters passen.

• Isolieren: Testweise EOP ↔ On-Premises direkt verbinden (temporär Filter umgehen). Wenn der Fehler verschwindet, muss der Connector auf die Filter-Zertifikatsidentität bzw. IPs angepasst werden.
• Header-Integrität: Keine Manipulation oder Entfernung von Auth-/Routing-Headern (X-MS-Exchange-Organization-*) und keine STARTTLS-Entfernung zulassen.
• Schrittweise Umstellung: Zuerst EOP-Inbound auf Zertifikat/IP des Filters anpassen, dann EOP-Outbound, zuletzt den On-Prem-Send-Connector auf das korrekte Ziel (Filter oder EOP) ausrichten, um Loops zu vermeiden.

CN/SAN und TlsSenderCertificateName müssen zusammenpassen

In Hybrid-Umgebungen erzwingt Exchange Online für den Inbound-Connector aus On-Premises eine zertifikatsbasierte Authentifizierung. Entscheidend ist, dass der im Inbound-Connector hinterlegte Wert TlsSenderCertificateName exakt auf einen Namen im Zertifikat des On-Premises-SMTP-Servers zeigt – entweder auf den Subject (CN) oder einen Subject Alternative Name (SAN). Ein Mismatch führt zu erzwungenem TLS-Abbruch, auch wenn das Zertifikat technisch gültig ist.

Der Hybrid Configuration Wizard (HCW) liest beim Einrichten das gewählte SMTP-Zertifikat aus und setzt TlsSenderCertificateName in Exchange Online auf dessen Subject. Wird später das Zertifikat gewechselt (z. B. neuer CN), muss TlsSenderCertificateName entsprechend aktualisiert werden, sonst scheitern Verbindungen aus On-Premises zu Exchange Online mit Zertifikatsvalidierungsfehlern.

So wird geprüft – Schritt für Schritt

1. In Exchange Online PowerShell den Inbound-Connector prüfen: Get-InboundConnector „Inbound from “ | fl Name,RequireTls,TlsSenderCertificateName. Der Wert RequireTls sollte True sein, TlsSenderCertificateName muss dem Zertifikatsnamen entsprechen.
2. Auf dem On-Premises-Server das aktive SMTP-Zertifikat verifizieren: Get-ExchangeCertificate | fl Subject,NotAfter,Thumbprint,Services. SMTP muss auf dem gewünschten Zertifikat aktiviert sein.
3. Optional die Zuordnung für ausgehenden Hybrid-Mailflow prüfen: Get-SendConnector „Outbound to Office 365“ | fl Fqdn,TlsAuthLevel,TlsCertificateName,RequireTls. TlsAuthLevel sollte DomainValidation sein, RequireTls True, TlsCertificateName (falls gesetzt) auf das richtige Zertifikat zeigen.
4. Zertifikat extern inspizieren: openssl s_client -starttls smtp -connect mail.ihredomain.tld:25. CN/SAN, Gültigkeit und Kette prüfen.
5. Mit dem Microsoft Remote Connectivity Analyzer (Inbound SMTP Email) gegen die eigene Hybrid-Empfangsadresse testen. Der Test zeigt TLS-Version, präsentierten Zertifikatsnamen und Kettenfehler.

Wichtig: Der Connector-Wert TlsSenderCertificateName darf auf einen vollständigen FQDN oder die primäre SMTP-Domäne zeigen, solange dieser als CN oder SAN im Zertifikat enthalten ist. Klein-/Großschreibung ist unerheblich, Wildcards sollten vermieden werden, wenn ein exakter FQDN verfügbar ist.

Zertifikatskette, Ablaufdaten und Algorithmen

• Gültigkeit: NotAfter darf nicht überschritten sein; tauschen Sie Zertifikate rechtzeitig und aktualisieren Sie danach TlsSenderCertificateName.
• Kette: Alle Intermediate-Zertifikate müssen im Zertifikatspeicher „Zwischenzertifizierungsstellen“ installiert sein, damit der Server sie mitsendet. Fehlende Intermediates führen zu Chain-Build-Fehlern.
• Schlüsselstärke/Algorithmen: Mindestens RSA 2048 und SHA-256. Veraltete Hashes oder zu kurze Schlüssel werden verworfen.
• TLS-Versionen: Exchange Online verlangt TLS 1.2 oder höher. Stellen Sie sicher, dass auf dem Windows-Host TLS 1.2 aktiviert ist und unsichere Protokolle deaktiviert sind.

Wenn mehrere SMTP-fähige Zertifikate vorhanden sind, erzwingt die Eigenschaft TlsCertificateName am Send Connector das gewünschte Zertifikat. Ohne Festlegung kann der Server ein anderes präsentierbares Zertifikat senden, was zu Mismatches führt.

Typische SMTP/TLS-Fehler und Abhilfe

Transport- und Protokolllogs gezielt lesen

Relevante Pfade auf Exchange: Frontend-Receive-Logs unter …\TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive, ausgehende Verbindungen unter …\TransportRoles\Logs\Hub\ProtocolLog\SmtpSend. Nach Einträgen mit TLS, StartTLS, CertificateValidationFailed, ChainStatus, HandshakeFailure suchen. Oft enthalten die Logs den genauen Grund, z. B. NameMismatch oder PartialChain.

In Exchange Online hilft ein Message Trace bei der Eingrenzung, ob die Nachricht überhaupt bei EOP ankam. Fehlt sie dort, brach die Verbindung vor der Übergabe ab – Fokus auf On-Premises-Logs und Netzwerkpfad.

Sonderfall: Drittanbieter-Gateways

Vorgeschaltete Spamfilter oder Mail-Gateways müssen für den Hybrid-Flow entweder dasselbe vertrauenswürdige Zertifikat zu Exchange Online präsentieren oder im Connector explizit als zulässige Quelle per Zertifikatsnamen hinterlegt sein. TLS-Offloading, STARTTLS-Removal oder SNI-Umsetzungen an Gateways verursachen häufig Mismatches. Im Zweifel Pass-Through ohne Umbenennung und mit vollständiger Zertifikatskette konfigurieren.

Message Trace zielgerichtet einsetzen

Message Trace liefert in Hybrid-Umgebungen die schnellste Sicht darauf, wo eine Nachricht hängen bleibt – in Exchange Online (EOP), im On-Premises-Transport oder dazwischen. Entscheidend ist die Nachverfolgung über die Header-Message-ID sowie die Korrelation mit dem On-Prem-Tracking.

• In der neuen Exchange Admin Center Oberfläche: Mail flow > Message trace. Zeitraum eingrenzen, Absender/Empfänger angeben.
• Wenn vorhanden, die Header-Message-ID benutzen (z. B. aus NDR oder Originalkopfzeilen) und gezielt danach suchen.
• In den Trace-Details den “Event”-Pfad prüfen: Receive/Send, beteiligter Connector, ob TLS verlangt/angelegt wurde und ob eine Policy blockiert.
• Mit PowerShell korrelieren: In Exchange Online Get-MessageTrace -MessageId "<Header-ID>" und bei Bedarf Get-MessageTraceDetail -MessageTraceId <GUID> ausführen.
• On-Prem die gleiche Header-ID verwenden: Get-MessageTrackingLog -MessageId "<Header-ID>" -Start (Get-Date).AddDays(-2). So lassen sich Brüche zwischen On-Prem und EXO erkennen.

Transport- und Protokoll-Logs on‑prem analysieren

Für TLS- und Zertifikatsfehler liefern die SMTP-Protokoll-Logs die entscheidenden Hinweise. Aktivieren Sie Protokollierung auf den betroffenen Sende- und Empfangsconnectors und lesen Sie die Frontend- sowie Hub-Logs aus.

• Protokollierung aktivieren: Set-SendConnector "Outbound to Office 365" -ProtocolLoggingLevel Verbose und am Empfangsconnector, der Mails von EOP annimmt: Set-ReceiveConnector "<Name>" -ProtocolLoggingLevel Verbose.
• Log-Pfade: …\TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive und …\TransportRoles\Logs\Hub\ProtocolLog\SmtpSend.
• Nach Einträgen zu STARTTLS, Zertifikatsnamen, Handshake-Fehlern, temporären Fehlercodes (4.x) und dauerhaften Ablehnungen (5.x) filtern. Typisch sind Mismatches zwischen erwartetem und präsentiertem Zertifikatnamen.
• MessageTracking für End-to-End-Korrelation: Get-MessageTrackingLog -Recipients user@contoso.com -EventId SEND/RECEIVE -Start ....

Wenn der Outbound-Sendconnector zu Exchange Online TLS erzwingt, aber das lokale Zertifikat abgelaufen ist oder nicht den geforderten Namen enthält, zeigen die SMTP-Send-Logs detaillierte TLS-Negotiation-Fehler und abgelehnte EHLO-Sessions.

Remote Connectivity Analyzer gezielt nutzen

Der Remote Connectivity Analyzer (testconnectivity.microsoft.com) prüft aus dem Internet die Erreichbarkeit, TLS-Aushandlung und die Zertifikatskette.

• Test “Inbound SMTP Email” auswählen, Ziel-Domain oder MX/Smart Host angeben.
• Ergebnisblöcke zu Zertifikatskette, Hostname-Match (Subject/SAN) und TLS-Verfügbarkeit auswerten.
• Bei Fehlern mit den On-Prem-Protocol-Logs gegenprüfen und Connector-Settings anpassen (z. B. geforderter TLS-Name).

Drittanbieter-Filter als Fehlerquelle

Filter-Appliances oder Cloud-Gateways zwischen On-Prem und Exchange Online verändern oft EHLO, TLS-Parameter oder Zertifikatspräsentation. Das kollidiert mit den vom Hybrid Configuration Wizard gesetzten Connector-Annahmen.

• Connector-Abgleich: Inbound-Connector in EXO erwartet meist einen spezifischen Zertifikatnamen. Nutzt der Filter sein eigenes Zertifikat, den Connector auf IP-Validierung des Filter-Perimeters umstellen oder dem Filter das korrekte Zertifikat zuweisen.
• TLS-Erzwingung: Wenn der Filter nur opportunistisches TLS anbietet, am Connector kein erzwungenes TLS konfigurieren oder den Filter so konfigurieren, dass er verpflichtend TLS 1.2 mit passendem Zertifikat anbietet.
• Header-/Body-Scanning: Einige Filter verändern Kopfzeilen. Bei ausbleibender Zustellung Message Trace auf “Policy/Spam action” prüfen und gegebenenfalls Bypass-Regeln (z. B. IP Allow/Connector-Scope) setzen.