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

Email Authentifizierung ist eine wichtige Komponente für die Sicherung der Kommunikation in Ihrem organization. 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 erfolgreich war oder fehlgeschlagen ist.
• 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.

Zunächst jedoch einige Definitionen, wie in der folgenden Tabelle beschrieben:

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.

Absender bezieht sich auf Administratoren im Quell-organization. Empfänger bezieht sich auf Administratoren im Ziel organization.

Alle Authentifizierungsprüfungen bestanden

• 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

• Headerbeispiel: compauth=pass (zusammengesetzter Authentifizierungsdurchlauf).

• Was das bedeutet: Die Nachricht hat die zusammengesetzte Microsoft 365-Authentifizierung übergeben:

  • Die DMARC-Anforderungen wurden erfüllt: Entweder SPF oder DKIM wurde übergeben , und die MAIL FROM- und From-Adressen sind ausgerichtet.

    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)

• 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 über keine DMARC-Richtlinie verfügt, kann die Nachricht von Ziel-E-Mail-Servern auf DMARC nicht fehlschlagen. 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)

• Headerbeispiel: compauth=pass reason=130 (zusammengesetzte Authentifizierung wurde aufgrund von ARC übergeben).
• Was dies bedeutet: Die Nachricht hat die Authentifizierung aufgrund einer ARC-Außerkraftsetzung (Authenticated Received Chain) 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 übergeben.

Nachricht, die aufgrund von Zulassungseinträgen für spoofte Absender in der Zulassungs-/Sperrliste des Mandanten übermittelt wurde

• Was dies bedeutet: Die Nachricht hat normale Authentifizierungsfehleraktionen umgangen, da zulassungseinträge für spoofte Absender in der Mandanten-Zulassungs-/Sperrliste vorhanden sind. In Microsoft 365 kann ein Zulassungseintrag für gefälschte Absender Fehler überschreiben. Selbst wenn E-Mail-Authentifizierungsprüfungen normalerweise fehlschlagen, ist die Nachricht aufgrund dieser expliziten Vertrauenskonfiguration zulässig.

• Headerbeispiel: compauth=fail reason=000 (eine organization Richtlinie hat jedoch die Meldung zugelassen: Spoof für Mandanten zulassen/Blockieren der Liste zulässig).

• Verantwortlicher: Der Empfänger. Administratoren im organization des Empfängers einen Zulassungseintrag für Spoofing in der Mandantenliste Zulassen/Blockieren für dieses bestimmte Domänenpaar 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 Entitätsseite Email überprüfen, um zu bestätigen, ob eine Außerkraftsetzung der Zulassungs-/Sperrliste für Mandanten beteiligt ist. Diese Meldungen enthalten zulässig durch organization Richtlinie: Mandanten-Zulassungs-/Sperrlisten-Spoof zulässig.

  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 Überbenutzung der Mandanten-Zulassungs-/Sperrliste ermöglicht die Übermittlung von (möglicherweise böswilligen) Nachrichten, die normalerweise bei Authentifizierungsprüfungen fehlschlagen würden.

Authentifiziert über PTR-Ausrichtung (Reverse DNS)

• Headerbeispiel: compauth=pass mit Codes wie reason=116 oder reason=111 , um die Verwendung von PTR-Datensätzen anzugeben.
• Was dies bedeutet: Die Nachricht hat die Authentifizierung basierend auf der PTR-Überprüfung (Reverse DNS) als Fallback bestanden. In einigen Fällen, in dem SPF- und DKIM-Überprüfungen keinen schlüssigen Durchlauf ergeben, kann Microsoft 365 den PTR-Eintrag des Absenders anzeigen. 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.

Absender bezieht sich auf Administratoren im Quell-organization. Empfänger bezieht sich auf Administratoren im Ziel organization.

DMARC Failed (Message Rejected or Quarantined)

• Headerbeispiel: dmarc=fail action=quarantine (oder action=reject); häufig begleitet von compauth=fail einem Code (z. B reason=000. , reason=001oder reason=601).

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

  • SPF oder DKIM wurden nicht mit Ausrichtung für die Von-Adressdomäne übergeben.

    Und

  • Der DMARC-Datensatz der Adressdomäne "From" enthält eine - oder p=reject -p=quarantineRichtlinie.

  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 oder die komplexe E-Mail-Routingkonfiguration des Empfängers nicht übergibt, die zu einem Fehler bei 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 organization des Empfängers verwendet einen Nicht-Microsoft-Filterdienst zwischen dem Internet Microsoft 365, ohne die 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) erfolgreich ist und auch an der Von-Adressdomäne ausgerichtet ist, wie für DMARC erforderlich.
    • Ü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:

    • Konfigurieren der erweiterten Filterung für Connectors
    • 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

• Headerbeispiel: spf=fail oder spf=softfail. spf=temperror Achten Sie auf vorübergehende DNS-Probleme oder spf=permerror SPF-Konfigurationsprobleme.

• 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:
    • Richten Sie die Domänen aus, die in den Adressen MAIL FROM und From verwendet werden.
    • 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 Notwendigkeit von mehr als 10 DNS-Lookups. Vereinfachen Sie den SPF-Eintrag, indem Sie unnötige include: Anweisungen entfernen und Alle Syntaxfehler korrigieren.

Das Beheben von SPF-Problemen bedeutet, dass Nachrichten die DMARC-Authentifizierung wahrscheinlicher 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)

• 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 ausgerichtet ist, sehen dkim=pass empfänger ihre Nachrichten, was auch hilft, die Nachrichten dmarc zu bestehen.

FEHLER BEI DKIM nach Änderung (Signatur wurde nicht überprüft)

• 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.

FEHLER BEI DKIM nach Änderung (Fehler beim Texthash)

• 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

Dieser Abschnitt enthält eine vereinfachte Tabelle, in der die Szenarien, die empfohlenen Lösungen und Links zu relevanten Artikeln für weitere Lektüre zusammengefasst sind.

Absender bezieht sich auf Administratoren der sendenden Domäne. Empfänger bezieht sich auf die Administratoren des empfangenden organization.

Bewährte Methoden und Tipps

• 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.

• Seien Sie vorsichtig mit Zulassungslisten: Verlassen Sie sich nach Möglichkeit auf Standardauthentifizierungsergebnisse, anstatt organization Zulassen von Einträgen. 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:

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