Funktionsweise der DNS-basierten SMTP-Authentifizierung benannter Entitäten (DANE)
Das SMTP-Protokoll ist das Standard Protokoll, das zum Übertragen von Nachrichten zwischen E-Mail-Servern verwendet wird, und ist standardmäßig nicht sicher. Das TLS-Protokoll (Transport Layer Security) wurde vor Jahren eingeführt, um die verschlüsselte Übertragung von Nachrichten über SMTP zu unterstützen. Es wird häufig opportunistisch und nicht als Anforderung verwendet und hinterlässt viel E-Mail-Datenverkehr in Klartext, anfällig für Abfangen durch böswillige Akteure. Darüber hinaus bestimmt SMTP die IP-Adressen von Zielservern über die öffentliche DNS-Infrastruktur, die anfällig für Spoofing- und Man-in-the-Middle-Angriffe (MITM) ist. Diese Sicherheitsanfälligkeit hat dazu geführt, dass viele neue Standards geschaffen wurden, um die Sicherheit für das Senden und Empfangen von E-Mails zu erhöhen. Einer dieser Standards ist DNS-basierte Authentifizierung benannter Entitäten (DANE).
DANE für SMTP RFC 7672 verwendet das Vorhandensein eines TLSA-Eintrags (Transport Layer Security Authentication) im DNS-Eintragssatz einer Domäne, um eine Domäne und deren Mailserver dane zu signalisieren. Wenn kein TLSA-Eintrag vorhanden ist, funktioniert die DNS-Auflösung für den E-Mail-Fluss wie gewohnt, ohne dass eine DANE-Überprüfung versucht wird. Der TLSA-Eintrag signalisiert tls-Unterstützung sicher und veröffentlicht die DANE-Richtlinie für die Domäne. So können sendende E-Mail-Server mithilfe von SMTP DANE erfolgreich legitime Empfangende E-Mail-Server authentifizieren. Diese Authentifizierung macht sie resistent gegen Downgrade- und MITM-Angriffe. DANE verfügt über direkte Abhängigkeiten von DNSSEC, die durch digitales Signieren von Datensätzen für DNS-Lookups mithilfe von Kryptografie mit öffentlichem Schlüssel funktioniert. DNSSEC-Überprüfungen erfolgen auf rekursiven DNS-Resolvern, den DNS-Servern, die DNS-Abfragen für Clients durchführen. DNSSEC stellt sicher, dass DNS-Einträge nicht manipuliert und authentisch sind.
Sobald die MX-, A/AAAA- und DNSSEC-bezogenen Ressourceneinträge für eine Domäne als DNSSEC-authentisch an den rekursiven DNS-Resolver zurückgegeben werden, fragt der sendende E-Mail-Server nach dem TLSA-Eintrag, der dem Eintrag oder den Einträgen des MX-Hosts entspricht. Wenn der TLSA-Eintrag vorhanden und mithilfe einer anderen DNSSEC-Überprüfung als authentisch erwiesen ist, gibt der rekursive DNS-Resolver den TLSA-Eintrag an den sendenden E-Mail-Server zurück.
Nachdem der authentische TLSA-Eintrag empfangen wurde, stellt der sendende E-Mail-Server eine SMTP-Verbindung mit dem MX-Host her, der dem authentischen TLSA-Eintrag zugeordnet ist. Der sendende E-Mail-Server versucht, TLS einzurichten und das TLS-Zertifikat des Servers mit den Daten im TLSA-Eintrag zu vergleichen, um zu überprüfen, ob der mit dem Absender verbundene Ziel-E-Mail-Server der legitime Empfangende E-Mail-Server ist. Die Nachricht wird (mit TLS) übertragen, wenn die Authentifizierung erfolgreich ist. Wenn die Authentifizierung fehlschlägt oder TLS vom Zielserver nicht unterstützt wird, wird Exchange Online den gesamten Überprüfungsprozess wiederholen, beginnend mit einer DNS-Abfrage für dieselbe Zieldomäne nach 15 Minuten und dann nach 15 Minuten und dann nach 15 Minuten und dann stündlich für die nächsten 24 Stunden. Wenn die Authentifizierung nach 24 Stunden wiederholter Wiederholung weiterhin fehlschlägt, läuft die Nachricht ab, und ein NDR mit Fehlerdetails wird generiert und an den Absender gesendet.
Tipp
Wenn Sie kein E5-Kunde sind, verwenden Sie die 90-tägige Testversion von Microsoft Purview-Lösungen, um zu erfahren, wie zusätzliche Purview-Funktionen Ihre organization die Verwaltung von Datensicherheits- und Complianceanforderungen unterstützen können. Beginnen Sie jetzt im Microsoft Purview-Complianceportal Testversionshub. Erfahren Sie mehr über die Anmelde- und Testbedingungen.
Was sind die Komponenten von DANE?
TLSA-Ressourceneintrag
Der TLSA-Eintrag (TLSA) wird verwendet, um das X.509-Zertifikat oder den Wert des öffentlichen Schlüssels eines Servers dem Domänennamen zuzuordnen, der den Datensatz enthält. TLSA-Einträge können nur vertrauenswürdig sein, wenn DNSSEC für Ihre Domäne aktiviert ist. Wenn Sie einen DNS-Anbieter zum Hosten Ihrer Domäne verwenden, kann die DNSSEC eine Einstellung sein, die beim Konfigurieren einer Domäne mit ihnen angeboten wird. Weitere Informationen zur DNSSEC-Zonensignierung finden Sie unter diesem Link: Übersicht über DNSSEC | Microsoft-Dokumentation.
TlsA-Beispieldatensatz:
Es gibt vier konfigurierbare Felder, die für den TLSA-Datensatztyp eindeutig sind:
Zertifikatverwendungsfeld: Gibt an, wie der sendenden E-Mail-Server das Zertifikat des Ziel-E-Mail-Servers überprüfen soll.
| Wert | Akronym | Description |
|---|---|---|
| 01 | PKIX-TA | Das verwendete Zertifikat ist die öffentliche Vertrauensankerzertifizierungsstelle aus der X.509-Vertrauenskette. |
| 11 | PKIX-EE | Geprüftes Zertifikat ist der Zielserver; DNSSEC-Überprüfungen müssen ihre Authentizität überprüfen. |
| 2 | DANE-TA | Verwenden Sie den privaten Schlüssel des Servers aus der X.509-Struktur, der von einem Vertrauensanker in der Vertrauenskette überprüft werden muss. Der TLSA-Eintrag gibt den Vertrauensanker an, der zum Überprüfen der TLS-Zertifikate für die Domäne verwendet werden soll. |
| 3 | DANE-EE | Übereinstimmung nur mit dem Zertifikat des Zielservers. |
1 Exchange Online den RFC-Implementierungsleitfaden befolgt, dass Werte des Zertifikatverwendungsfelds 0 oder 1 nicht verwendet werden sollten, wenn DANE mit SMTP implementiert wird. Wenn ein TLSA-Datensatz mit dem Feldwert Zertifikatverwendung von 0 oder 1 an Exchange Online zurückgegeben wird, wird er von Exchange Online als nicht verwendbar behandelt. Wenn alle TLSA-Einträge als unbrauchbar eingestuft werden, führen Exchange Online beim Senden der E-Mail nicht die DANE-Überprüfungsschritte für 0 oder 1 aus. Stattdessen erzwingen Exchange Online aufgrund des Vorhandenseins eines TLSA-Eintrags die Verwendung von TLS zum Senden der E-Mail, das Senden der E-Mail, wenn der Ziel-E-Mail-Server TLS unterstützt, oder das Löschen der E-Mail und generieren einen NDR, wenn der Ziel-E-Mail-Server TLS nicht unterstützt.
Im BEISPIEL-TLSA-Eintrag ist das Feld "Zertifikatverwendung" auf "3" festgelegt, sodass die Zertifikatzuordnungsdaten ('abc123... xyz789') würde nur mit dem Zertifikat des Zielservers abgeglichen werden.
Auswahlfeld: Gibt an, welche Teile des Zertifikats des Zielservers überprüft werden sollen.
| Wert | Akronym | Beschreibung |
|---|---|---|
| 0 | Cert | Verwenden Sie das vollständige Zertifikat. |
| 1 | SPKI (Informationen zum öffentlichen Schlüssel des Antragstellers) | Verwenden Sie den öffentlichen Schlüssel des Zertifikats und den Algorithmus, mit dem der öffentliche Schlüssel identifiziert wird. |
Im TLSA-Beispieleintrag ist das Auswahlfeld auf "1" festgelegt, sodass die Zertifikatzuordnungsdaten mithilfe des öffentlichen Schlüssels des Zielserverzertifikats und dem Algorithmus abgeglichen werden, mit dem der öffentliche Schlüssel verwendet werden soll.
Übereinstimmende Typfeld: Gibt das Format an, in dem das Zertifikat im TLSA-Eintrag dargestellt wird.
| Wert | Akronym | Beschreibung |
|---|---|---|
| 0 | Vollständig | Die Daten im TSLA-Datensatz sind das vollständige Zertifikat oder die SPKI. |
| 1 | SHA-256 | Die Daten im TSLA-Datensatz sind ein SHA-256-Hash des Zertifikats oder der SPKI. |
| 2 | SHA-512 | Die Daten im TSLA-Datensatz sind ein SHA-512-Hash des Zertifikats oder der SPKI. |
Im TLSA-Beispieldatensatz ist das übereinstimmende Typfeld auf "1" festgelegt, sodass die Zertifikatzuordnungsdaten ein SHA-256-Hash der Informationen zum öffentlichen Schlüssel des Antragstellers aus dem Zielserverzertifikat sind.
Zertifikatzuordnungsdaten: Gibt die Zertifikatdaten an, die für den Abgleich mit dem Zielserverzertifikat verwendet werden. Diese Daten hängen vom Wert des Auswahlfelds und dem übereinstimmenden Typwert ab.
Im TLSA-Beispieldatensatz sind die Zertifikatzuordnungsdaten auf "abc123" festgelegt. xyz789'. Da der Wert selector Field im Beispiel auf "1" festgelegt ist, verweist er auf den öffentlichen Schlüssel des Zielserverzertifikats und den Algorithmus, der für die Verwendung identifiziert wird. Und da der Wert des Übereinstimmenden Typs im Beispiel auf "1" festgelegt ist, würde er auf den SHA-256-Hash der Informationen zum öffentlichen Antragstellerschlüssel aus dem Zielserverzertifikat verweisen.
Wie können Exchange Online Kunden SMTP DANE Outbound verwenden?
Als Exchange Online Kunden müssen Sie nichts tun, um diese erweiterte E-Mail-Sicherheit für Ihre ausgehenden E-Mails zu konfigurieren. Diese erweiterte E-Mail-Sicherheit haben wir für Sie entwickelt und ist standardmäßig für alle Exchange Online Kunden aktiviert und wird verwendet, wenn die Zieldomäne Unterstützung für DANE ankündigen. Um von den Vorteilen des Sendens von E-Mails mit DNSSEC- und DANE-Überprüfungen zu profitieren, teilen Sie Ihren Geschäftspartnern, mit denen Sie E-Mails austauschen, dass sie DNSSEC und DANE implementieren müssen, damit sie E-Mails nach diesen Standards empfangen können.
Wie können Exchange Online Kunden SMTP DANE eingehend verwenden?
Derzeit wird eingehende SMTP-DANE für Exchange Online nicht unterstützt. Unterstützung für eingehende SMTP-DANE wird in naher Zukunft verfügbar sein.
Was ist die empfohlene Konfiguration des TLSA-Eintrags?
Gemäß rfc-Implementierungsleitfaden für SMTP DANE wird ein TLSA-Eintrag empfohlen, der aus dem Auf 3 festgelegten Feld Zertifikatverwendung, dem Selector-Feld auf 1 und dem Feld Übereinstimmender Typ auf 1 besteht.
Exchange Online Nachrichtenfluss mit SMTP DANE
Der E-Mail-Flussprozess für Exchange Online mit SMTP-DANE, der im Flussdiagramm unten dargestellt ist, überprüft die Sicherheit von Domänen- und Ressourcendatensätzen über DNSSEC, TLS-Unterstützung auf dem Ziel-E-Mail-Server und ob das Zertifikat des Ziel-E-Mail-Servers basierend auf dem zugehörigen TLSA-Eintrag den Erwartungen entspricht.
Es gibt nur zwei Szenarien, in denen ein SMTP-DANE-Fehler dazu führt, dass die E-Mail blockiert wird:
Die Signalisierung von DNSSEC der Zieldomäne, aber mindestens ein Datensatz wurde als nicht authentifiziert zurückgegeben.
Alle MX-Einträge für die Zieldomäne verfügen über TLSA-Einträge, und keines der Zertifikate des Zielservers entspricht den Erwartungen gemäß den TSLA-Datensatzdaten, oder eine TLS-Verbindung wird vom Zielserver nicht unterstützt.
Verwandte Technologien
| Technologie | Weitere Informationen |
|---|---|
| Mail Transfer Agent – Strict Transport Security (MTA-STS) hilft, Downgrade- und Man-in-the-Middle-Angriffe zu verhindern, indem ein Mechanismus zum Festlegen von Domänenrichtlinien bereitgestellt wird, die angeben, ob der Ziel-E-Mail-Server TLS unterstützt und was zu tun ist, wenn TLS nicht ausgehandelt werden kann, z. B. die Übertragung beenden. | Weitere Informationen zur anstehenden Unterstützung für ein- und ausgehende MTA-STS von Exchange Online werden später in diesem Jahr veröffentlicht. Exchange Online Transport News von der Microsoft Ignite 2020 – Microsoft Tech Community rfc8461 (ietf.org) |
| Sender Policy Framework (SPF) verwendet IP-Informationen, um sicherzustellen, dass Ziel-E-Mail-Systeme nachrichten vertrauen, die von Ihrer benutzerdefinierten Domäne gesendet werden. | Wie Sender Policy Framework (SPF) Spoofing verhindert |
| DomainKeys Identified Mail (DKIM) verwendet X.509-Zertifikatinformationen, um sicherzustellen, dass Ziel-E-Mail-Systeme ausgehenden Nachrichten vertrauen, die von Ihrer benutzerdefinierten Domäne gesendet werden. | Verwenden von DKIM für E-Mail in Ihrer benutzerdefinierten Domäne |
| Domänenbasierte Nachrichtenauthentifizierung, Berichterstellung und Konformität (DMARC) arbeitet mit Sender Policy Framework und DomainKeys Identified Mail zusammen, um E-Mail-Absender zu authentifizieren und sicherzustellen, dass Ziel-E-Mail-Systeme nachrichten vertrauen, die von Ihrer Domäne gesendet werden. | DMARC zur Validierung von E-Mails verwenden, Einrichtungsschritte |
Problembehandlung beim Senden von E-Mails mit SMTP DANE
Derzeit gibt es vier Fehlercodes für DANE beim Senden von E-Mails mit Exchange Online. Microsoft aktualisiert diese Fehlercodeliste aktiv. Die Fehler werden in folgendem Bereich angezeigt:
- Das Exchange Admin Center-Portal über die Ansicht Details der Nachrichtenablaufverfolgung.
- NDRs, die generiert werden, wenn eine Nachricht aufgrund eines DANE- oder DNSSEC-Fehlers nicht gesendet wird.
- Remote connectivity Analyzer-Tool Microsoft Remote Connectivity Analyzer.
| NDR-Code | Beschreibung |
|---|---|
| 4/5.7.321 | starttls-not-supported: Ziel-E-Mail-Server muss TLS unterstützen, um E-Mails zu empfangen. |
| 4/5.7.322 | zertifikat abgelaufen: Das Zertifikat des Ziel-E-Mail-Servers ist abgelaufen. |
| 4/5.7.323 | tlsa-invalid: Fehler bei der DANE-Überprüfung der Domäne. |
| 4/5.7.324 | dnssec-invalid: Die Zieldomäne hat ungültige DNSSEC-Einträge zurückgegeben. |
Hinweis
Wenn eine Domäne signalisiert, dass sie DNSSEC unterstützt, aber dnssec-Überprüfungen fehlschlägt, generiert Exchange Online derzeit nicht den Fehler 4/5.7.324 dnssec-invalid. Es wird ein generischer DNS-Fehler generiert:
4/5.4.312 DNS query failed
Wir arbeiten aktiv daran, diese bekannte Einschränkung zu beheben. Wenn Sie diese Fehlermeldung erhalten, navigieren Sie zur Microsoft Remote Connectivity Analyzer, und führen Sie den DANE-Überprüfungstest für die Domäne aus, die den Fehler 4/5.4.312 generiert hat. Die Ergebnisse zeigen, ob es sich um ein DNSSEC-Problem oder ein anderes DNS-Problem handelt.
Problembehandlung 4/5.7.321 starttls-not-supported
Dieser Fehler weist in der Regel auf ein Problem mit dem Ziel-E-Mail-Server hin. Nach dem Empfang der Nachricht:
- Überprüfen Sie, ob die Ziel-E-Mail-Adresse richtig eingegeben wurde.
- Benachrichtigen Sie den Ziel-E-Mail-Administrator, dass Sie diesen Fehlercode erhalten haben, damit er ermitteln kann, ob der Zielserver ordnungsgemäß für den Empfang von Nachrichten mithilfe von TLS konfiguriert ist.
- Versuchen Sie erneut, die E-Mail zu senden, und überprüfen Sie die Details der Nachrichtenablaufverfolgung für die Nachricht im Exchange Admin Center-Portal.
Problembehandlung 4/5.7.322 Zertifikat abgelaufen
Ein gültiges X.509-Zertifikat, das noch nicht abgelaufen ist, muss dem sendenden E-Mail-Server vorgelegt werden. X.509-Zertifikate müssen nach ihrem Ablauf verlängert werden, in der Regel jährlich. Nach dem Empfang der Nachricht:
- Benachrichtigen Sie den E-Mail-Zieladministrator, dass Sie diesen Fehlercode erhalten haben, und geben Sie die Fehlercodezeichenfolge an.
- Lassen Sie die Zeit für die Verlängerung des Zielserverzertifikats und den TLSA-Eintrag so zu aktualisieren, dass er auf das neue Zertifikat verweist. Versuchen Sie dann erneut, die E-Mail zu senden, und überprüfen Sie die Details der Nachrichtenablaufverfolgung für die Nachricht im Exchange Admin Center-Portal.
Problembehandlung 4/5.7.323 tlsa-invalid
Dieser Fehlercode steht im Zusammenhang mit der Fehlkonfiguration eines TLSA-Eintrags und kann erst generiert werden, nachdem ein DNSSEC-authentischer TLSA-Eintrag zurückgegeben wurde. Es gibt viele Szenarien während der DANE-Überprüfung, die nach der Rückgabe des Datensatzes auftreten, die dazu führen können, dass der Code generiert wird. Microsoft arbeitet aktiv an den Szenarien, die von diesem Fehlercode abgedeckt werden, sodass jedes Szenario über einen bestimmten Code verfügt. Derzeit kann eines oder mehrere dieser Szenarien die Generierung des Fehlercodes verursachen:
- Das Zertifikat des Ziel-E-Mail-Servers stimmt nicht mit dem überein, was gemäß dem authentifizierten TLSA-Eintrag erwartet wird.
- Der authentische TLSA-Eintrag ist falsch konfiguriert.
- Die Zieldomäne wird angegriffen.
- Ein beliebiger anderer DANE-Fehler.
Nach dem Empfang der Nachricht:
- Benachrichtigen Sie den E-Mail-Zieladministrator, dass Sie diesen Fehlercode erhalten haben, und geben Sie die Fehlercodezeichenfolge an.
- Lassen Sie dem E-Mail-Zieladministrator Zeit, seine DANE-Konfiguration und die Gültigkeit des Zertifikats des E-Mail-Servers zu überprüfen. Versuchen Sie dann erneut, die E-Mail zu senden, und überprüfen Sie die Details der Nachrichtenablaufverfolgung für die Nachricht im Exchange Admin Center-Portal.
Problembehandlung 4/5.7.324 dnssec-invalid
Dieser Fehlercode wird generiert, wenn die Zieldomäne angibt, dass sie DNSSEC-authentisch war, Exchange Online ihn jedoch nicht als DNSSEC-authentic überprüfen konnte.
Nach dem Empfang der Nachricht:
- Benachrichtigen Sie den E-Mail-Zieladministrator, dass Sie diesen Fehlercode erhalten haben, und geben Sie die Fehlercodezeichenfolge an.
- Lassen Sie dem Ziel-E-Mail-Administrator Zeit, die DNSSEC-Konfiguration seiner Domäne zu überprüfen. Versuchen Sie dann erneut, die E-Mail zu senden, und überprüfen Sie die Details der Nachrichtenablaufverfolgung für die Nachricht im Exchange Admin Center-Portal.
Problembehandlung beim Empfangen von E-Mails mit SMTP DANE
Derzeit gibt es zwei Methoden, mit denen ein Administrator einer empfangenden Domäne seine DNSSEC- und DANE-Konfiguration überprüfen und behandeln kann, um E-Mails von Exchange Online mit diesen Standards zu empfangen.
- Einführung von SMTP TLS-RPT (Transport Layer Security Reporting), die in RFC8460
- Verwenden des Remotekonnektivitätsanalysetools Microsoft Remote Connectivity Analyzer
TLS-RPT https://datatracker.ietf.org/doc/html/rfc8460 ist ein Berichterstellungsmechanismus für Absender, mit dem Zieldomänenadministratoren Details zu DANE- und MTA-STS-Erfolgen und -Fehlern bei diesen jeweiligen Zieldomänen bereitstellen können. Um TLS-RPT-Berichte zu erhalten, müssen Sie nur einen TXT-Eintrag in den DNS-Einträgen Ihrer Domäne hinzufügen, der die E-Mail-Adresse oder den URI enthält, an die die Berichte gesendet werden sollen. Exchange Online senden TLS-RPT-Berichte im JSON-Format.
Beispieldatensatz:
Die zweite Methode besteht darin, die Remotekonnektivitätsanalyse Microsoft Remote Connectivity Analyzer zu verwenden, die die gleichen DNSSEC- und DANE-Überprüfungen für Ihre DNS-Konfiguration durchführen kann, die Exchange Online beim Senden von E-Mails außerhalb des Diensts ausführen. Diese Methode ist die direkteste Methode, um Fehler in Ihrer Konfiguration zu beheben, um E-Mails von Exchange Online zu empfangen, die diese Standards verwenden.
Wenn Fehler behoben werden, können die folgenden Fehlercodes generiert werden:
| NDR-Code | Beschreibung |
|---|---|
| 4/5.7.321 | starttls-not-supported: Ziel-E-Mail-Server muss TLS unterstützen, um E-Mails zu empfangen. |
| 4/5.7.322 | zertifikat abgelaufen: Das Zertifikat des Ziel-E-Mail-Servers ist abgelaufen. |
| 4/5.7.323 | tlsa-invalid: Fehler bei der DANE-Überprüfung der Domäne. |
| 4/5.7.324 | dnssec-invalid: Die Zieldomäne hat ungültige DNSSEC-Einträge zurückgegeben. |
Hinweis
Wenn eine Domäne signalisiert, dass sie DNSSEC unterstützt, aber dnssec-Überprüfungen fehlschlägt, generiert Exchange Online derzeit nicht den Fehler 4/5.7.324 dnssec-invalid. Es wird ein generischer DNS-Fehler generiert:
4/5.4.312 DNS query failed
Wir arbeiten aktiv daran, diese bekannte Einschränkung zu beheben. Wenn Sie diese Fehlermeldung erhalten, navigieren Sie zur Microsoft Remote Connectivity Analyzer, und führen Sie den DANE-Überprüfungstest für die Domäne aus, die den Fehler 4/5.4.312 generiert hat. Die Ergebnisse zeigen, ob es sich um ein DNSSEC-Problem oder ein anderes DNS-Problem handelt.
Problembehandlung 4/5.7.321 starttls-not-supported
Hinweis
Diese Schritte gelten für E-Mail-Administratoren bei der Problembehandlung beim Empfangen von E-Mails von Exchange Online mithilfe von SMTP DANE.
Dieser Fehler weist in der Regel auf ein Problem mit dem Ziel-E-Mail-Server hin. Der E-Mail-Server, mit dem die Remotekonnektivitätsanalyse eine Verbindung herstellt. Es gibt im Allgemeinen zwei Szenarien, die diesen Code generieren:
- Der Ziel-E-Mail-Server unterstützt überhaupt keine sichere Kommunikation, und die einfache, nicht verschlüsselte Kommunikation muss verwendet werden.
- Der Zielserver ist nicht ordnungsgemäß konfiguriert und ignoriert den STARTTLS-Befehl.
Nach dem Empfang der Nachricht:
- Überprüfen Sie die E-Mail-Adresse.
- Suchen Sie die IP-Adresse, die der error-Anweisung zugeordnet ist, damit Sie den E-Mail-Server identifizieren können, dem die Anweisung zugeordnet ist.
- Überprüfen Sie die Einstellung Ihres E-Mail-Servers, um sicherzustellen, dass er für das Lauschen auf SMTP-Datenverkehr konfiguriert ist (in der Regel ports 25 und 587).
- Warten Sie einige Minuten, und wiederholen Sie dann den Test mit dem Tool Remote Connectivity Analyzer.
- Wenn weiterhin ein Fehler auftritt, versuchen Sie, den TLSA-Eintrag zu entfernen, und führen Sie den Test erneut mit dem Tool Remote Connectivity Analyzer aus.
- Wenn keine Fehler auftreten, kann diese Meldung darauf hinweisen, dass der E-Mail-Server, den Sie zum Empfangen von E-Mails verwenden, STARTTLS nicht unterstützt, und Sie müssen möglicherweise ein Upgrade auf einen Server durchführen, der dies tut, um DANE verwenden zu können.
Problembehandlung 4/5.7.322 Zertifikat abgelaufen
Hinweis
Diese Schritte gelten für E-Mail-Administratoren bei der Problembehandlung beim Empfangen von E-Mails von Exchange Online mithilfe von SMTP DANE.
Ein gültiges X.509-Zertifikat, das noch nicht abgelaufen ist, muss dem sendenden E-Mail-Server vorgelegt werden. X.509-Zertifikate müssen nach ihrem Ablauf verlängert werden, in der Regel jährlich. Nach dem Empfang der Nachricht:
- Überprüfen Sie die IP-Adresse, die der Error-Anweisung zugeordnet ist, damit Sie den E-Mail-Server identifizieren können, dem sie zugeordnet ist. Suchen Sie das abgelaufene Zertifikat auf dem E-Mail-Server, den Sie identifiziert haben.
- Melden Sie sich bei der Website Ihres Zertifikatanbieters an.
- Wählen Sie das abgelaufene Zertifikat aus, und folgen Sie den Anweisungen zum Verlängern und Bezahlen der Verlängerung.
- Nachdem Ihr Anbieter den Kauf bestätigt hat, können Sie ein neues Zertifikat herunterladen.
- Installieren Sie das erneuerte Zertifikat auf dem zugehörigen E-Mail-Server.
- Aktualisieren Sie den zugeordneten TLSA-Eintrag des E-Mail-Servers mit den Daten des neuen Zertifikats.
- Wiederholen Sie den Test mit dem Remotekonnektivitätsanalysetool, nachdem Sie eine angemessene Zeit gewartet haben.
Problembehandlung 4/5.7.323 tlsa-invalid
Hinweis
Diese Schritte gelten für E-Mail-Administratoren bei der Problembehandlung beim Empfangen von E-Mails von Exchange Online mithilfe von SMTP DANE.
Dieser Fehlercode steht im Zusammenhang mit einer Fehlkonfiguration eines TLSA-Eintrags und kann erst generiert werden, nachdem ein DNSSEC-authentischer TSLA-Eintrag zurückgegeben wurde. Es gibt jedoch viele Szenarien während der DANE-Überprüfung, die nach der Rückgabe des Datensatzes auftreten, die dazu führen können, dass der Code generiert wird. Microsoft arbeitet aktiv an den Szenarien, die von diesem Fehlercode abgedeckt werden, sodass jedes Szenario über einen bestimmten Code verfügt. Derzeit kann eines oder mehrere dieser Szenarien die Generierung des Fehlercodes verursachen:
- Der authentische TLSA-Eintrag ist falsch konfiguriert.
- Das Zertifikat ist für ein zukünftiges Zeitfenster noch nicht gültig/konfiguriert.
- Die Zieldomäne wird angegriffen.
- Ein beliebiger anderer DANE-Fehler.
Nach dem Empfang der Nachricht:
- Überprüfen Sie die IP-Adresse, die der Error-Anweisung zugeordnet ist, um den E-Mail-Server zu identifizieren, dem sie zugeordnet ist.
- Identifizieren Sie den TLSA-Eintrag, der dem identifizierten E-Mail-Server zugeordnet ist.
- Überprüfen Sie die Konfiguration des TLSA-Eintrags, um sicherzustellen, dass er dem Absender signalisiert, die bevorzugten DANE-Überprüfungen durchzuführen, und dass die richtigen Zertifikatdaten in den TLSA-Eintrag aufgenommen wurden.
- Wenn Sie den Datensatz aufgrund von Abweichungen aktualisieren müssen, warten Sie einige Minuten, und führen Sie dann den Test mit dem Tool Remote Connectivity Analyzer erneut aus.
- Suchen Sie das Zertifikat auf dem identifizierten E-Mail-Server.
- Überprüfen Sie das Zeitfenster, für das das Zertifikat gültig ist. Wenn festgelegt ist, dass die Gültigkeit zu einem zukünftigen Datum beginnt, muss sie für das aktuelle Datum verlängert werden.
- Melden Sie sich bei der Website Ihres Zertifikatanbieters an.
- Wählen Sie das abgelaufene Zertifikat aus, und folgen Sie den Anweisungen zum Verlängern und Bezahlen der Verlängerung.
- Nachdem Ihr Anbieter den Kauf bestätigt hat, können Sie ein neues Zertifikat herunterladen.
- Installieren Sie das erneuerte Zertifikat auf dem zugehörigen E-Mail-Server.
Problembehandlung 4/5.7.324 dnssec-invalid
Hinweis
Diese Schritte gelten für E-Mail-Administratoren bei der Problembehandlung beim Empfangen von E-Mails von Exchange Online mithilfe von SMTP DANE.
Dieser Fehlercode wird generiert, wenn die Zieldomäne angibt, dass sie DNSSEC-authentisch ist, Exchange Online ihn jedoch nicht als DNSSEC-authentic überprüfen kann. Dieser Abschnitt ist nicht umfassend für die Behandlung von DNSSEC-Problemen und konzentriert sich auf Szenarien, in denen Domänen zuvor die DNSSEC-Authentifizierung bestanden haben, aber jetzt nicht.
Nach dem Empfang der Nachricht:
- Wenn Sie einen DNS-Anbieter verwenden, z. B. GoDaddy, benachrichtigen Sie Ihren DNS-Anbieter über den Fehler, damit er an der Problembehandlung und Konfigurationsänderung arbeiten kann.
- Wenn Sie Ihre eigene DNSSEC-Infrastruktur verwalten, gibt es viele DNSSEC-Fehlkonfigurationen, die diese Fehlermeldung generieren können. Einige häufige Probleme, die überprüft werden müssen, ob Ihre Zone zuvor die DNSSEC-Authentifizierung übergeben hat:
- Unterbrochene Vertrauenskette, wenn die übergeordnete Zone einen Satz von DS-Einträgen enthält, die auf etwas verweisen, das in der untergeordneten Zone nicht vorhanden ist. Solche Zeiger nach DS-Datensätzen können dazu führen, dass die untergeordnete Zone durch Überprüfung von Resolvern als falsch markiert wird.
- Beheben Sie das Problem, indem Sie die RRSIG-Schlüssel-IDs der untergeordneten Domänen überprüfen und sicherstellen, dass sie mit den Schlüssel-IDs in den DS-Einträgen übereinstimmen, die in der übergeordneten Zone veröffentlicht wurden.
- Der RRSIG-Ressourcendatensatz für die Domäne ist nicht gültig, er ist entweder abgelaufen, oder sein Gültigkeitszeitraum hat noch nicht begonnen.
- Beheben Sie das Problem, indem Sie neue Signaturen für die Domäne mithilfe gültiger Zeitspannen generieren.
- Unterbrochene Vertrauenskette, wenn die übergeordnete Zone einen Satz von DS-Einträgen enthält, die auf etwas verweisen, das in der untergeordneten Zone nicht vorhanden ist. Solche Zeiger nach DS-Datensätzen können dazu führen, dass die untergeordnete Zone durch Überprüfung von Resolvern als falsch markiert wird.
Hinweis
Dieser Fehlercode wird auch generiert, wenn Exchange Online eine SERVFAIL-Antwort vom DNS-Server auf TLSA-Abfrage für die Zieldomäne empfängt.
Wenn eine ausgehende E-Mail gesendet wird und für die empfangende Domäne DNSSEC aktiviert ist, werden TLSA-Einträge abgefragt, die MX-Einträgen in der Domäne zugeordnet sind. Wenn kein TLSA-Eintrag veröffentlicht wird, muss die Antwort auf die TLSA-Suche NOERROR (keine Datensätze des angeforderten Typs für diese Domäne) oder NXDOMAIN (es gibt keine solche Domäne) lauten. DNSSEC erfordert diese Antwort, wenn kein TLSA-Eintrag veröffentlicht wird. andernfalls interpretiert Exchange Online die fehlende Antwort als SERVFAIL-Fehler. Gemäß RFC 7672 ist eine SERVFAIL-Antwort nicht vertrauenswürdig; Daher schlägt die Zieldomäne die DNSSEC-Überprüfung fehl. Diese E-Mail wird dann mit dem folgenden Fehler zurückgestellt:
450 4.7.324 dnssec-invalid: Destination domain returned invalid DNSSEC records
Wenn der E-Mail-Absender den Empfang der Nachricht meldet
Wenn Sie einen DNS-Anbieter verwenden, z. B. GoDaddy, benachrichtigen Sie Ihren DNS-Anbieter über den Fehler, damit er die DNS-Antwort beheben kann. Wenn Sie Ihre eigene DNSSEC-Infrastruktur verwalten, kann dies ein Problem mit dem DNS-Server selbst oder mit dem Netzwerk sein.
Häufig gestellte Fragen
Kann ich als Exchange Online Kunde die Verwendung von DNSSEC und/oder DANE deaktivieren?
Wir sind fest davon überzeugt, dass DNSSEC und DANE die Sicherheitsposition unseres Dienstes erheblich erhöhen und allen unseren Kunden zugute kommen werden. Wir haben im letzten Jahr fleißig daran gearbeitet, das Risiko und den Schweregrad der potenziellen Auswirkungen zu verringern, die diese Bereitstellung für Microsoft 365-Kunden haben könnte. Wir überwachen und verfolgen die Bereitstellung aktiv, um sicherzustellen, dass die negativen Auswirkungen beim Rollout minimiert werden. Aus diesem Fall sind Ausnahmen auf Mandantenebene oder -abmeldung nicht verfügbar. Wenn Probleme im Zusammenhang mit der Aktivierung von DNSSEC und/oder DANE auftreten, helfen Ihnen die verschiedenen methoden zum Untersuchen von Fehlern, die in diesem Dokument aufgeführt sind, bei der Identifizierung der Fehlerquelle. In den meisten Fällen tritt das Problem bei der externen Zielpartei auf, und Sie müssen diesen Geschäftspartnern mitteilen, dass sie DNSSEC und DANE ordnungsgemäß konfigurieren müssen, um E-Mails von Exchange Online empfangen zu können, die diese Standards verwenden.
In welchem Verhältnis steht DNSSEC zu DANE?
DNSSEC fügt der DNS-Auflösung eine Vertrauensschicht hinzu, indem die Public Key-Infrastruktur angewendet wird, um sicherzustellen, dass die als Antwort auf eine DNS-Abfrage zurückgegebenen Datensätze authentisch sind. DANE stellt sicher, dass der empfangende E-Mail-Server der legitime und erwartete E-Mail-Server für den authentischen MX-Eintrag ist.
Was ist der Unterschied zwischen MTA-STS und DANE für SMTP?
DANE und MTA-STS dienen demselben Zweck, aber DANE erfordert DNSSEC für die DNS-Authentifizierung, während MTA-STS auf Zertifizierungsstellen basiert.
Warum reicht opportunistisches TLS nicht aus?
Opportunistisches TLS verschlüsselt die Kommunikation zwischen zwei Endpunkten, wenn beide zustimmen, dies zu unterstützen. Selbst wenn TLS die Übertragung verschlüsselt, kann eine Domäne während der DNS-Auflösung so gespooft werden, dass sie auf den Endpunkt eines böswilligen Akteurs und nicht auf den tatsächlichen Endpunkt für die Domäne verweist. Dieser Spoof ist eine Lücke in der E-Mail-Sicherheit, die durch die Implementierung von MTA-STS und/oder SMTP DANE mit DNSSEC behoben wird.
Warum ist DNSSEC nicht ausreichend?
DNSSEC ist nicht vollständig resistent gegen Man-in-the-Middle-Angriffe und Downgrade-Angriffe (von TLS auf Klartext) für Nachrichtenflussszenarien. Das Hinzufügen von MTA-STS und DANE zusammen mit DNSSEC bietet eine umfassende Sicherheitsmethode, um sowohl MITM- als auch Downgrade-Angriffe zu verhindern.
Weitere Links
Suchen und Beheben von Problemen, nachdem Ihre Domäne oder DNS-Einträge hinzugefügt wurden
Übersicht über DNSSEC | Microsoft-Dokumentation
So verhindert Sender Policy Framework (SPF) Spoofing – Office 365 | Microsoft-Dokumentation
Exchange Online Transport News von der Microsoft Ignite 2020 – Microsoft Tech Community
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für