Freigeben über

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

Das SMTP-Protokoll ist das Hauptprotokoll, das zum Übertragen von Nachrichten zwischen E-Mail-Servern verwendet wird. Standardmäßig ist es 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, sodass viel E-Mail-Datenverkehr in Klartext bleibt und anfällig für Abfangen durch bösgläubige Akteure ist. 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 führte zur Schaffung vieler neuer Standards, um die Sicherheit beim Senden und Empfangen von E-Mails zu erhöhen. Einer dieser Standards ist die 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 Nachrichtenfluss wie gewohnt ohne DANE-Überprüfungen. 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-Konfliktlöser zurückgegeben werden, fragt der sendende E-Mail-Server nach dem TLSA-Eintrag, der den MX-Hosteinträgen 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, wiederholt Exchange Online den gesamten Überprüfungsprozess. Es beginnt mit einer DNS-Abfrage für dieselbe Zieldomäne erneut nach 15 Minuten, dann 15 Minuten danach und dann stündlich für die nächsten 24 Stunden. Wenn die Authentifizierung nach 24 Stunden wiederholungsversuchen 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-Ressourcendatensatz

Verwenden Sie den TLSA-Eintrag (TLSA), um das X.509-Zertifikat oder den Wert des öffentlichen Schlüssels eines Servers dem Domänennamen zuzuordnen, der den Datensatz enthält. Sie können TLSA-Einträgen nur vertrauen, wenn Sie DNSSEC für Ihre Domäne aktivieren. Wenn Sie einen DNS-Anbieter zum Hosten Ihrer Domäne verwenden, bietet dieser möglicherweise DNSSEC als Einstellung an, wenn Sie Ihre Domäne konfigurieren. Weitere Informationen zur DNSSEC-Zonensignierung finden Sie unter Übersicht über DNSSEC.

TlsA-Beispieldatensatz:

Screenshot: Beispiel für einen TLSA-Eintrag

Der TLSA-Datensatztyp verfügt über vier konfigurierbare Felder:

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ührt 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') entspricht nur dem Zertifikat des Zielservers.

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 mit dem öffentlichen Schlüssel des Zielserverzertifikats und dem Algorithmus übereinstimmen, mit dem der öffentliche Schlüssel identifiziert wird.

Ü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, verweist er auf den SHA-256-Hash der Informationen zum öffentlichen Schlüssel des Antragstellers aus dem Zielserverzertifikat.

Verwenden Sie gemäß rfc-Implementierungsleitfaden für SMTP DANE einen TLSA-Eintrag, wobei das Feld Zertifikatverwendung auf 3, das Auswahlfeld auf 1 und das Feld Übereinstimmender Typ auf 1 festgelegt ist.

Exchange Online Nachrichtenfluss mit SMTP DANE

Der Nachrichtenflussprozess für Exchange Online mit SMTP DANE, der im folgenden Flussdiagramm 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 Zieldomäne signalisiert DNSSEC-Unterstützung, aber mindestens ein Datensatz wird 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. Fügen Sie die Domäne als akzeptierte Domäne hinzu, und stellen Sie sicher, dass die Domäne status im Microsoft 365 Admin Center fehlerfrei ist. In dieser 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, arbeiten Sie eng mit Ihrem Exchange Online-Administrator zusammen, um sicherzustellen, dass Änderungen ordnungsgemäß ausgeführt werden.
  2. Aktivieren Sie DNSSEC für Ihre Domäne, um die vollständigen Sicherheitsvorteile des Features zu nutzen.
  3. Zugriff auf Exchange Online PowerShell und die Berechtigungen zum Ausführen der in Exchange Online PowerShell beschriebenen Cmdlets.

Hinweis

Um DNSSEC für eine Domäne zu aktivieren, die ein Drittanbietergateway verwendet, führen Sie die Schritte 1 bis 3 aus, und befolgen Sie dabei den Hinweis am Ende von Schritt 3 für Gateways von Drittanbietern.

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 3.600 Sekunden (1 Stunde) betrug, 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 3.600 Sekunden (1 Stunde) betrug, bevor Sie sie geändert haben, müssen Sie 1 Stunde warten, bevor Sie fortfahren.

  3. Aktivieren Sie für die Domäne, für die Sie SMTP DANE mit DNSSEC aktivieren möchten, DNSSEC für die Domäne, indem Sie den folgenden Befehl ausführen (ersetzen Sie "domäne" 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", wechseln 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, wechseln 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 die folgenden Schritte nicht weiter 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 auf mx.microsoft endet, auf 3.600 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 erneut versuchen.

    Sobald TTLs für den Legacy-MX-Eintrag ablaufen, 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.

    Sobald Sie die DNSSEC-Aktivierung abgeschlossen haben und der SMTP DANE-Eintrag (TLSA) von Exchange Online bereitgestellt wird, 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 nicht überprüft werden. Solange ein TLSA-Eintrag 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 Sie als "Self-Service" eingerichtet haben, 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: Wenn Sie ein E-Mail-Gateway eines Drittanbieters auf dem eingehenden Pfad verwenden, das E-Mails für den Mandanten akzeptiert, eine Verarbeitung durchführt und diese dann an Exchange Online weitergibt, können Sie dieses Feature nur verwenden, um E-Mails zu schützen, die vom Gateway des Drittanbieters an Exchange Online weitergeleitet werden, wenn das Drittanbietergateway SMTP-DANE mit DNSSEC-Überprüfung unterstützt. Wenn Sie diese Konfiguration verwenden, müssen Sie eingehende SMTP-DANE mit DNSSEC mithilfe von Exchange PowerShell einrichten.

  4. Andere Integration von Drittanbietern in den Nachrichtenfluss: Einige Kunden verwenden 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 die E-Mail schließlich 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.

  5. Vollständig delegierte Domänen: Domänen, die Von Microsoft gehostet und NS-Delegierung verwendet werden, 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: Wechseln 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, wechseln Sie zum Exchange Admin Center, und stellen Sie sicher, dass die Domäne als "Akzeptierte Domäne" hinzugefügt wird.

    DNSSEC

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

    SMTP DANE

    Ergebnis ErrorData
    Fehler 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
    Fehler ErrorCode: 'DnssecOperationFailed' ErrorDetails 'DNSSEC-Aktivierung fehlgeschlagen...

    SMTP DANE

    Ergebnis ErrorData
    Fehler 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
    Fehler 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 Domänen 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
    Fehler ErrorCode: 'DomainNotSupported' ErrorDetails 'Die angegebene Domäne ...

    SMTP DANE

    Ergebnis ErrorData
    Fehler 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 wurde die Domäne nicht zu Exchange Online hinzugefügt. Wenn Sie der Meinung sind, dass Sie diese Domäne bereits zu Exchange Online hinzugefügt haben, versuchen Sie erneut, das Cmdlet auszuführen, da dieses Problem möglicherweise vorübergehend ist.
    Auszuführende Aktionen: Wiederholen Sie das Cmdlet. Wenn weiterhin ein Fehler auftritt, wechseln 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 keine überprüfte Domäne des organization."
    Ursache: Beim Überprüfen der Konfiguration der Domäne in Exchange Online wurde die Domäne Exchange Online hinzugefügt, aber nicht überprüft.
    Auszuführende Aktionen: Wechseln 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 ist beim Abfragen der Domäne ein allgemeiner DNS-Fehler aufgetreten.
    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 ist beim Abfragen der Domäne ein NXDOMAIN-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.

  5. Meldung: 'ED003: Domäne [{domain}] gefunden. Es wurden keine authentischen MX-Einträge gefunden."
    Ursache: Während der DNSSEC-Überprüfung wurde kein MX-Eintrag gefunden, 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 wurde kein 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 wurde der erwartete MX-Eintrag gefunden, seine Priorität wurde jedoch 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: Während der MX-Überprüfung war der MX-Eintrag mit der höchsten Priorität nicht der erwartete MX-Eintrag.
    Auszuführende Aktionen: Wenn Sie die Schritte 1 bis 4 von Einrichten eingehender SMTP-DANE mit DNSSEC 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 stimmte ein MX-Eintrag für die Domäne nicht mit dem erwarteten MX-Eintrag überein.
    Auszuführende Aktionen: Wenn Sie die Schritte 1 bis 5 von Einrichten eingehender SMTP-DANE mit DNSSEC 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 hatte ein anderer MX-Eintrag eine höhere Präferenz als der erwartete.
    Auszuführende Aktionen: Legen Sie Ihren Mx-Legacyeintrag (der auf 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 wurde kein 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: Während der MX-Überprüfung hatte der erwartete MX-Eintrag die falsche Priorität.
    Auszuführende Aktion(en): Legen Sie Ihren MX-Eintrag (mit dem wert, der bei der Ausführung Enable-DnssecForVerifiedDomain 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: Während der MX-Überprüfung hatte der erwartete MX-Eintrag die falsche Priorität.
    Auszuführende Aktion(en): Legen Sie Ihren MX-Eintrag (mit dem wert, der bei der Ausführung Enable-DnssecForVerifiedDomain 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 wurde kein 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 wurde kein 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 wurde der mx-Wert, der ihrem erwarteten Datensatz entspricht, nicht gefunden.
    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 ist:

  1. Problem mit fehlgeschlagenen SMTP-DANE-Überprüfungen: Informationen zum Beheben dieses Problems finden Sie unter Beheben von Fehlern bei SMTP-DANE-Überprüfungen.
  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 deaktivieren von DNSSEC nicht behoben wird, liegt das Problem möglicherweise an Ihrem MX-Wert.

  2. Deaktivieren Sie DNSSEC für Ihre Domäne über Ihren DNS-Anbieter. Öffnen Sie dann ein Supportticket bei Ihrem DNS-Anbieter, um herauszufinden, wie Sie DNSSEC für Ihre Domäne sicher wieder aktivieren.

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 Hostname-Wert 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 mx-Eintrag, den Sie in Schritt 5 erstellt haben, 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-eintrag token.mail.protection.outlook.com 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 Kunde müssen Sie nichts tun, um diese erweiterte E-Mail-Sicherheit für Ihre ausgehenden E-Mails zu konfigurieren. Wir haben diese erweiterte E-Mail-Sicherheit für Sie erstellt und ist standardmäßig für alle Exchange Online Kunden aktiviert. Exchange Online verwendet diese Sicherheit, 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 folgenden Artikeln 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 an, 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 Sie die Ziel-E-Mail-Adresse richtig eingegeben haben.
  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

Der sendenden E-Mail-Server muss ein gültiges X.509-Zertifikat vorlegen, das nicht abgelaufen ist. 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 bezieht sich auf eine Fehlkonfiguration eines TLSA-Eintrags und kann erst generiert werden, nachdem ein DNSSEC-authentischer TLSA-Eintrag zurückgegeben wurde. Viele Szenarien während der DANE-Überprüfung treten auf, nachdem der Datensatz zurückgegeben wurde, was dazu führen kann, dass der Code generiert wird. Microsoft arbeitet aktiv an den Szenarien, die dieser Fehlercode abdeckt, 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 der authentische TLSA-Eintrag erwartet.
  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

Exchange Online generiert diesen Fehlercode, wenn die Zieldomäne angibt, dass sie DNSSEC-authentic ist, aber Exchange Online sie nicht als DNSSEC-authentic überprüfen kann.

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 können Administratoren von empfangenden Domänen mithilfe der folgenden Standards zwei Methoden verwenden, um ihre DNSSEC- und DANE-Konfiguration zu überprüfen und zu beheben, um E-Mails von Exchange Online zu empfangen:

  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. Zum Empfangen von TLS-RPT-Berichten 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 sendet TLS-RPT-Berichte im JSON-Format.

Die folgende Tabelle zeigt 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 Remote connectivity Analyzer Microsoft Remote Connectivity Analyzer zu verwenden, die die gleichen DNSSEC- und DANE-Überprüfungen für Ihre DNS-Konfiguration durchführen kann, wie Exchange Online beim Senden von E-Mails außerhalb des Diensts. Diese Methode ist die direkteste Methode, um Fehler in Ihrer Konfiguration zu beheben, um E-Mails von Exchange Online mithilfe dieser Standards zu erhalten.

Bei der Problembehandlung von Fehlern 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 an, ob es sich um ein DNSSEC-Problem oder ein anderes DNS-Problem handelt.

Problembehandlung 4/5.7.321 starttls-not-supported

Hinweis

Diese Schritte richten sich an E-Mail-Administratoren, die probleme beim Empfangen von E-Mails von Exchange Online mithilfe von SMTP DANE behandeln.

Dieser Fehler weist in der Regel auf ein Problem mit dem Ziel-E-Mail-Server hin. Die Remotekonnektivitätsanalyse testet die Verbindung mit dem E-Mail-Server. Dieser Code wird in der Regel in zwei Szenarien generiert:

  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, entfernen Sie den TLSA-Eintrag, und führen Sie den Test erneut mit dem Tool Remote Connectivity Analyzer aus.
  6. Wenn keine Fehler auftreten, weist diese Meldung möglicherweise darauf hin, dass der E-Mail-Server, den Sie zum Empfangen von E-Mails verwenden, STARTTLS nicht unterstützt. Möglicherweise müssen Sie ein Upgrade auf ein Upgrade durchführen, das STARTTLS unterstützt, um DANE verwenden zu können.

Problembehandlung 4/5.7.322 Zertifikat abgelaufen

Hinweis

Diese Schritte richten sich an E-Mail-Administratoren, die probleme beim Empfangen von E-Mails von Exchange Online mithilfe von SMTP DANE behandeln.

Der sendenden E-Mail-Server muss ein gültiges X.509-Zertifikat vorlegen, das nicht abgelaufen ist. 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 er 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 überprüft hat, laden Sie ein neues Zertifikat herunter.
  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 richten sich an E-Mail-Administratoren, die probleme beim Empfangen von E-Mails von Exchange Online mithilfe von SMTP DANE behandeln.

Dieser Fehlercode bezieht sich auf eine Fehlkonfiguration eines TLSA-Datensatzes. Der Fehlercode kann erst generiert werden, nachdem ein DNSSEC-authentischer TLSA-Eintrag zurückgegeben wurde. Viele Szenarien während der DANE-Überprüfung treten jedoch auf, nachdem der Datensatz zurückgegeben wurde, was dazu führen kann, dass der Code generiert wird. Microsoft arbeitet aktiv an den Szenarien, die dieser Fehlercode abdeckt, 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 noch nicht gültig oder für ein zukünftiges Zeitfenster 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.
  2. Identifizieren Sie den TLSA-Eintrag, der dem 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 im TLSA-Eintrag enthalten sind.
    1. Wenn Sie den Datensatz auf 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 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 überprüft 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 richten sich an E-Mail-Administratoren, die probleme beim Empfangen von E-Mails von Exchange Online mithilfe von SMTP DANE behandeln.

Exchange Online generiert diesen Fehlercode, wenn die Zieldomäne ihre DNSSEC-Authentic angibt, Exchange Online sie jedoch nicht als DNSSEC-authentic überprüfen können. 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, jetzt aber nicht.

Hinweis

Exchange Online generiert diesen Fehlercode auch, wenn eine SERVFAIL-Antwort von einem DNS-Server in einer TLSA-Abfrage für die Zieldomäne empfangen wird.

Nach dem Empfang der Nachricht:

  1. Wenn Sie einen DNS-Anbieter wie GoDaddy verwenden, benachrichtigen Sie Ihren DNS-Anbieter über den Fehler, damit er bei der Problembehandlung und Konfigurationsänderung arbeiten kann.
  2. Wenn Sie Ihre eigene DNSSEC-Infrastruktur verwalten, können viele DNSSEC-Fehlkonfigurationen diese Fehlermeldung generieren. Überprüfen Sie, ob diese häufig auftretenden Probleme auftreten, wenn Ihre Zone zuvor die DNSSEC-Authentifizierung bestanden 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äne ü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 Sie eine ausgehende E-Mail senden und dnssec für die empfangende Domäne aktiviert ist, Exchange Online Abfragen nach TLSA-Einträgen, 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. Exchange Online verschiebt diese E-Mail mit dem folgenden Fehler:

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 wie GoDaddy verwenden, benachrichtigen Sie Ihren DNS-Anbieter über den Fehler, damit er die DNS-Antwort beheben kann. Wenn Sie Ihre eigene DNSSEC-Infrastruktur verwalten, kann das Problem mit dem DNS-Server selbst oder mit dem Netzwerk zusammenhingen.

Häufig gestellte Fragen

Kann ich als Exchange Online Kunde die Verwendung von DNSSEC und DANE deaktivieren?

Wir sind fest davon überzeugt, dass DNSSEC und DANE die Sicherheit unseres Dienstes erheblich erhöhen und allen unseren Kunden zugute kommen. Im letzten Jahr haben wir sorgfältig daran gearbeitet, das Risiko und den Schweregrad der potenziellen Auswirkungen dieser Bereitstellung für Microsoft 365-Kunden zu verringern. Wir überwachen und verfolgen die Bereitstellung aktiv, um sicherzustellen, dass die negativen Auswirkungen beim Rollout minimiert werden. Aus diesem Grund sind Ausnahmen auf Mandantenebene oder keine Abmeldung verfügbar. Wenn Probleme im Zusammenhang mit der Aktivierung von DNSSEC und DANE auftreten, helfen Ihnen die verschiedenen In diesem Dokument aufgeführten Methoden zur Untersuchung von Fehlern, die Ursache des Fehlers zu identifizieren. In den meisten Fällen liegt das Problem bei der externen Zielpartei, und Sie müssen diesen Geschäftspartnern mitteilen, dass sie DNSSEC und DANE ordnungsgemäß konfigurieren müssen, um E-Mails von Exchange Online zu empfangen, 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, sie 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 verweist und nicht auf den tatsächlichen Endpunkt für die Domäne. Dieser Spoof ist eine Lücke in der E-Mail-Sicherheit, die MTA-STS und SMTP DANE mit DNSSEC-Adresse.

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.

Zusätzliche Ressourcen

  • Last updated on