SMTP-TLS für Microsoft 365

Microsoft 365 erzwingt seit Oktober 2018 mindestens TLS 1.2 und nutzt standardmäßig opportunistisches TLS. Für regulierte Partner können Sie Forced-TLS-Connectors mit Zertifikatsvalidierung anlegen — ohne Eingriff in die Mailserver-Infrastruktur.

SMTP-TLS prüfen Plattform entdecken

Microsoft 365 · SMTP-TLS-Anleitung

Von Wolf-Agents Security Team · Aktualisiert: 12. Mai 2026

SMTP-TLS bei Microsoft 365 (Exchange Online)

Microsoft 365 verwaltet die TLS-Konfiguration der MX-Hosts unter *.mail.protection.outlook.com vollständig — TLS 1.2 ist Mindestversion, opportunistisches TLS ist Default. Sie können die TLS-Parameter nicht selbst ändern, aber Forced-TLS-Connectors für regulierte Partner konfigurieren. Microsoft Learn dokumentiert: "Exchange Online servers always encrypt connections to other Exchange Online servers in our data centers with TLS 1.2."

Das Zertifikat der Microsoft-MX-Hosts wird von DigiCert ausgestellt, ist auf mail.protection.outlook.com registriert und automatisch erneuert (Stand der aktuellen Doku: gültig seit 24. September 2020). Der Wolf-Agents Email Security Scanner prüft pro MX-Host Ihrer Domain den STARTTLS-Support, die TLS-Version, die Cipher-Stärke nach BSI TR-02102-2 und die Zertifikats-Kette zeichengenau — er erkennt sofort, wenn ein MX-Eintrag versehentlich auf einen Nicht-Microsoft-Host zeigt (typischer Fehler nach Migration: ein Legacy-Connector hängt im DNS, das Zertifikat passt nicht zum erwarteten Hostnamen).

Zertifikatsdetails für Forced-TLS-Connector-Partner

Microsoft veröffentlicht die Zertifikatsdaten für die Exchange-Online-MX-Hosts in Microsoft Learn — Partner-Organisationen, die mit TlsSettings DomainValidation auf Microsoft 365 zustellen, können diese Werte zur Trust-Path-Konfiguration nutzen. Stand der Doku: aktualisiert 9. Dezember 2025.

Certificate Authority Root Issuer: DigiCert CA - 1
Certificate Name (Subject): mail.protection.outlook.com
Organization: Microsoft Corporation
Organization Unit: www.digicert.com
Certificate Key Strength: 2048 Bit (RSA — laut Microsoft-Tabelle ohne explizite Algorithmus-Angabe, RSA über die DigiCert-CA-1-Hierarchie typisch)
Gültig seit (Fließtext-Hinweis): 24. September 2020 (Microsoft-Lerntext: „The current certificate is valid from September 24, 2020“)
Renewal (Microsoft-Zusatzaussage): Microsoft-managed — kein Kunden-Eingriff nötig (Microsoft-Lerntext: „For security reasons, our certificates do change from time to time“)

Quelle: Microsoft Learn — How Exchange Online uses TLS to secure email connections (Abruf 12. Mai 2026, Doku-Stand 9. Dezember 2025). Die ersten fünf Felder stammen aus der Microsoft-Tabelle „Current certificate information valid from September 24, 2020“, die beiden Zusatzangaben (Gültig seit, Renewal) aus dem umgebenden Fließtext. Microsoft weist explizit darauf hin: „For security reasons, our certificates do change from time to time“ — die Werte sollten vor jedem Connector-Setup verifiziert werden.

Für die Compliance-Triple (NIS2 Art. 21 Abs. 2 Buchstabe h zur Kryptografie, BSI TR-03108 zum sicheren E-Mail-Transport, DSGVO Art. 32 Abs. 1 Buchstabe a zur Verschlüsselung als technische Maßnahme) liefert Microsoft 365 zwei prüfbare Nachweise: Erstens den Message Trace im Exchange Admin Center, der pro E-Mail die genutzte TLS-Version und Cipher-Suite zeigt; zweitens die Forced-TLS-Connector-Konfiguration, die mit TlsSettings DomainValidation auch die Zertifikats-Validierung gegen die Empfänger-Domain erzwingt. Wolf-Agents empfiehlt für Microsoft 365 die Ergänzung um MTA-STS — damit erzwingen Sie TLS-Verschlüsselung auch gegenüber sendenden Servern, ohne pro Partner einen Connector anlegen zu müssen.

Ausführliche SMTP-TLS-Einführung

1 Schritt 1 von 3

TLS-Status der Microsoft-MX-Hosts prüfen

Bestätigen Sie, dass die MX-Hosts Ihrer Domain auf *.mail.protection.outlook.com auflösen und der STARTTLS-Handshake mit TLS 1.2 oder TLS 1.3 erfolgreich ist. Microsoft Learn stellt klar: TLS 1.0 und 1.1 sind seit dem 31. Oktober 2018 deprecated und seit 2022 vollständig entfernt — alle Verbindungen mit Microsoft 365 nutzen mindestens TLS 1.2.

Der konkrete MX-Hostname Ihres Tenants folgt dem Muster ihre-domain-de.mail.protection.outlook.com (Bindestriche statt Punkte in der Tenant-Subdomain). Verwenden Sie im openssl-Befehl den Parameter -servername, damit SNI im TLS-Handshake gesendet wird — sonst antwortet Microsoft mit einem generischen Zertifikat statt dem Tenant-spezifischen.

# TLS-Version und Cipher des Microsoft-MX-Hosts prüfen
echo | openssl s_client \
  -connect ihre-domain-de.mail.protection.outlook.com:25 \
  -starttls smtp \
  -servername ihre-domain-de.mail.protection.outlook.com \
  2>/dev/null | grep -E "Protocol|Cipher|subject|issuer"

# Erwartete Ausgabe:
# Protocol  : TLSv1.2  (oder TLSv1.3)
# Cipher    : ECDHE-RSA-AES256-GCM-SHA384
# subject=CN = mail.protection.outlook.com
# issuer=C = US, O = DigiCert Inc, CN = DigiCert CA - 1

# MX-Hosts Ihrer Domain ermitteln (Linux/macOS)
dig MX ihre-domain.de +short

# Windows (PowerShell)
Resolve-DnsName -Name ihre-domain.de -Type MX | Select-Object NameExchange, Preference

2 Schritt 2 von 3

Forced-TLS-Connector für regulierte Partner konfigurieren

Standard-Mailfluss bei Microsoft 365 nutzt opportunistic TLS — wenn der Empfangsserver kein TLS anbietet, fällt Exchange Online auf Klartext zurück. Für Banken, Behörden und Healthcare-Partner mit Compliance-Pflicht legen Sie einen Outbound-Connector mit TlsSettings DomainValidation an: Exchange Online erzwingt dann TLS plus Zertifikats-Validierung und lehnt die Zustellung ab, wenn der Empfänger nicht beide Bedingungen erfüllt.

Die Konfiguration erfolgt entweder über das Exchange Admin Center (admin.exchange.microsoft.com → Mail Flow → Connectors → Add a Connector) oder per PowerShell mit dem Cmdlet New-OutboundConnector. Das PowerShell-Setup ist reproduzierbar und versionierbar — empfohlen für Multi-Tenant-Setups oder Audit-Trails. Wichtig: TlsSettings DomainValidation erfordert einen TlsDomain-Parameter — das Wildcard-Muster (z.B. *.partner-bank.de) muss mit dem SAN/CN-Eintrag des Empfänger-Zertifikats übereinstimmen.

# Forced-TLS Outbound-Connector via Exchange Online PowerShell
Connect-ExchangeOnline -UserPrincipalName admin@ihre-domain.de

New-OutboundConnector \
  -Name "Forced TLS to Partner Bank AG" \
  -ConnectorType Partner \
  -RecipientDomains @("partner-bank.de") \
  -UseMXRecord $true \
  -TlsSettings DomainValidation \
  -TlsDomain "*.partner-bank.de" \
  -IsTransportRuleScoped $false

# Verifizieren
Get-OutboundConnector -Identity "Forced TLS to Partner Bank AG" | \
  Select-Object Name, TlsSettings, TlsDomain, RecipientDomains

Connector-TLS-Modi (TlsSettings-Parameter)

EncryptionOnly: Erzwingt TLS-Verschlüsselung, prüft aber das Zertifikat nicht. Verhindert Klartext, aber kein Schutz vor MitM mit gefälschtem Zertifikat
CertificateValidation: Erzwingt TLS plus Validierung gegen eine vertrauenswürdige CA — gleichwertig zum normalen Browser-Vertrauen
DomainValidation (empfohlen): TLS plus CA-Validierung plus Hostname-Match gegen den TlsDomain-Parameter — strengste Variante, vergleichbar mit MTA-STS enforce für genau diese Partner-Domain

3 Schritt 3 von 3

TLS pro Zustellung per Message Trace verifizieren

Der Message Trace im Exchange Admin Center (oder per PowerShell-Cmdlet Get-MessageTraceDetail) zeigt für jede ausgehende E-Mail die genutzte TLS-Version, den Cipher und ob das Zertifikat validiert wurde. Das ist Ihr DSGVO-Art.-32-Nachweis: Bei einem Audit können Sie pro Datum, Absender und Empfänger belegen, dass die Übertragung verschlüsselt erfolgte.

Bei einem aktiven Forced-TLS-Connector erscheint im Trace zusätzlich der Status TlsRequired mit dem Connector-Namen. Wenn der Empfangsserver kein TLS oder ein ungültiges Zertifikat anbietet, sehen Sie statt einer erfolgreichen Zustellung ein FailedToConnect-Event mit dem TLS-Grund — die E-Mail wird nicht zugestellt, was bei Compliance-relevanten Empfängern gewollt ist.

# Message Trace per PowerShell — TLS-Version pro Zustellung
Get-MessageTrace \
  -SenderAddress "rechnung@ihre-domain.de" \
  -StartDate (Get-Date).AddDays(-7) \
  -EndDate (Get-Date)

# Detail-Ansicht zeigt EncryptionType: TLS und Cipher
Get-MessageTraceDetail \
  -MessageTraceId "abc123-..." \
  -RecipientAddress "kontakt@partner-bank.de"

Auth-Komplement: SMTP-AUTH Basic Authentication wird 2026 abgeschaltet

Microsoft hat in der offiziellen Exchange-Online-Doku angekündigt: Basic Authentication für SMTP-AUTH (Client Submission auf Port 587) wird im Jahr 2026 endgültig entfernt. Microsoft Learn nennt als Datum "March 2026" — eine ergänzende Microsoft-Tech-Community-Ankündigung erwähnt eine gestaffelte Deaktivierung mit erweiterten Phasen bis Dezember 2026/2027. Betroffen ist ausschließlich die Submission-Authentifizierung mit Benutzername/Passwort, NICHT die Server-zu-Server-SMTP-TLS-Verbindung auf Port 25.

Was bedeutet das für SMTP-TLS? SMTP-TLS auf Port 25 (MTA-zu-MTA) ist nicht betroffen — Server-zu-Server-Verschlüsselung bleibt unverändert. Betroffen sind nur Anwendungen, Geräte oder Skripte, die per Port 587 mit Username/Password-Auth gegen Exchange Online Mails versenden (typisch: Multifunktionsdrucker, Legacy-Monitoring-Skripte, Line-of-Business-Anwendungen ohne OAuth). Microsoft empfiehlt drei Migrationspfade: OAuth 2.0 mit Microsoft-Graph-API für Anwendungs-Code, "High Volume Email" für massenhafte System-Mails oder "Azure Communication Services for Email" für Transaktions-Mails. Die Wolf-Agents-Empfehlung: Inventarisieren Sie aktive Geräte/Skripte über das Sign-in-Activity-Log in Microsoft Entra (Filter "Legacy Authentication") und migrieren Sie sukzessive auf OAuth, bevor die Microsoft-Frist greift.

Quellen: Microsoft Learn — Deprecation of Basic authentication in Exchange Online (Abruf 12. Mai 2026, Doku-Stand 28. Juli 2025) plus Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline (Microsoft Tech Community).

Häufige SMTP-TLS-Probleme bei Microsoft 365

Die folgenden drei Probleme treten bei Microsoft-365-Setups besonders häufig auf. Sie betreffen entweder die Connector-Konfiguration (zu strenge oder zu lockere TLS-Settings), die Zertifikats-Erwartungen an Partner-Domains oder die Sichtbarkeit von Klartext-Zustellungen in opportunistic-TLS-Mailflüssen.

Outbound-Connector mit Smart Host und TlsSettings ohne TlsDomain

Symptom: Der PowerShell-Befehl New-OutboundConnector mit TlsSettings DomainValidation schlägt fehl mit "TlsDomain parameter is required when TlsSettings is DomainValidation". Bei UI-Konfiguration ohne TlsDomain greift Microsoft auf CertificateValidation zurück — die Hostname-Validierung fehlt.

Ursache: Die DomainValidation-Variante verlangt explizit ein FQDN oder Wildcard, gegen das das Empfänger-Zertifikat geprüft wird. Ohne diesen Parameter kann Microsoft das Zertifikat zwar gegen die CA validieren, aber nicht prüfen, ob der Hostname zum Empfänger passt.

Lösung: Setzen Sie -TlsDomain "*.partner-domain.de" oder eine konkrete Hostname-Liste. Verifizieren Sie mit Get-OutboundConnector | fl TlsSettings, TlsDomain. Wenn Sie mehrere Empfangs-Hostnamen haben, listen Sie alle Wildcards getrennt — Microsoft akzeptiert mehrere TlsDomain-Werte.

Partner-Mailserver akzeptiert nur TLS 1.0 — Zustellung scheitert

Symptom: Bei einem Forced-TLS-Connector zu einem Legacy-Partner bleiben E-Mails in der Queue. Message Trace zeigt FailedToConnect mit Grund "TLS negotiation failed" oder "Remote certificate failed validation".

Ursache: Microsoft 365 hat TLS 1.0 und 1.1 seit Oktober 2018 deprecated. Bei einem Forced-TLS-Connector gibt es keinen Fallback auf eine schwächere TLS-Version — die Verbindung schlägt fehl, wenn der Partner nicht mindestens TLS 1.2 unterstützt.

Lösung: Bitten Sie den Partner um TLS-1.2-Upgrade des Mailservers (Postfix-3.x, Exim-4.99 oder Exchange-Server-2019 CU15 unterstützen TLS 1.2 standardmäßig). Falls das nicht möglich ist und der Partner aus Compliance-Sicht nicht zwingend Forced-TLS braucht, deaktivieren Sie den Connector für diese Domain und nutzen opportunistic TLS — Microsoft 365 stellt dann auf TLS 1.2/1.3 zu, wenn möglich.

Opportunistic-TLS-Fallback auf Klartext — DSGVO-Risiko

Symptom: E-Mails zu manchen externen Empfängern werden im Klartext übertragen (Message Trace zeigt EncryptionType: Clear). Das Risiko: Personenbezogene Daten in Rechnungen, Verträgen oder HR-Mails verlassen unverschlüsselt das Exchange-Online-Netz.

Ursache: Microsofts Default-Konfiguration ist opportunistic TLS — wenn der Empfangsserver kein STARTTLS anbietet, sendet Exchange Online im Klartext. Das ist sinnvoll für die globale E-Mail-Erreichbarkeit, aber für DSGVO-relevante Kommunikation unzureichend.

Lösung: Identifizieren Sie regelmäßig Klartext-Zustellungen mit Get-MessageTrace | Where-Object {$_.EncryptionType -eq "Clear"}. Für regulierte Partner-Domains legen Sie Forced-TLS-Connectors an. Ergänzend setzen Sie auf MTA-STS für Ihre eigene Empfangsseite — der Wolf-Agents Email Security Scanner erkennt fehlende Verschlüsselungs-Trends in den TLS-RPT-Reports und alarmiert vor einer Klartext-Häufung.

NIS2, BSI TR-03108 und DSGVO Art. 32: Microsoft 365 mit Forced TLS

NIS2 Art. 21 Abs. 2 Buchstabe h fordert den Einsatz von Kryptografie und Verschlüsselung als grundlegende Cybersecurity-Maßnahme — Microsoft 365 erfüllt das mit opportunistic TLS standardmäßig und mit Forced-TLS-Connectors für regulierte Mailflüsse. Die BSI TR-03108 verlangt sicheren E-Mail-Transport mit mindestens TLS 1.2 plus Perfect Forward Secrecy — beide Anforderungen erfüllt Exchange Online seit der TLS-1.0/1.1-Deprecation im Oktober 2018. DSGVO Art. 32 Abs. 1 Buchstabe a nennt Verschlüsselung als technische Maßnahme: Der Message Trace im Exchange Admin Center (Mail Flow → Message Trace) dokumentiert pro E-Mail die TLS-Version und den Cipher — auditierbar für sieben Jahre. Das DigiCert-Zertifikat der MX-Hosts mail.protection.outlook.com wird von Microsoft automatisch erneuert; Kunden müssen keine eigenen Zertifikate verwalten. Der Wolf-Agents Email Security Scanner bewertet SMTP-TLS mit 5 von 165 Punkten und prüft Zertifikat, TLS-Version, Cipher-Stärke nach BSI TR-02102-2 und Chain-Vollständigkeit zeichengenau pro MX-Host.

M365 Connector-Modi — Opportunistic vs. Force-TLS (Multimodal)

Microsoft 365 (Microsoft Corporation, Redmond, Washington, USA) erlaubt drei Connector-Modi: Opportunistic (Standard, Best-Effort), Force-TLS mit DomainValidation und Force-TLS mit CertificateValidation. Die Visualisierung zeigt die Entscheidungslogik pro Empfängerdomain und die Compliance-Implikationen für regulierte Partner.

SMTP-TLS-Anleitung auch für:

Google Workspace IONOS Strato All-Inkl Hetzner Postfix Exim Generisch

Wie steht Ihre Domain bei SMTP-TLS?

Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.

E-Mail Security Check starten