Freigeben über

Funktionsweise der DNS-basierten SMTP-Authentifizierung benannter Entitäten (DANE)

  • Artikel

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 zu signalisieren, dass eine Domäne und ihre E-Mail-Server DANE unterstützen. 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.

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:

Screenshot: Beispiel für einen TLSA-Eintrag

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 0 oder 1 an Exchange Online zurückgegeben wird, behandelt Exchange Online ihn als nicht verwendbar. 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 erzwingt Exchange Online aufgrund des Vorhandenseins eines TLSA-Eintrags die Verwendung von TLS für das 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 das Generieren eines 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-Beispieleintrag 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.

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.

    Screenshot: Exchange Online-Nachrichtenfluss mit SMTP DANE

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

Eingehende SMTP-DANE mit DNSSEC

Voraussetzungen

Bevor Sie beginnen, stellen Sie sicher, dass die folgenden Voraussetzungen erfüllt sind:

  1. Sie müssen die Domäne als "Akzeptierte Domäne" hinzugefügt haben, und die Domäne status muss im Microsoft 365 Admin Center "Fehlerfrei" sein. In der Dokumentation wird davon ausgegangen, dass der MX-Eintrag der Domäne auf Priorität 0 oder 10 festgelegt ist und dass kein "Fallback" oder sekundärer MX-Eintrag vorhanden ist. Wenn Sie über einen MX-Fallbackeintrag verfügen, müssen Sie eng mit Ihrem Exchange Online-Administrator zusammenarbeiten, um sicherzustellen, dass Änderungen ordnungsgemäß ausgeführt werden.
  2. Um die vollständigen Sicherheitsvorteile des Features zu nutzen, stellen Sie sicher, dass Sie DNSSEC für Ihre Domäne aktiviert haben.
  3. Sie benötigen Zugriff auf Exchange Online PowerShell und die Berechtigungen zum Ausführen der in Exchange Online PowerShell beschriebenen Cmdlets.
  4. Wenn auf die Domäne, die Sie mit eingehender SMTP-DANE mit DNSSEC sichern möchten, in smarthost-Konfigurationen oder Connectors referenziert wird, müssen Sie den Smarthost-Namen tenantname.mail.protection.outlook.com in ändern, bevor Sie die Schritte ausführen.

Hinweis

Wenn Sie DNSSEC für eine Domäne aktivieren möchten, die ein Drittanbietergateway verwendet, können Sie dies tun, indem Sie die Schritte 1 bis 3 befolgen. Befolgen Sie dazu den Hinweis am Ende von Schritt 3 zu Gateways von Drittanbietern.

Warnung

Wenn Sie eingehende SMTP-DANE mit DNSSEC für Ihre akzeptierte Domäne contoso.comkonfigurieren möchten und Ihre Geschäftspartner Connectors für Ihren contoso-com.mail.protection.outlook.com Endpunkt verwenden, müssen Sie mit Ihren Partnern zusammenarbeiten, damit diese deren Connectors aktualisieren, um entweder auf den tenantname.onmicrosoft.com Endpunkt oder den tenantname.mail.protection.outlook.com Endpunkt zu verweisen, bevor Sie eingehende SMTP-DANE mit DNSSEC konfigurieren. Andernfalls schlagen die Connectors-E-Mails Ihrer Geschäftspartner fehl, nachdem Sie die Aktivierung abgeschlossen haben. Nach Abschluss der Aktivierung können Ihre Partner Ihren neuen contoso-com.<random>.mx.microsoft Endpunkt verwenden, um den ursprünglichen Connector erneut einzurichten.

Einrichten eingehender SMTP-DANE mit DNSSEC

Hinweis

Die Bereitstellung und Aktualisierung von DNS-Einträgen kann einige Zeit in Anspruch nehmen. DNS-Änderungen können aufgrund mehrerer Zwischenspeicherebenen länger als erwartet sichtbar werden.

Führen Sie die folgenden Schritte aus, um eingehende SMTP-DANE mit DNSSEC einzurichten:

  1. Aktualisieren Sie die Gültigkeitsdauer Ihres vorhandenen MX-Eintrags auf die niedrigste mögliche Gültigkeitsdauer (aber nicht weniger als 30 Sekunden). Warten Sie dann, bis die vorherige Gültigkeitsdauer abläuft, bevor Sie fortfahren. Wenn die Gültigkeitsdauer Ihres vorhandenen MX-Eintrags beispielsweise "3600 Sekunden" oder "1 Stunde" lautete, bevor Sie ihn geändert haben, müssen Sie eine Stunde warten, bevor Sie mit Schritt 2 fortfahren.

  2. Stellen Sie eine Verbindung mit Exchange Online PowerShell her.

    Warnung

    Wenn Sie MTA-STS verwenden, müssen Sie den Richtlinienmodus auf "Testen" festlegen und die ID im MTA-STS txt-Eintrag aktualisieren. (Sie können die aktuelle Uhrzeit in UTC als neue Richtlinien-ID verwenden.) Warten Sie dann, bis die "max_age" der Richtlinie abläuft, bevor Sie fortfahren. Wenn z. B. die "max_age" Ihrer vorhandenen STS-Richtlinie 3600 Sekunden oder eine Stunde betrug, bevor Sie sie geändert haben, müssen Sie "1 Stunde" warten, bevor Sie fortfahren.

  3. Für die Domäne, für die Sie SMTP DANE mit DNSSEC aktivieren möchten, müssen Sie zunächst DNSSEC für die Domäne aktivieren, indem Sie den folgenden Befehl ausführen (ersetzen Sie "domain" durch den Namen Ihrer ausgewählten Domäne, z. B. contosotest.com):

    Enable-DnssecForVerifiedDomain -DomainName <DomainName>

    Hinweis

    Die Ausführung dieses Befehls kann einige Minuten dauern.

    Beispielausgabe einer erfolgreichen Ausführung

    Ergebnis DnssecMxValue ErrorData
    Erfolgreich contosotest-com.o-v1.mx.microsoft

    Die Erfolgsantwort gibt den MX-Wert für die Domäne an. Dieser Wert ist der Name, auf den der neue MX-Eintrag für die Domäne verweist, die Sie mit DNSSEC aktivieren. Beispiel: contosotest-com.o-v1.mx.microsoft.

  4. Verwenden Sie den Wert "DnssecMxValue", navigieren Sie zur DNS-Registrierungsstelle, die die Domäne hostet, fügen Sie einen neuen MX-Eintrag mit dem in Schritt 3 zurückgegebenen Wert hinzu, legen Sie die Gültigkeitsdauer auf den niedrigsten möglichen Wert (aber nicht weniger als 30 Sekunden) fest, und legen Sie die Priorität des neuen MX-Eintrags auf 20 fest.

    Hinweis

    Wenn Sie ein E-Mail-Gateway eines Drittanbieters verwenden und diesen Wert als neuen Exchange Online Zielhost verwenden möchten, an den das E-Mail-Gateway des Drittanbieters Ihre eingehenden E-Mails sendet, navigieren Sie zum Verwaltungsportal des Drittanbieters, aktualisieren Sie den Ziel-Smarthost, den der Drittanbieter zum Senden an Exchange Online verwendet, und überprüfen Sie dann, ob "der Nachrichtenfluss über den DNSSEC-Test (Stellen Sie sicher, dass Sie während der Testeingabe "DNSSEC-Validierung" und nicht "DANE-Validierung [einschließlich DNSSEC])" im Microsoft Remote Connectivity Analyzer: Test Input auswählen. Wenn E-Mails wie erwartet fließen, müssen Sie NICHT die folgenden Schritte ausführen. Wenn Sie SMTP DANE für diese Domäne aktivieren möchten, fahren Sie mit Schritt 7 fort.

    Warnung

    Wenn Sie MTA-STS verwenden, stellen Sie sicher, dass der Richtlinienmodus auf "Testen" festgelegt ist. Löschen Sie dann die aktuelle MX-Zeile, die die Legacy-MX-Eintragsinformationen enthält, und fügen Sie den neuen FQDN ihrer MTA-STS-Richtliniendatei als neue MX-Zeile hinzu. Aktualisieren Sie dann die Richtlinien-ID in der Richtlinie und den MTA-STS TXT-Eintrag (Sie können die aktuelle Uhrzeit in UTC als neue Richtlinien-ID verwenden).

  5. Vergewissern Sie sich, dass der neue MX über den eingehenden SMTP-Email Test (https://testconnectivity.microsoft.com/tests/O365InboundSmtp/input) funktioniert, indem Sie die Testschritte erweitern und überprüfen, ob der Mail Exchanger mit mx.microsoft-Endung erfolgreich getestet wurde. Je nach DNS-Zwischenspeicherung müssen Sie diesen Test möglicherweise wiederholen.

    Beispiel für eine erfolgreiche Ausgabe

    Screenshot: Beispiel für eine Ausgabe, die über den Erfolg des implementierten Prozesses informiert.

  6. Ändern Sie die Priorität des Legacy-MX, der auf mail.protection.outlook.com verweist, von der aktuellen Priorität in 30. Ändern Sie die Priorität des in Schritt 3 erstellten MX-Eintrags, sodass er auf Priorität 0 (höchste Priorität) festgelegt ist.

  7. Löschen Sie den Legacy-MX-Eintrag, der mit "mail.protection.outlook.com", "mail.eo.outlook.com" oder "mail.protection.outlook.de" endet. Aktualisieren Sie dann die Gültigkeitsdauer für den MX-Eintrag, der mit mx.microsoft endet, auf 3600 Sekunden. Optional können Sie überprüfen, ob alles wie erwartet funktioniert, indem Sie den DNSSEC-Test verwenden (stellen Sie sicher, dass Sie während der Testeingabe "DNSSEC-Validierung" und nicht "DANE-Überprüfung [einschließlich DNSSEC])" in der Remotekonnektivitätsanalyse auswählen. Je nach DNS-Zwischenspeicherung und TTLs müssen Sie diesen Test möglicherweise wiederholen.

    Sobald TTLs für den Legacy-MX-Eintrag abgelaufen sind, sieht eine erfolgreiche Ausgabe wie folgt aus:

    Screenshot: Beispiel einer Ausgabe, die benachrichtigt, dass Domänen den DNSSEC-Überprüfungstest erfolgreich bestanden haben.

  8. Führen Sie den folgenden Befehl [ersetzen Sie (DomainName) durch den Namen Der ausgewählten Domäne, z. B. contosotest.com] aus, wenn Sie SMTP DANE für dieselbe Domäne aktivieren möchten, nachdem die DNSSEC-Aktivierung abgeschlossen ist:

    Enable-SmtpDaneInbound -DomainName <DomainName>
    Ergebnis ErrorData
    Erfolgreich

  9. Überprüfen Sie, ob der TLSA-Eintrag weitergegeben wurde (was 15 bis 30 Minuten dauern kann), indem Sie ein Onlinetool Ihrer Wahl und die Microsoft Remote Connectivity Analyzer: Test Input verwenden.

    Nachdem Sie die DNSSEC-Aktivierung abgeschlossen haben und der SMTP DANE-Eintrag (TLSA) von Exchange Online bereitgestellt wurde, wird eine erfolgreiche Ausgabe angezeigt, wie im folgenden Screenshot gezeigt:

    Screenshot: Beispiel einer Ausgabe, die benachrichtigt, dass Domänen den Dane-Überprüfungstest erfolgreich bestanden haben.

    Exchange Online hostet mehrere TLSA-Einträge, um die Zuverlässigkeit einer erfolgreichen SMTP-DANE-Überprüfung zu erhöhen. Es wird erwartet, dass einige der TLSA-Einträge bei der Überprüfung fehlschlagen können. Solange 1 TLSA-Datensatz die Überprüfung besteht, wird SMTP DANE ordnungsgemäß konfiguriert, und die E-Mail wird mit SMTP DANE geschützt.

    Warnung

    Wenn Sie MTA-STS verwenden, legen Sie nach der Überprüfung, dass die Richtlinie funktioniert und die E-Mail wie erwartet fließt, den Richtlinienmodus wieder auf "erzwingen" fest, und aktualisieren Sie die ID im MTA-STS txt-Eintrag. (Sie können die aktuelle Uhrzeit in UTC als neue Richtlinien-ID verwenden.)

Begrenzungen

  1. Virale oder Self-Service-Registrierungsdomänen: Domänen, die als "Self-Service" eingerichtet wurden, werden derzeit nicht mit eingehender SMTP-DANE mit DNSSEC unterstützt.
  2. onmicrosoft.com Domänen: Die Domäne "onmicrosoft.com" für den Mandanten wird derzeit nicht mit eingehender SMTP-DANE mit DNSSEC unterstützt. Wir untersuchen die Unterstützung für eingehende SMTP-DANE mit DNSSEC für die onmicrosoft.com Domänen. die ETA ist jedoch unbekannt.
  3. Gateways von Drittanbietern: Kunden, die ein E-Mail-Gateway eines Drittanbieters im eingehenden Pfad verwenden (das E-Mails für den Mandanten akzeptiert, einige Verarbeitungen durchführt und diese dann an Exchange Online weitergibt) können dieses Feature nur verwenden, um E-Mails zu schützen, die vom Drittanbietergateway an Exchange Online weitergeleitet werden, wenn das Drittanbietergateway SMTP DANE mit DNSSEC-Überprüfung unterstützt. Kunden in dieser Konfiguration müssen eingehende SMTP-DANE mit DNSSEC mithilfe von Exchange PowerShell einrichten.
  4. Andere Integration von Drittanbietern in den Nachrichtenfluss: Es gibt Kunden für Gateways von Drittanbietern auf dem ausgehenden Pfad, bei dem die E-Mail über einen Connector an den Drittanbieter gesendet wird, der Drittanbieter eine Verarbeitung durchführt und dann erneut an Exchange Online übermittelt, dann Exchange Online schließlich die E-Mail sendet. Diese Kunden müssen möglicherweise mit ihrem Drittanbieter zusammenarbeiten, wenn sie das Feature aktivieren, damit keine Unterbrechungen auftreten. Das Relay eines Drittanbieters muss beim Zurücksenden der E-Mail an Exchange Online eine DNS-Suche verwenden und den neuen Hostnamen des MX-Eintrags ">contoso-com" verwenden. subdomain).mx.microsoft wurde während der Featureaktivierung erstellt. Der Drittanbieter SOLLTE NICHT den hostnamen des alten MX-Eintrags verwenden–> contoso-com.mail.protection.outlook.com wie Exchange Online löscht den A-Eintrag ungefähr innerhalb von 2 Tagen (48 Stunden) nach der Featureaktivierung, sobald wir die allgemeine Verfügbarkeit erreicht haben.
  5. Vollständig delegierte Domänen: Domänen, die von Microsoft gehostet werden und die NS-Delegierung verwenden, sodass die Namenserver von Microsoft für die Domäne autoritativ sind, werden mit eingehender SMTP-DANE mit DNSSEC unterstützt. Wir beabsichtigen, eingehende SMTP-DANE mit DNSSEC für diese Domänen zu unterstützen. die ETA ist jedoch unbekannt.

Debuggen von Problemen, die beim Aktivieren eingehender SMTP-DANE mit DNSSEC auftreten

Probleme mit Enable/Disable-DnssecForVerifiedDomain und Enable/Disable-SmtpDane Inbound

  1. DomainNotFound

    Meldung (DNSSEC): "Fehler beim Aktivieren/Deaktivieren von DNSSEC, weil die Domäne contoso.com nicht in AAD vorhanden ist."
    Nachrichten (SMTP DANE):

    • "Fehler beim Aktivieren/Deaktivieren von SMTP DANE, weil die Domäne in AAD nicht vorhanden contoso.com."
    • "Fehler beim Aktivieren/Deaktivieren von SMTP DANE, weil domänenbezogene contoso.com in der Liste der akzeptierten Domänen nicht gefunden wurden."
      Ursache: Die angegebene Domäne wurde in der Liste der akzeptierten Domänen nicht gefunden.
      Auszuführende Aktionen: Navigieren Sie zum Microsoft 365 Admin Center, und stellen Sie sicher, dass die Domäne mit dem Mandanten überprüft wurde. Wenn die Domäne im Microsoft 365 Admin Center fehlerfrei ist, navigieren Sie zum Exchange Admin Center, und stellen Sie sicher, dass die Domäne als "Akzeptierte Domäne" hinzugefügt wurde.

    DNSSEC

    Ergebnis DnssecMxValue ErrorData
    Error ErrorCode: 'DomainNotFound' ErrorDetails 'DNSSEC-Aktivierung fehlgeschlagen...

    SMTP DANE

    Ergebnis ErrorData
    Error ErrorCode: 'DomainNotFound' ErrorDetails 'SMTP DANE enabling...

  2. DnsSecOperationFailed

    Meldung (DNSSEC): "Fehler beim Aktivieren/Deaktivieren von DNSSEC aufgrund von AdditionalErrorDetails. Wiederholen Sie den Vorgang zu einem späteren Zeitpunkt.
    Messages (SMTP DANE): Fehler beim Aktivieren/Deaktivieren von SMTP DANE aufgrund von AdditionalErrorDetails. Wiederholen Sie den Vorgang zu einem späteren Zeitpunkt.
    Ursache: Fehler beim Erstellen der richtigen DNS-Zone und/oder -Einträge.
    Auszuführende Aktionen: Versuchen Sie, das Cmdlet erneut auszuführen.

    DNSSEC

    Ergebnis DnssecMxValue ErrorData
    Error ErrorCode: 'DnssecOperationFailed' ErrorDetails 'DNSSEC-Aktivierung fehlgeschlagen...

    SMTP DANE

    Ergebnis ErrorData
    Error ErrorCode: 'DnssecOperationFailed' ErrorDetails 'SMTP DANE enabling ...

  3. PartitionNotFound

    Messages (SMTP DANE): "Fehler beim Aktivieren/Deaktivieren von SMTP DANE, weil die Domäne contoso.com keine Partition hat."
    Ursache: DNSSEC ist für die Domäne nicht aktiviert.
    Auszuführende Aktionen: Stellen Sie sicher, dass Sie eine DNSSEC-fähige Domäne verwenden.

    Ergebnis ErrorData
    Error ErrorCode: 'PartitionNotFound' ErrorDetails 'SMTP DANE enabling

  4. DomainNotSupported

    Meldung (DNSSEC): "Die angegebene Domäne ist eine onmicrosoft-Domäne: contoso-com.onmicrosoft.com."
    Messages (SMTP DANE): "Die angegebene Domäne ist eine onmicrosoft-Domäne: contoso-com.onmicrosoft.com."
    Ursache: Die Domäne ist eine anfangs- oder MOERA-Domäne. Diese werden derzeit nicht unterstützt.
    Auszuführende Aktionen: Stellen Sie sicher, dass Sie eine Domäne verwenden, die nicht mit "onmicrosoft.com" endet.

    DNSSEC

    Ergebnis DnssecMxValue ErrorData
    Error ErrorCode: 'DomainNotSupported' ErrorDetails 'Die angegebene Domäne ...

    SMTP DANE

    Ergebnis ErrorData
    Error ErrorCode: 'DomainNotSupported' ErrorDetails 'Die angegebene Domäne ...
Probleme mit Get-DnssecStatusForVerifiedDomain

  1. Meldung: 'EG001: DNSSEC-Feature kann nicht abgerufen status für domäne [{domain}]."
    Ursache: Beim Überprüfen der Konfiguration der Domäne in Exchange Online haben wir festgestellt, dass die Domäne nicht zu Exchange Online hinzugefügt wurde. Wenn Sie der Meinung sind, dass Sie diese Domäne bereits Exchange Online hinzugefügt haben, wiederholen Sie die Ausführung des Cmdlets, da dies ein vorübergehendes Problem sein kann.
    Auszuführende Aktionen: Wiederholen Sie das Cmdlet. Wenn weiterhin ein Fehler auftritt, navigieren Sie zum Microsoft 365 Admin Center, und schließen Sie den Setupvorgang für diese Domäne ab.

  2. Meldung: 'EG002: Domäne [{domain}] ist nicht überprüfte Domäne des organization.
    Ursache: Beim Überprüfen der Konfiguration der Domäne in Exchange Online haben wir festgestellt, dass die Domäne Exchange Online hinzugefügt, aber nicht überprüft wurde.
    Auszuführende Aktionen: Navigieren Sie zum Microsoft 365 Admin Center, und schließen Sie den Setup- und Überprüfungsprozess für diese Domäne ab.

  3. Meldung: "DNS-Abfragefehler tritt beim Abrufen von MX-Einträgen für die Domäne [{Domäne}] auf."
    Ursache: Während der DNS-Überprüfung haben wir beim Abfragen der Domäne einen generischen DNS-Fehler erhalten.
    Auszuführende Aktion(en): Wiederholen Sie die Ausführung des Cmdlets. Möglicherweise müssen Sie Ihre Konfiguration für die Domäne überprüfen, die Sie mit SMTP DANE mit DNSSEC aktivieren möchten.

  4. Meldung: "Domäne [{domain}] nicht gefunden."
    Ursache: Während der DNS-Überprüfung haben wir beim Abfragen der Domäne einen NXDOMAIN-Fehler erhalten.
    Auszuführende Aktion(en): Wiederholen Sie die Ausführung des Cmdlets, nachdem Sie die Mx-Eintragskonfiguration für die Domäne überprüft haben. Die DNS-Weitergabe kann bei einigen DNS-Anbietern bis zu 48 Stunden dauern.

  5. Meldung: 'ED003: Domäne [{domain}] gefunden. Es wurden keine authentischen MX-Einträge gefunden."
    Ursache: Während der DNSSEC-Überprüfung konnten wir keinen MX-Eintrag finden, der in einen DNSSEC-gesicherten A-Eintrag aufgelöst wurde (der A-Eintrag für den Hostnamenwert des MX-Eintrags).
    Auszuführende Aktion(en): Wiederholen Sie die Ausführung des Cmdlets, nachdem Sie die Mx-Eintragskonfiguration für die Domäne überprüft haben. Die DNS-Weitergabe kann bei einigen DNS-Anbietern bis zu 48 Stunden dauern.

  6. Meldung: "EX002: Der Wert des MX-Eintrags stimmte nicht mit dem erwarteten Datensatz überein."
    Ursache: Während der MX-Überprüfung haben wir keinen MX-Eintrag gefunden, der dem erwarteten Eintrag entspricht.
    Auszuführende Aktionen: Überprüfen Sie Ihre MX-Einträge in Ihrer Domäne. Stellen Sie sicher, dass ein MX-Eintrag dem erwarteten Datensatz entspricht, der nach dem Ausführen Enable-DnssecForVerifiedDomain von oder Get-DnssecStatusForVerifiedDomainausgegeben wird.

  7. Meldung: "EX003: Die Priorität des MX-Eintrags entspricht nicht dem erwarteten Eintrag."
    Ursache: Während der MX-Überprüfung haben wir den erwarteten MX-Eintrag gefunden, aber seine Priorität wurde nicht auf 0 festgelegt.
    Auszuführende Aktionen: Legen Sie ihren MX-Eintrag (mit dem wert, der beim Ausführen Enable-DnssecForVerifiedDomainvon oder Get-DnssecStatusForVerifiedDomainzurückgegeben wird) auf Priorität 0 fest.

  8. Meldung: "EX004: Es gibt einen anderen MX-Eintrag mit der gleichen Einstellung wie der erwartete."
    Ursache: Bei der MX-Überprüfung haben wir festgestellt, dass der MX-Eintrag mit der höchsten Priorität nicht der erwartete MX-Eintrag war.
    Auszuführende Aktionen: Wenn Sie die Schritte 1 bis 4 von Einrichten eingehender SMTP-DANE mit DNSSEC bereits abgeschlossen haben, führen Sie die Schritte 5 und 6 aus, indem Sie die Prioritäten Ihrer MX-Einträge so ändern, dass der erwartete MX-Wert 0 (höchste Priorität) ist, die Konfiguration überprüfen und dann den Legacy-MX-Eintrag löschen.

  9. Meldung: "EX005: Es gibt einen anderen MX-Eintrag mit einer niedrigeren Präferenz als den erwarteten."
    Ursache: Während der MX-Überprüfung haben wir einen MX-Eintrag für die Domäne gefunden, der nicht mit dem erwarteten MX-Eintrag übereinstimmt.
    Auszuführende Aktionen: Wenn Sie die Schritte 1 bis 5 des Einrichtens eingehender SMTP-DANE mit DNSSEC bereits abgeschlossen haben, führen Sie Schritt 6 aus, indem Sie den Legacy-MX-Eintrag löschen.

  10. Meldung: "EX006: Es gibt einen anderen MX-Eintrag mit einer höheren Präferenz als den erwarteten."
    Ursache: Während der MX-Überprüfung haben wir einen anderen MX-Eintrag mit einer höheren Präferenz als dem erwarteten gefunden.
    Auszuführende Aktionen: Legen Sie den Mx-Legacyeintrag (der mit mail.protection.outlook.com, mail.eo.outlook.com oder mail.protection.outlook.de endet) auf Priorität 20 fest.

  11. Meldung: "EX007: MX-Eintrag wurde nicht gefunden."
    Ursache: Während der MX-Überprüfung haben wir keinen MX-Eintrag gefunden, der dem erwarteten Eintrag entspricht.
    Auszuführende Aktionen: Überprüfen Sie Ihre MX-Einträge in Ihrer Domäne. Stellen Sie sicher, dass ein MX-Eintrag dem erwarteten Datensatz entspricht, der nach dem Ausführen Enable-DnssecForVerifiedDomain von oder Get-DnssecStatusForVerifiedDomainausgegeben wird.

  12. Meldung: "EX008: Der richtige MX-Eintrag gefunden, aber mit einer niedrigeren Einstellung als erwartet."
    Ursache: Bei der MX-Überprüfung haben wir festgestellt, dass der erwartete MX-Eintrag die falsche Priorität hat.
    Auszuführende Aktionen: Legen Sie ihren MX-Eintrag (mit dem wert, der beim Ausführen Enable-DnssecForVerifiedDomain von oder Get-DnssecStatusForVerifiedDomainzurückgegeben wird) auf Priorität 0 fest.

  13. Meldung: "EX009: Der richtige MX-Eintrag gefunden, aber mit höherer Präferenz als erwartet."
    Ursache: Bei der MX-Überprüfung haben wir festgestellt, dass der erwartete MX-Eintrag die falsche Priorität hat.
    Auszuführende Aktionen: Legen Sie ihren MX-Eintrag (mit dem wert, der beim Ausführen Enable-DnssecForVerifiedDomain von oder Get-DnssecStatusForVerifiedDomainzurückgegeben wird) auf Priorität 0 fest.

  14. Meldung: 'EX010: Unbekannter Fehler beim Durchsuchen von MX-Einträgen für domäne [{domain}].'
    Ursache: Während der MX-Überprüfung ist ein generischer DNS-Fehler aufgetreten.
    Auszuführende Aktion(en): Wiederholen Sie die Ausführung des Cmdlets, nachdem Sie die Mx-Eintragskonfiguration für die Domäne überprüft haben. Die DNS-Weitergabe kann bei einigen DNS-Anbietern bis zu 48 Stunden dauern.

  15. Meldung: 'EX012: MX-Einträge für domäne [{domain}]nicht gefunden.'
    Ursache: Während der MX-Überprüfung haben wir keinen MX-Eintrag gefunden, der dem erwarteten Eintrag entspricht.
    Auszuführende Aktionen: Überprüfen Sie Ihre MX-Einträge in Ihrer Domäne. Stellen Sie sicher, dass ein MX-Eintrag dem erwarteten Datensatz entspricht, der nach dem Ausführen Enable-DnssecForVerifiedDomain von oder Get-DnssecStatusForVerifiedDomainausgegeben wird.

  16. Meldung: 'EX013: Unbekannter erwarteter MX-Eintrag für domäne [{domain}].'
    Ursache: Während der MX-Überprüfung haben wir keinen MX-Eintrag gefunden, der dem erwarteten Eintrag entspricht.
    Auszuführende Aktionen: Überprüfen Sie Ihre MX-Einträge in Ihrer Domäne. Stellen Sie sicher, dass ein MX-Eintrag dem erwarteten Datensatz entspricht, der nach dem Ausführen Enable-DnssecForVerifiedDomain von oder Get-DnssecStatusForVerifiedDomainausgegeben wird.

  17. Meldung: "ES001: Es wurde erwartet, dass mx-Eintrag in der Richtlinie fehlt, während der Modus "erzwungen" ist.
    Ursache: Während der MTA-STS-Überprüfung konnten wir den mx-Wert nicht finden, der ihrem erwarteten Datensatz entspricht.
    Auszuführende Aktionen: Legen Sie den Modus Ihrer MTA-STS-Richtlinie fest, die getestet werden soll. fügen Sie dann den Wert mxhostname (zurückgegeben beim Ausführen Enable-DnssecForVerifiedDomain von oder Get-DnssecStatusForVerifiedDomain) als Zeile in der MTA-STS-Richtlinie hinzu.

  18. Meldung: 'ES002: Es wurde kein MX-Eintrag gefunden, mit dem die Richtlinie verglichen werden soll. Aktivieren Sie zuerst das DNSSEC-Feature für die Domäne [{domain}].
    Ursache: MTA-STS wurde gefunden, aber DNSSEC-status der Domäne war nicht erreichbar.
    Auszuführende Aktionen: Führen Sie die Schritte unter Einrichten eingehender SMTP-DANE mit DNSSEC aus.

Beheben von E-Mail-Flussproblemen mit eingehender SMTP-DANE mit DNSSEC

Es gibt drei wichtige Szenarien für E-Mail-Flussprobleme, nachdem eingehende SMTP-DANE mit DNSSEC aktiviert wurde:

  1. Problem mit fehlgeschlagenen SMTP-DANE-Überprüfungen: Informationen zum Beheben dieses Problems finden Sie unter Beheben von SMTP-DANE-Überprüfungen mit Fehlern.
  2. Problem mit fehlerhaften DNSSEC-Überprüfungen: Informationen zum Beheben dieses Problems finden Sie unter Beheben von Fehlern bei DNSSEC-Überprüfungen.
  3. Problem mit dem MX-Wert: Informationen zum Beheben dieses Problems finden Sie unter Beheben von Problemen mit dem MX-Wert.
Beheben von Fehlern bei SMTP-DANE-Überprüfungen

Führen Sie den folgenden Befehl aus, um die Auswirkungen von SMTP-DANE-Überprüfungen zu verringern:

Disable-SmtpDaneInbound -DomainName <DomainName>
Beheben von Fehlern bei DNSSEC-Überprüfungen

  1. Um die Auswirkungen von fehlerhaften DNSSEC-Überprüfungen zu verringern, müssen Sie DNSSEC für Ihre Domäne (contoso.com) über Ihren DNS-Anbieter deaktivieren.

    Hinweis

    Wenn das Problem durch die Deaktivierung von DNSSEC nicht behoben wird, liegt möglicherweise ein Problem mit Ihrem MX-Wert vor.

  2. Nachdem Sie DNSSEC für Ihre Domäne über Ihren DNS-Anbieter deaktiviert haben, öffnen Sie ein Supportticket bei Ihrem DNS-Anbieter, um zu ermitteln, wie DNSSEC für Ihre Domäne sicher wieder aktiviert werden kann.

Beheben von Problemen mit dem MX-Wert

  1. Stellen Sie sicher, dass Ihr MX-Wert mit dem Wert im Microsoft 365 Admin Center –> Einstellungen –> Domänen übereinstimmt.

  2. Wählen Sie die Domäne aus, wählen Sie DNS-Einträge aus, und führen Sie dann Integrität überprüfen aus.

  3. Stellen Sie sicher, dass der MX-Eintrag als OK angezeigt wird. Wenn dies nicht der Fall ist, aktualisieren Sie den Wert auf den wert, der im Admin Center bereitgestellt wird.

  4. Navigieren Sie zu Ihrer DNS-Registrierungsstelle, und suchen Sie den MX-Eintrag für Ihre Domäne. Der Hostnamenwert lautet:

    <MX token>.<subdomain>.mx.microsoft

  5. Erstellen Sie einen zweiten MX-Eintrag mit dem folgenden Hostnamenwert, und legen Sie die Priorität auf 20 fest:

    <MX token>.mail.protection.outlook.com

    Hinweis

    Ersetzen Sie den Wert "MX-Token" durch das MX-Token aus dem aktuellen MX-Eintrag für Ihre Domäne in Schritt 4. Beispielsweise lautet das MX-Token für contosotest.com contosotest-com.

  6. Stellen Sie sicher, dass der in Schritt 5 erstellte MX funktioniert.

    Wichtig

    Eine Möglichkeit, um sicherzustellen, dass der zweite MX-Eintrag funktioniert, ist die Verwendung der Microsoft Remote Connectivity Analyzer.

    1. Geben Sie die Domäne (z. B. contoso.com) in den Test ein. und wählen Sie dann Test ausführen aus.
    2. Öffnen Sie Testschritte.
    3. Öffnen Sie Testschritte zum Testen des eingehenden SMTP-Nachrichtenflusses für die Domäne "admin@(Domäne)".
    4. Öffnen Sie zusätzliche Details unter Versucht, DNS-MX-Einträge für die Domäne "(Domäne)" abzurufen.
    5. Vergewissern Sie sich, dass der MX-Eintrag (MX-Token) .mail.protection.outlook.com fehlerfrei ist.

  7. Wenn der Nachrichtenfluss mit dem MX-token.mail.protection.outlook.com MX-Eintrag funktioniert, führen Sie den folgenden Befehl aus:

    Disable-DnssecForVerifiedDomain -DomainName <DomainName>

  8. Löschen Sie den DNSSEC MX-Eintrag, der den folgenden Werten entspricht:

    <MX token>.<subdomain>.mx.microsoft

  9. Stellen Sie sicher, dass der mx-Eintrag, den Sie in Schritt 5 erstellt haben, der einzige MX-Eintrag ist und auf Priorität 0 (höchste Priorität) festgelegt ist.

Wie können Exchange Online Kunden ausgehende SMTP-DANE mit DNSSEC 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.

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:

  1. Das Exchange Admin Center-Portal über die Ansicht Details der Nachrichtenablaufverfolgung.

  2. NDRs, die generiert werden, wenn eine Nachricht aufgrund eines DANE- oder DNSSEC-Fehlers nicht gesendet wird.

  3. 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:

  1. Überprüfen Sie, ob die Ziel-E-Mail-Adresse richtig eingegeben wurde.
  2. 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.
  3. 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:

  1. Benachrichtigen Sie den E-Mail-Zieladministrator, dass Sie diesen Fehlercode erhalten haben, und geben Sie die Fehlercodezeichenfolge an.
  2. 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:

  1. Das Zertifikat des Ziel-E-Mail-Servers stimmt nicht mit dem überein, was gemäß dem authentifizierten TLSA-Eintrag erwartet wird.
  2. Der authentische TLSA-Eintrag ist falsch konfiguriert.
  3. Die Zieldomäne wird angegriffen.
  4. Ein beliebiger anderer DANE-Fehler.

Nach dem Empfang der Nachricht:

  1. Benachrichtigen Sie den E-Mail-Zieladministrator, dass Sie diesen Fehlercode erhalten haben, und geben Sie die Fehlercodezeichenfolge an.
  2. 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:

  1. Benachrichtigen Sie den E-Mail-Zieladministrator, dass Sie diesen Fehlercode erhalten haben, und geben Sie die Fehlercodezeichenfolge an.
  2. 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, die ein Administrator einer empfangenden Domäne verwenden kann, um seine DNSSEC- und DANE-Konfiguration zu überprüfen und zu beheben, um E-Mails von Exchange Online mithilfe der folgenden Standards zu erhalten:

  1. Einführung von SMTP TLS-RPT (Transport Layer Security Reporting), die in RFC8460
  2. 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.

Die Daten der folgenden Tabelle sind ein Beispiel für einen Datensatz:

Typ Domänenname TTL Aufzeichnen
TXT _smtp._tls.microsoft.com 3600 v=TLSRPTv1; rua=https://tlsrpt.azurewebsites.net/report

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:

  1. Der Ziel-E-Mail-Server unterstützt überhaupt keine sichere Kommunikation, und die einfache, nicht verschlüsselte Kommunikation muss verwendet werden.
  2. Der Zielserver ist nicht ordnungsgemäß konfiguriert und ignoriert den STARTTLS-Befehl.

Nach dem Empfang der Nachricht:

  1. Überprüfen Sie die E-Mail-Adresse.
  2. 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.
  3. Ü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).
  4. Warten Sie einige Minuten, und wiederholen Sie dann den Test mit dem Tool Remote Connectivity Analyzer.
  5. 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.
  6. 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:

  1. Ü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.
  2. Melden Sie sich bei der Website Ihres Zertifikatanbieters an.
  3. Wählen Sie das abgelaufene Zertifikat aus, und folgen Sie den Anweisungen zum Verlängern und Bezahlen der Verlängerung.
  4. Nachdem Ihr Anbieter den Kauf bestätigt hat, können Sie ein neues Zertifikat herunterladen.
  5. Installieren Sie das erneuerte Zertifikat auf dem zugehörigen E-Mail-Server.
  6. Aktualisieren Sie den zugeordneten TLSA-Eintrag des E-Mail-Servers mit den Daten des neuen Zertifikats.
  7. 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:

  1. Der authentische TLSA-Eintrag ist falsch konfiguriert.
  2. Das Zertifikat ist für ein zukünftiges Zeitfenster noch nicht gültig/konfiguriert.
  3. Die Zieldomäne wird angegriffen.
  4. Ein beliebiger anderer DANE-Fehler.

Nach dem Empfang der Nachricht:

  1. Überprüfen Sie die IP-Adresse, die der Error-Anweisung zugeordnet ist, um den E-Mail-Server zu identifizieren, dem sie zugeordnet ist.
  2. Identifizieren Sie den TLSA-Eintrag, der dem identifizierten E-Mail-Server zugeordnet ist.
  3. Ü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.
    1. 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.
  4. Suchen Sie das Zertifikat auf dem identifizierten E-Mail-Server.
  5. Ü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.
    1. Melden Sie sich bei der Website Ihres Zertifikatanbieters an.
    2. Wählen Sie das abgelaufene Zertifikat aus, und folgen Sie den Anweisungen zum Verlängern und Bezahlen der Verlängerung.
    3. Nachdem Ihr Anbieter den Kauf bestätigt hat, können Sie ein neues Zertifikat herunterladen.
    4. 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.

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.

Nach dem Empfang der Nachricht:

  1. 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.
  2. 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:
    1. 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.
    2. 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.

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.

Suchen und Beheben von Problemen, nachdem Ihre Domäne oder DNS-Einträge hinzugefügt wurden

Übersicht über DNSSEC | Microsoft-Dokumentation

Verwenden von DMARC zum Überprüfen von E-Mails, Einrichtungsschritte – Office 365 | Microsoft-Dokumentation

Verwenden von DKIM für E-Mails in Ihrer benutzerdefinierten Domäne – Office 365 | 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

rfc8461 (ietf.org)