Leitfaden für Sicherheitsvorgänge für die E-Mail-Authentifizierung in Microsoft 365

Die E-Mail-Authentifizierung in Microsoft 365 ist eine wichtige Komponente der Sicherung der Kommunikation in Ihrer Organisation. Wenn eine E-Mail in Microsoft 365 empfangen wird, fügt der Dienst einen Authentication-Results-Header hinzu. Dieser Header zeigt die Ergebnisse verschiedener E-Mail-Authentifizierungsprüfungen an, einschließlich SPF, DKIM, DMARC und zusammengesetzter Authentifizierung (Compauth).

In diesem Leitfaden werden häufige Szenarien erläutert, die bei den folgenden Ergebnissen auftreten können:

• Warum eine Nachricht die E-Mail-Authentifizierung bestanden hat oder nicht.
• Gibt an, ob die E-Mail-Quelle oder das E-Mail-Ziel für das Ergebnis verantwortlich ist.
• Welche Aktionen (falls vorhanden) werden zur Verbesserung der E-Mail-Authentifizierungsergebnisse empfohlen.

Zuerst sind hier jedoch einige wichtige Definitionen aufgeführt:

Szenarios für Email-Authentifizierungspass

Diese Szenarien beschreiben Nachrichten, die E-Mail-Authentifizierungsprüfungen bestanden haben oder akzeptiert wurden (manchmal aufgrund bestimmter Konfigurationen). Wenn die E-Mail-Authentifizierung erfolgreich ist, sind im Allgemeinen keine Korrekturmaßnahmen erforderlich. Einige Szenarien enthalten jedoch Warnungen , in denen wir Konfigurationsverbesserungen empfehlen, um die Sicherheit zu erhöhen.

Sender bezeichnet Administratoren in der Quellorganisation. Empfänger bezeichnet Administratoren in der Zielorganisation.

Alle Authentifizierungsprüfungen bestanden

Dieses Szenario gilt, wenn alle standardmäßigen E-Mail-Authentifizierungsprüfungen erfolgreich bestehen.

• Headerbeispiel: dmarc=pass (und in der Regel spf=pass und dkim=pass).
• Was das bedeutet: Alle E-Mail-Authentifizierungsprüfungen (SPF, DKIM und DMARC) waren erfolgreich. Dieses Ergebnis gibt an, dass die Nachricht gemäß standardbasierten E-Mail-Authentifizierungsprotokollen vollständig authentifiziert ist.
• Verantwortlicher: Der Absender.
• Empfohlene Aktion: Keine. Email Authentifizierung ist ordnungsgemäß konfiguriert und funktioniert wie beabsichtigt. Der Empfänger kann der Absenderdomäne vertrauen, die diese Nachricht ordnungsgemäß authentifiziert hat.

Zusammengesetzte Authentifizierung erfolgreich

Dieses Szenario beschreibt, wie Microsoft 365 eine Nachricht mittels zusammengesetzter Authentifizierung akzeptieren kann.

• Headerbeispiel: compauth=pass (Zusammengesetzte Authentifizierung erfolgreich).

• Was dies bedeutet: Die Nachricht hat die Microsoft 365-Verbundauthentifizierung bestanden:

  • DMARC-Anforderungen wurden erfüllt: Entweder SPF oder DKIM war erfolgreich, und die MAIL FROM- und Absenderadressen stimmen überein.

    Oder

  • Die implizite Vertrauenslogik von Microsoft hat die Nachricht als legitim identifiziert. Beispielsweise kann eine Nachricht eine zusammengesetzte Authentifizierung basierend auf dem sicheren Absenderverlauf von Microsoft oder spoof intelligence übergeben, die angibt, dass der Absender vertrauenswürdig ist.

• Verantwortlicher: Der Absender.

• Empfohlene Aktion: Keine. Die Authentifizierungsprüfungen waren erfolgreich, und das System hat keine Probleme erkannt. In diesem Szenario sind keine Änderungen an SPF oder DKIM erforderlich.

DMARC-Pass ohne DMARC-Richtlinie (kein DMARC-Datensatz)

Dieses Szenario behandelt Nachrichten, die DMARC zu bestehen scheinen, obwohl der Absender keinen DMARC-Eintrag veröffentlicht hat.

• Headerbeispiel: dmarc=bestguesspass action=none
• Was dies bedeutet: Die Nachricht hat STANDARDMÄßIG DMARC übergeben, da die Domäne des Absenders keinen veröffentlichten DMARC-Eintrag aufweist. Wenn eine Domäne keine DMARC-Richtlinie hat, können empfangende E-Mail-Server die Nachricht nicht anhand von DMARC ablehnen. Im Grunde gilt die DMARC-Überprüfung nicht. DMARC=bestguesspass action=none bedeutet, wenn die Domäne über einen gültigen DMARC-Datensatz verfügt, würde die DMARC-Überprüfung für die Nachricht bestanden.
• Verantwortlicher: Der Absender.
• Empfohlene Aktion: Der Absender sollte einen DMARC-Eintrag für seine Domäne veröffentlichen. Obwohl die Nachricht akzeptiert wurde, ist das Fehlen einer DMARC-Richtlinie kein gutes Zeichen. Es wird empfohlen, dass der Domänenbesitzer einen DMARC TXT-Eintrag einrichte, um eine DMARC-Richtlinie (p=quarantine oder p=reject) für Nachrichten zu erzwingen, bei denen die DMARC-Überprüfung fehlschlägt. Weitere Informationen finden Sie unter Syntax für DMARC TXT-Einträge.

ARC-validiert (komplexe Routingszenarien)

Dieses Szenario gilt für Nachrichten, die über ARC-Validierung in Weiterleitungs- oder anderen komplexen Routingpfaden akzeptiert werden.

• Headerbeispiel: compauth=pass reason=130 (zusammengesetzte Authentifizierung war aufgrund von ARC erfolgreich).
• Bedeutung: Die Nachricht hat die Authentifizierung aufgrund einer Außerkraftsetzung durch Authenticated Received Chain (ARC) bestanden. Dieses Ergebnis tritt in der Regel in komplexen E-Mail-Routing- oder E-Mail-Weiterleitungsszenarien auf. Wenn ein Zwischen-E-Mail-Server die Nachricht ändert und SPF oder DKIM fehlschlägt, informiert eine vertrauenswürdige ARC-Signatur Microsoft 365 darüber, dass die ursprüngliche Authentifizierung gültig ist. In diesem Fall hat das System die Nachricht basierend auf der gültigen ARC-Kette akzeptiert, obwohl direkte SPF- oder DKIM-Überprüfungen fehlschlagen können.
• Verantwortlicher: Der Absender (ursprünglicher Absender oder Vermittler). Es gibt keine Fehlkonfiguration. Ein Vermittler, der ARC verwendet, hat die Nachricht verarbeitet.
• Empfohlene Aktion: Keine direkte Aktion erforderlich , wenn dieses Szenario erwartet wird (z. B. wurde die Nachricht von einem bekannten Dienst verarbeitet, der ARC implementiert). Wenn Sie einen Nicht-Microsoft-Zwischendienst betreiben, fügen Sie ARC-Header hinzu, und überprüfen Sie, ob empfangende Server (z. B. Microsoft 365) Ihren ARC-Signaturen vertrauen. Diese Konfiguration ermöglicht es eingehenden Nachrichten, compauth über ARC zu bestehen.

Nachricht wurde aufgrund von Zulassungseinträgen für gefälschte Absender in der Mandanten-Zulassungs-/Sperrliste zugestellt

Dieses Szenario erklärt, warum eine gefälschte Nachricht trotzdem zugestellt werden kann, wenn die Empfängerorganisation sie ausdrücklich zulässt.

• Was es bedeutet: Die Nachricht hat die normalen Maßnahmen bei Authentifizierungsfehlern umgangen, da Zulassungseinträge für gefälschte Absender in der Tenant Allow/Block List vorhanden sind. In Microsoft 365 kann ein Zulassungseintrag für gefälschte Absender Fehler außer Kraft setzen. Selbst wenn E-Mail-Authentifizierungsprüfungen normalerweise fehlschlagen, ist die Nachricht aufgrund dieser expliziten Vertrauenskonfiguration zulässig.

• Headerbeispiel: compauth=fail reason=000 (aber eine Organisationsrichtlinie hat die Nachricht zugelassen: Spoofing in Mandanten-Zulassungs-/Sperrliste zugelassen).

• Verantwortlicher: Der Empfänger. Administratoren in der Organisation des Empfängers haben in der Mandanten-Zulassungs-/Sperrliste einen Zulassungseintrag für Spoofing für diese spezifische Domänenpaarsyntax für gefälschte Absendereinträge konfiguriert. Der Absender sollte Authentifizierungsprobleme beheben, um Zustellbarkeitsprobleme mit anderen Empfängern zu vermeiden.

• Empfohlene Aktion: Empfängeradministratoren können den Abschnitt Alle Außerkraftsetzungen auf der E-Mail-Entitätsseite überprüfen, um zu bestätigen, ob eine Außerkraftsetzung der Mandanten-Zulassungs-/Sperrliste vorliegt. Diese Nachrichten enthalten Zugelassen durch Organisationsrichtlinie: Spoofing in Mandanten-Zulassungs-/Sperrliste zugelassen.

  Im Allgemeinen gibt es keine sofortige Aktion für diese Nachrichten, da sie absichtlich zulässig sind. Es empfiehlt sich jedoch, dass Administratoren in regelmäßigen Abständen Zulassen von Einträgen für gefälschte Absender überprüfen , um sicherzustellen, dass nur erforderliche Absender zulässig sind. Die übermäßige Verwendung der Mandanten-Zulassungs-/Sperrliste ermöglicht die Zustellung von (möglicherweise bösartigen) Nachrichten, die normalerweise bei Authentifizierungsprüfungen fehlschlagen würden.

Authentifiziert über PTR-Ausrichtung (Reverse DNS)

In diesem Szenario wird die Fallbackauthentifizierung basierend auf PTR-Informationen (Reverse DNS) beschrieben, wenn Standardüberprüfungen nicht eindeutig sind.

• Headerbeispiel: compauth=pass mit Codes wie reason=116 oder reason=111 , um die Verwendung von PTR-Datensätzen anzugeben.
• Was es bedeutet: Die Nachricht hat die Authentifizierung auf Grundlage der PTR-Validierung (Reverse DNS) als Fallback erfolgreich durchlaufen. In einigen Fällen kann Microsoft 365, wenn SPF- und DKIM-Überprüfungen zu keinem eindeutigen Ergebnis führen, den PTR-Eintrag des Absenders prüfen. Wenn die IP-Adresse des sendenden Servers über einen PTR-Eintrag (Reverse-DNS) verfügt, der mit der Domäne in der Von-Adresse der Nachricht übereinstimmt, behandelt das System die Nachricht möglicherweise als authentifiziert.
• Verantwortlicher: Der Absender. Der E-Mail-Server des Absenders wurde über den PTR-Eintrag im DNS überprüft. Dieses Ergebnis bedeutet in der Regel, dass SPF und DKIM nicht ordnungsgemäß konfiguriert wurden und das System zur PTR-Suche zurückgegriffen hat.
• Empfohlene Aktion: Der Absender sollte sicherstellen, dass SPF und DKIM für seine Domäne ordnungsgemäß konfiguriert sind . Ein richtiger Reverse-DNS-Eintrag (PTR), der die sendende Domäne der sendenden IP-Adresse zuordnet, ist gut, aber er ist kein Ersatz für die DMARC-Ausrichtung. Absender müssen den PTR-Pass als Indikator behandeln, um ihre SPF- und DKIM-Konfiguration zu verbessern. Es gibt keine Aktion für den Empfänger, außer absender zu benachrichtigen, wenn sie dieses Ergebnis bemerken.

Email Authentifizierungsfehlerszenarien

Diese Szenarien umfassen fehlgeschlagene Authentifizierungsprüfungen oder andere Bedingungen, bei denen die Nachricht als nicht authentifiziert gekennzeichnet ist. Wenn eine Authentifizierungsprüfung fehlschlägt, bedeutet dies nicht immer, dass die Nachricht abgelehnt wurde. Einige Fehler führen dazu, dass die Nachricht unter Quarantäne gestellt oder mit Warnungen zugestellt wird. In den folgenden Szenarien wird beschrieben, warum der Fehler aufgetreten ist, wer ihn beheben muss und wie das zugrunde liegende Problem behoben werden kann.

Sender bezeichnet Administratoren in der Quellorganisation. Empfänger bezeichnet Administratoren in der Zielorganisation.

DMARC fehlgeschlagen (Nachricht abgelehnt oder unter Quarantäne gestellt)

In diesem Szenario wird erläutert, wie Ein DMARC-Fehler interpretiert wird, der zu Quarantäne oder Ablehnung der Nachricht führt.

• Kopfzeilenbeispiel: dmarc=fail action=quarantine (oder action=reject); häufig begleitet von compauth=fail mit einem Code (zum Beispiel reason=000, reason=001 oder reason=601).

• Was dies bedeutet: Fehler bei der DMARC-Überprüfung für die Nachricht. Dieses Ergebnis bedeutet:

  • SPF oder DKIM war mit Übereinstimmung für die Domäne der Absenderadresse nicht erfolgreich.

    Und

  • Der DMARC-Eintrag der Domäne der Absenderadresse enthält eine p=quarantine- oder p=reject-Richtlinie.

  Daher hat Microsoft 365 die Nachricht für die angegebene Richtlinienaktion markiert: Übermittlung an den Junk-Email Ordner, Quarantäne oder Ablehnen.

• Verantwortlicher: Der Absender oder der Empfänger. Der Fehler ist darauf zurückzuführen, dass die Domäne des Absenders DMARC nicht bestanden hat, oder auf die Konfiguration des Empfängers für die Integration von Nicht-Microsoft-Sicherheitsdiensten in Microsoft 365, die zum Fehlschlagen von DMARC geführt hat.

  Während Absender für die ordnungsgemäße Konfiguration von SPF, DKIM und DMARC für ihre Domäne verantwortlich sind, können Authentifizierungsfehler manchmal auf Probleme im organization des Empfängers zurückzuführen sein. Zum Beispiel:

  • Die Organisation des Empfängers verwendet einen Nicht-Microsoft-Filterdienst zwischen dem Internet und Microsoft 365, ohne Erweiterte Filterung für Connectors zu konfigurieren. Die SPF-Überprüfung schlägt möglicherweise fehl, wenn Microsoft 365 die Nachricht empfängt.
  • Wenn der Nicht-Microsoft-Filterdienst die Nachricht vor der Übermittlung ändert, schlägt DKIM möglicherweise fehl, obwohl der DKIM-Eintrag des Absenders ordnungsgemäß konfiguriert ist.

  Daher ist es wichtig, zwischen dem Urteil am Ersten Empfang (MX-Eintrag) und dem Urteil zu unterscheiden, wenn die Nachricht das Postfach des Empfängers erreicht.

• Empfohlene Aktion:

  • Der Absender muss seine E-Mail-Authentifizierungskonfiguration korrigieren. Insbesondere muss der Absender die folgenden Schritte ausführen:

    • Stellen Sie sicher, dass ihr SPF-Eintrag alle legitimen Quell-IP-Adressen für E-Mails aus der Domäne enthält.
    • Richten Sie DKIM für die Domäne ein, und überprüfen Sie, ob die Signaturen ordnungsgemäß auf ausgehende E-Mails angewendet werden.
    • Stellen Sie sicher, dass SPF oder DKIM (oder beides) die Überprüfung bestehen und außerdem wie von DMARC gefordert mit der Domäne der Absenderadresse übereinstimmen.
    • Überprüfen Sie die DMARC-Datensatzsyntax und die DMARC-Richtlinie. Zum Beispiel p=quarantine oder p=reject.

  • Der Empfänger muss seine komplexe E-Mail-Routingkonfiguration korrigieren. Insbesondere muss der Empfänger die folgenden Schritte ausführen:

    • Erweiterte Filterung für Konnektoren konfigurieren
    • Konfigurieren Sie ggf. vertrauenswürdige ARC-Versiegelungen , um Fehler zu überschreiben, die durch Nachrichtenänderung während der Übertragung verursacht werden.
    • Erwägen Sie die Verwendung von Microsoft 365, um Nachrichtenänderungen (Fußzeilen, Haftungsausschlüsse, Betreff usw.) anstelle von Nicht-Microsoft-Diensten anzuwenden.

Fehler bei der SPF-Überprüfung

In diesem Szenario können Sie Nachrichten diagnostizieren, die die SPF-Auswertung fehlschlagen.

• Headerbeispiel: spf=fail oder spf=softfail. Achten Sie auf spf=temperror, was auf vorübergehende DNS-Probleme hinweist, oder auf spf=permerror, was auf Probleme mit der SPF-Konfiguration hinweist.

• Was es bedeutet: Eine der folgenden Möglichkeiten:

  • Die IP-Adresse des sendenden Servers ist nicht durch den SPF-Eintrag der Domäne autorisiert , sodass die SPF-Rückgabe fehlschlägt.
  • Die SPF-Überprüfung konnte nicht ordnungsgemäß abgeschlossen werden. Beispielsweise ein DNS-Nachschlageproblem (spf=temperror) oder zu viele Umleitungen (spf=permerror).

  Ein SPF-Fehler ohne DMARC-Pass führt auch zu einem DMARC-Fehler.

• Verantwortlicher: Der Absender. Das Problem liegt in der SPF-Eintragskonfiguration der Absenderdomäne oder deren Einrichtung des sendenden Servers.

• Empfohlene Aktion: Der Absender sollte den SPF-Eintrag der Domäne aktualisieren und korrigieren:

  • Vergewissern Sie sich, dass alle legitimen Quell-IP-Adressen für die Domäne im SPF-Eintrag enthalten sind.
  • Wenn DMARC aufgrund einer fehlerhaften Domänenausrichtung fehlschlägt (die MAIL FROM-Adressdomäne unterscheidet sich von der Von-Adressdomäne), können Sie dies beheben, indem Sie einen oder beide der folgenden Schritte ausführen:
    • Stimmen Sie die in den Adressen MAIL FROM und From verwendeten Domänen aufeinander ab.
    • Richten Sie die DKIM-Signatur von ausgehenden Nachrichten mithilfe einer Domäne ein, die der Von-Adressdomäne entspricht. DMARC erfordert entweder SPF- oder DKIM-Überprüfung, nicht beides.
  • spf=temperror gibt im Allgemeinen an, dass der Empfänger ein Problem beim Auflösen des SPF-Eintrags hatte (z. B. vorübergehende DNS-Probleme). Der Absender sollte überprüfen, ob die DNS-Server für seine Domäne fehlerfrei und erreichbar sind. Wenn der Wert der Gültigkeitsdauer (Time-to-Live, TTL) zu niedrig ist und häufige Timeouts verursacht, sollten Sie die Gültigkeitsdauer auf mindestens eine Stunde erhöhen.
  • spf=permerror weist in der Regel auf ein Problem mit dem SPF-Eintrag selbst hin, einschließlich der Problembehandlung von SPF TXT-Einträgen, die mehr als 10 DNS-Nachschlagevorgänge erfordern. Vereinfachen Sie den SPF-Eintrag, indem Sie unnötige include: Anweisungen entfernen und alle Syntaxfehler korrigieren.

Durch das Beheben von SPF-Problemen ist es wahrscheinlicher, dass E-Mails die DMARC-Authentifizierung bestehen. Empfänger sollten Absender über SPF-Fehler und die empfohlenen Aktionen zum Beheben der Probleme benachrichtigen.

DKIM-Überprüfung fehlgeschlagen (kein Schlüssel für signatur)

In diesem Szenario werden DKIM-Fehler behandelt, die durch fehlende oder nicht übereinstimmende öffentliche Schlüssel in DNS verursacht werden.

• Headerbeispiel: dkim=fail (kein Schlüssel für die Signatur), wenn der öffentliche Schlüssel fehlt.

• Was es bedeutet: Eine der folgenden Möglichkeiten:

  • Es gab eine DKIM-Signatur, aber der Empfänger konnte keinen übereinstimmenden öffentlichen Schlüssel in DNS (kein Schlüssel) finden.

    Oder

  • Der Schlüssel stimmte nicht mit der Signatur überein (die Signatur konnte nicht überprüft werden).

• Verantwortlicher: Der Absender. Die Domäne des Absenders verfügt über ein fehlerhaftes DKIM-Setup:

  • Im DKIM-CNAME- oder TXT-Eintrag in DNS ist kein öffentlicher Schlüssel vorhanden.

    Oder

  • Es gibt ein DNS-Problem auf der Seite des Absenders oder des Empfängers.

• Empfohlene Aktion: Der Absender sollte die DKIM-Einrichtung für seine Domäne korrigieren , indem er die folgenden Schritte ausführt:

  • Veröffentlichen Sie den öffentlichen DKIM-Schlüssel in DNS. Vergewissern Sie sich, dass der DKIM-CNAME- oder TXT-Eintrag einen gültigen Selektor (z. B. ) enthält, der mit dem privaten Schlüssel übereinstimmt, selector._domainkey.contoso.comder zum Signieren der Nachrichten verwendet wird.
  • Wenn der Schlüssel veröffentlicht wird, ist wahrscheinlich ein Timeout aufgetreten, als Microsoft 365 versucht hat, den Datensatz abzufragen. Vergewissern Sie sich, dass der Wert für die Gültigkeitsdauer (Time-to-Live, TTL) auf mindestens eine Stunde festgelegt ist.

Sobald DKIM ordnungsgemäß konfiguriert und abgestimmt ist, sehen Empfänger dkim=pass für Ihre Nachrichten, was auch dazu beiträgt, dass die Nachrichten DMARC bestehen.

DKIM ist nach einer Änderung fehlgeschlagen (Signatur konnte nicht verifiziert werden)

In diesem Szenario werden DKIM-Fehler erläutert, die durch Kopfzeilenänderungen nach der Signatur verursacht werden.

• Headerbeispiel: dkim=fail (Signatur wurde nicht überprüft).
• Was dies bedeutet: Die Nachricht enthielt eine gültige DKIM-Signatur, aber die Nachricht konnte die DKIM-Überprüfung nicht überprüfen, da ein in der DKIM-Signatur enthaltener Header während der Übertragung nach dem Signieren geändert wurde. Diese Änderung tritt in der Regel auf, wenn ein Vermittler (z. B. eine Adressenliste, ein Weiterleitungsdienst oder ein Sicherheits-Anwendung) einen signierten Header (z. B. Subject:, From:, oder To:) ändert, nachdem die DKIM-Signatur ursprünglich angewendet wurde. Der h= Wert in der DKIM-Signature identifiziert die Header, die im ursprünglichen Hash enthalten sind. Wenn Sie einen dieser Header ändern, tritt ein DKIM-Fehler auf.
• Verantwortlicher: Der Absender oder der Vermittler , der die Nachrichtenkopfzeilen geändert hat. Der ursprüngliche Absender hat die Nachricht ordnungsgemäß von DKIM signiert, aber möglicherweise ist ein Vermittler für die fehlerhafte DKIM-Signatur verantwortlich.
• Empfohlene Aktion: Nehmen Sie keine Änderungen an Headern vor, nachdem DKIM eine Nachricht signiert hat:
  • Absender: Überprüfen Sie, ob die signierten Header von dem Moment an unverändert bleiben, an dem die Nachricht DKIM-signiert ist, bis sie Ihre Umgebung verlässt.
  • Vermittler: Ermöglichen Sie Es Kunden, Ihren Dienst als vertrauenswürdigen ARC-Versiegeler zu konfigurieren, um DKIM-Fehler zu überschreiben, die durch Nachrichtenänderung während der Übertragung verursacht werden.

DKIM nach Änderung fehlgeschlagen (Textkörperhash fehlgeschlagen)

In diesem Szenario werden DKIM-Fehler behandelt, die nach dem Signieren durch Nachrichtentextänderungen verursacht wurden.

• Headerbeispiel: dkim=fail (Texthashfehler).
• Was dies bedeutet: Die Nachricht enthielt eine gültige DKIM-Signatur, aber die Nachricht konnte die DKIM-Überprüfung nicht überprüfen, da der Nachrichtentext während der Übertragung nach dem Signieren geändert wurde. Diese Änderung tritt in der Regel auf, wenn ein Vermittler (z. B. eine Adressenliste, ein Weiterleitungsdienst oder sicherheitsrelevanter Anwendung) den Nachrichtentextinhalt ändert, nachdem die DKIM-Signatur ursprünglich angewendet wurde. Das Ergebnis ist der vom empfangenden E-Mail-System berechnete Hash, der nicht mit dem Hash in der DKIM-Signatur übereinstimmt, sodass die DKIM-Überprüfung fehlschlägt.
• Verantwortlicher: Der Absender oder der Vermittler , der die Nachricht geändert hat. Der ursprüngliche Absender hat die Nachricht ordnungsgemäß von DKIM signiert, aber möglicherweise ist ein Vermittler für die fehlerhafte DKIM-Signatur verantwortlich.
• Empfohlene Aktion: Stellen Sie sicher, dass nach dem Signieren keine unbeabsichtigten Änderungen am E-Mail-Inhalt vorgenommen werden:
  • Absender: Führen Sie die folgenden Schritte aus:
    • Vergewissern Sie sich, dass die signierten Header von dem Moment an unverändert bleiben, an dem die Nachricht DKIM-signiert ist, bis sie Ihre Umgebung verlässt.
    • Erwägen Sie die Verwendung von Microsoft 365, um Nachrichtenänderungen (Fußzeilen, Haftungsausschlüsse, Betreff usw.) anstelle von Nicht-Microsoft-Diensten anzuwenden.
  • Vermittler: Ermöglichen Sie Es Kunden, Ihren Dienst als vertrauenswürdigen ARC-Versiegeler zu konfigurieren, um DKIM-Fehler zu überschreiben, die durch Nachrichtenänderung während der Übertragung verursacht werden.

Kurzübersichtstabelle für E-Mail-Authentifizierungsszenarien

In der folgenden Tabelle sind die E-Mail-Authentifizierungsszenarien, die empfohlenen Lösungen und Links zu relevanten Artikeln zusammengefasst, um weitere Informationen zu erhalten.

Absender bezieht sich auf Administratoren der sendenden Domäne. Empfänger bezeichnet die Administratoren der empfangenden Organisation.

Bewährte Methoden und Tipps

Verwenden Sie die folgenden bewährten Methoden, um die E-Mail-Authentifizierung zu stärken und aufrechtzuerhalten.

• Implementieren von SPF, DKIM und DMARC: Diese Technologien ergänzen sich gegenseitig und bieten tiefgehende Verteidigung. Alles, was weniger ist, hinterlässt Lücken im Schutz.

• Verwalten von DNS-Einträgen: Halten Sie SPF-Einträge mit allen Ihren E-Mail-Quellen auf dem neuesten Stand. Rotieren und verwalten Sie DKIM-Schlüssel nach Bedarf, und überwachen Sie Ihre DMARC-Berichte, um Authentifizierungsfehler zu identifizieren.

• Überwachen von Authentifizierungsergebnissen: Überprüfen Sie regelmäßig die Header von Authentication-Results , oder verwenden Sie Tools/Berichte (z. B. microsoft 365 spoof intelligence insight), um zu sehen, wie eingehende Nachrichten ausgeführt werden. Diese Aktivität kann Partner offenlegen, die SPF/DKIM nicht eingerichtet haben, oder wenn ihre eigene Nachricht die Authentifizierung fehlschlägt.

• Verwenden von ARC für Relayszenarien: Wenn Ihr organization E-Mail-Weiterleitung durchführt oder Nicht-Microsoft-Dienste verwendet, die Nachrichten ändern, sollten Sie die Konfiguration vertrauenswürdiger ARC-Versiegelungen in Microsoft 365 in Betracht ziehen. ARC kann dazu beitragen, die Authentifizierung beizubehalten und falsche Fehler zu vermeiden, wenn Nachrichten über Vermittler übertragen werden.

• Vorsicht bei Zulassungslisten: Verlassen Sie sich nach Möglichkeit auf Standardauthentifizierungsergebnisse anstatt auf Zulassungseinträge der Organisation. Zulassungseinträge sollten Ausnahmen sein und regelmäßig überprüft werden, um unnötige Einträge zu entfernen.

• Bleiben Sie auf dem Laufenden: Befolgen Sie die folgenden Ressourcen:

  • Blog zu Microsoft Defender for Office 365
  • Exchange-Teamblog
  • Neuerungen in Microsoft Defender für Office 365
  • Das Microsoft 365-Nachrichtencenter.