Identifizieren Sie, welcher Microsoft-Dienst die Nachricht empfängt
„Microsoft-hosted Mail“ identifiziert keine universelle Weiterleitungsrichtlinie. Stellen Sie zunächst fest, ob es sich bei dem Ziel um eine Microsoft 365 -Organisation, ein Outlook .com-Konto für Verbraucher oder eine Route handelt, die über einen anderen Sicherheitsdienst führt, bevor sie ein Microsoft-Postfach erreicht. Die in einer Umgebung verfügbaren Verwaltungskontrollen und Beweise sollten nicht für eine andere übernommen werden.
Dieser Workflow verwendet die aktuelle Microsoft 365 Dokumentation für von der Organisation verwaltete E-Mails und erfordert die Überprüfung der tatsächlichen Route. Es handelt sich um einen vorgeschlagenen Untersuchungs- und Änderungsplan und nicht um einen Bericht darüber, dass Mietereinstellungen überprüft oder geändert wurden. Führen Sie zunächst einen Direkt-gegen-Weiterleitungs-Vergleich durch und wählen Sie dann die kleinste Änderung aus, die den nachgewiesenen Fehler behebt und gleichzeitig die Sicherheitskontrollen der Organisation beibehält.
Suchen Sie die Grenze, an der sich die Authentifizierung geändert hat
Zeichnen Sie den Pfad vom ursprünglichen Absender über alle Weiterleitungen oder Gateways zum empfangenden Dienst. Notieren Sie für jede Grenze den verbindenden Host, der verfügbar ist Umschlagabsender, Autorendomäne, DKIM Signaturen und beobachtete Transformationen. Unterscheiden Sie einen eingehenden Drittanbieter-Vermittler von der Weiterleitung von E-Mails durch Exchange Online nach außen. Es handelt sich um unterschiedliche operative Fälle, auch wenn beide im selben Gespräch auftreten.
SPF verwendet die endgültige Verbindungsquelle für die dort ausgewertete Identität, sodass die Autorisierung der ursprünglichen Quelle möglicherweise nicht die Weiterleitungsverbindung beschreibt. RFC 7208 Abschnitt 10.3 erklärt diese Einschränkung. Ein Analyst sollte den ursprünglichen Absender nicht ändern SPF Eintrag bis die betroffene Identität und die beabsichtigte Autorisierung geklärt sind.
Vergleichen Sie die Original- und Endunterschriften mit RFC 6376. Die Inhaltsänderung eines Gateways kann eine Signatur ungültig machen, wenn das abgedeckte Material danach geändert wird Kanonisierung. Dies ist an Bedingungen geknüpft und stellt keinen Anspruch darauf dar, dass alle hinzugefügten Header oder alle Weiterleitungsregeln DKIM zerstören. Bewahren Sie rohe Nachrichtenkopien auf, sofern dies zulässig ist, damit die Hypothese getestet werden kann und nicht aus einem Anbieterdiagramm abgeleitet werden muss.
Lesen Sie Microsoft-Ergebnisse, ohne sie umzubenennen
Microsofts Authentifizierungsübersicht unterscheidet SPF , DKIM und DMARC aus der zusammengesetzten Authentifizierung, aufgezeichnet als compauth. Letzteres beinhaltet eine zusätzliche Beurteilung. Halten Sie jedes Feld und die abschließende Bearbeitungsaktion in separaten Spalten. Ein zusammengesetzter Pass sollte nicht in den Vorfalldatensatz als gewöhnlicher DMARC Pass umgeschrieben werden.
Die jetzige vertrauenswürdige ARC Versiegelungsanleitung beschreibt die Verwendung früherer Bewertungen legitimer Vermittler und stellt ein Diagnosebeispiel mit compauth=pass und reason=130 bereit, während dmarc=fail sichtbar bleibt. Es weist auch darauf hin, dass andere Filter immer noch funktionieren können. Dabei handelt es sich um eine anbieterspezifische Interpretation zur Überprüfung der von vertrauenswürdigen Empfängern generierten Ergebnisse und nicht um ein Versprechen, dass in jedem Konto dieselben Felder angezeigt werden.
Vertraue keinem Willkürlichen Authentication-Results Zeile einfach deshalb, weil sie sich am oberen Rand einer eingefügten Kopfzeile befindet. Stellen Sie fest, welches empfangende System das Ergebnis generiert hat und wie die vertrauenswürdige Grenze identifiziert wird. Wenn nur ein Screenshot oder ein gekürzter Auszug verfügbar ist, erfassen Sie die fehlende Herkunft und fordern Sie im Rahmen des genehmigten Prozesses eine entsprechend redigierte vollständige Probe an.
Halten Sie SRS- und ARC Entscheidungen getrennt
Microsofts SRS-Dokumentation betrifft anwendbare Weiterleitungs- und Relay-Szenarien und trennt explizit das umgeschriebene MAIL FROM vom sichtbaren Von. Es dokumentiert auch Ausnahmen. Gehen Sie nicht davon aus, dass jede Nachricht, die in Microsoft 365 eingeht, die gleiche Umschreibung erhält, und behandeln Sie sie auch nicht nach außen SRS Verhalten als Lösung für ein unabhängiges Eingangs-Gateway.
Ein umgeschriebener Umschlag kann SPF für die umgeschriebene Domäne ohne unterstützen Ausrichtung an den ursprünglichen Autor. Die entsprechende Domänenbeziehung ist weiterhin erforderlich RFC 9989 Abschnitt 4.4. ARC Stattdessen werden frühere Authentifizierungsbewertungen übermittelt, die ein Empfänger berücksichtigen kann. RFC 8617 Abschnitt 7.2.1 beschreibt die Verwendung lokaler Richtlinien, nicht die automatische Ersetzung des normalen Authentifizierungsergebnisses.
Jeder Vorschlag, einem Versiegeler zu vertrauen, ist eine Sicherheitsentscheidung. Identifizieren Sie den genauen legitimen Dienst, seinen betrieblichen Bedarf und einen verantwortlichen Genehmiger; Behalten Sie die früheren Konfigurations- und Entfernungskriterien bei. Fügen Sie kein breites Vertrauen hinzu, nur weil eine Nachricht einen syntaktisch gültigen ARC Satz enthält. Die jetzige ARC Neuklassifizierungsentwurf ist in Arbeit, während RFC 8617 zum jetzigen Zeitpunkt noch experimentell ist.
Fiktive Gateway-Änderung mit begrenztem Akzeptanztest
In diesem fiktiven Beispiel empfängt Beispieldienste E-Mails über ein Content-Gateway vor einem Microsoft 365 -Postfach. Eine erfundene Direktprobe verifiziert eine Ausrichtung DKIM Signatur; Ein gleichwertiges Beispiel mit Gateway-Routing verfügt über einen umgeschriebenen Anhang und überprüft diese Signatur nicht mehr. Das Szenario geht davon aus, dass diese Beobachtungen ausschließlich der Erklärung der Untersuchung dienen. Es wurde auf keinen Mandanten oder keine Nachricht zugegriffen.
Der Eigentümer würde zunächst feststellen, ob die Transformation notwendig ist und ob eine weniger störende Konfiguration unterstützt wird. Wenn eine ARC-basierte Behandlung vorgeschlagen würde, wären für die Überprüfung die tatsächliche Identität des Versiegelers, authentifizierte Kettennachweise und eine spezifische Zustimmung des Mieters erforderlich. Akzeptanzkriterien würden gewöhnliche Authentifizierung, zusammengesetzte Ergebnisse, Sicherheitsfilterung und Disposition separat erfassen. Ein erfolgreiches Erscheinungsbild im Posteingang allein würde den beabsichtigten Mechanismus nicht demonstrieren.
Zu den Wiederherstellungskriterien sollten ein unerwartet breites Vertrauen, eine erneute Fehlklassifizierung oder das Versäumnis, die erforderlichen Beweise zu sichern, gehören. Der Rollback-Plan sollte die genaue genehmigte Konfiguration angeben und nicht einfach jemanden anweisen, die Sicherheitsverarbeitung zu deaktivieren, bis Nachrichten eintreffen.
Schließen Sie nur die Route, die überprüft wurde
Vergleichen Sie nach einer autorisierten Änderung neue direkte und indirekte Stichproben mit der Basislinie für repräsentative Nachrichten. Behalten Sie die Einstellungsversion, Zeitstempel und etwaige verbleibende Anbieter- oder Mieterunsicherheiten bei. Ein funktionierender Pfad über ein Gateway validiert nicht jede Weiterleitungsregel in der Organisation.
Der Original-Beweis-Gate ist unverändert und sichtbar: direkte und indirekte Lieferproben mit Route, Umschlag, Unterschriften und vertrauenswürdigen Ergebnissen im Vergleich. Hier sind keine derartigen betrieblichen Nachweise, Mietergenehmigungen, Live-Tests oder Sanierungsdurchführungen enthalten. Bei dem Ergebnis handelt es sich um ein überprüfbares Verfahren mit quellengestützten Unterscheidungen und nicht um eine abgeschlossene Microsoft 365 Behebung.