Ein stromabwärts DMARC pass stellt nicht sicher, dass die Person, die eine Nachricht initiiert hat, berechtigt war, ihren sichtbaren Absender zu verwenden. Die LaunDroMARC-Studie vom Dezember 2025 von Engage Security beschreibt einen indirekten Weg, bei dem Remailing die von Ihnen bewertete Identität ändert SPF. Verstehen Sie die einzelnen Hops, bevor Sie das Ergebnis als universelle DMARC Umgehung beschreiben oder davon ausgehen, dass sich jeder Microsoft-Mandant heute gleich verhält.
Trennen Sie die beiden Beweisquellen
Der ursprüngliche Forscher beschreibt eine eingehende Nachricht, die SPF für ihre eigene Umschlagdomäne bestanden hat, aber DMARC für die imitierte sichtbare Von-Domäne nicht bestanden hat. Im gemeldeten Fall schrieb ein Microsoft 365 Weiterleitungspfad den Umschlag in die Weiterleitungsdomäne um, die auch mit der sichtbaren Von-Domäne übereinstimmte. Der Endempfänger beobachtete dann den ausgerichteten SPF . Die Forscher berichten von einer unterschiedlichen Behandlung des Originals und der weitergeleiteten Kopien. Hierbei handelt es sich um zugeschriebene Ergebnisse ihrer Untersuchung, nicht um Beobachtungen, die für diese Überprüfung gemacht wurden. Beteiligen Sie sich an der Sicherheitsforschung.
Die Dokumentation von Microsoft erklärt das SRS Änderungen POST VON, nicht das sichtbare Von-Feld, und gibt Umschreibmuster für anwendbare Weiterleitungsrouten an. Außerdem wird gewarnt, dass SRS DMARC normalerweise nicht löst Ausrichtung für weitergeleitete Post. Diese Aussagen sind mit der besonderen Identitätskoinzidenz der Forschung vereinbar: Normalerweise unterscheidet sich die ursprüngliche Von-Domäne von der Domäne des Weiterleiters; Der gemeldete Fall betrifft bewusst dieselbe Domain. Microsoft SRS-Dokumentation.
Verstehen Sie das nachgelagerte Urteil
Referenzen: RFC 9989 §4.4, RFC 8601 §5.
SPF fragt, ob der verbindende Host für die Umschlagidentität an diesem Hop autorisiert ist. DMARC vergleicht eine authentifizierte Domäne mit der sichtbaren Von-Domäne. Keines der beiden Ergebnisse lässt sich für sich allein rekonstruieren, wie der ursprüngliche Akteur Zugriff auf einen Weiterleitungsworkflow erlangte. Ein nachgelagertes abgeglichenes Ergebnis kann daher für die bewerteten Identitäten korrekt sein und dennoch keinen ausreichenden Nachweis der Geschäftsberechtigung darstellen.
Interpretieren Sie kein SRS-Looking Return-Path als Beweis dafür, dass Microsoft es produziert hat. Bewahren Sie die vertrauenswürdigen Ergebnisse, Peer-Informationen und die Nachrichtenverfolgung des Endempfängers und vergleichen Sie Beweise aus den Empfangs- und Weiterleitungsgrenzen. Beliebig eingebettet Authentication-Results Text ist kein vertrauenswürdiges Urteil. RFC 8601 erläutert die Vertrauensgrenzenanforderung; RFC 9989 Stellt den Domänenausrichtungskontext bereit.
Reproduzieren Sie nur den Identitätsvergleich
Das Nichtzustellungsmodell des privaten Rezensionspakets enthält zwei fiktive Fälle. Im Normalfall unterscheidet sich die ursprünglich sichtbare Domäne „author.test“ vom umgeschriebenen Umschlag „forwarder.test“, sodass der angenommene Downstream SPF Durchlauf nicht ausgerichtet bleibt. Im zweiten Fall ist die sichtbare Domäne forwarder.test; Derselbe umgeschriebene Umschlag wird jetzt ausgerichtet. Beide beginnen mit einer anderen ursprünglichen Umschlagdomäne und sind nicht ausgerichtet DKIM.
Die beibehaltenen Fixture-Eingaben wurden am 8. November 2026 mithilfe dieses exakten Domänenvergleichs offline neu berechnet. Es versendet keine gefälschten E-Mails, erstellt keine Weiterleitungsregeln, übt keine Exchange Online aus, implementiert keine SRS-Hashes und weist auch nicht nach, dass ein aktueller Mieter die Route akzeptiert. Sein Zweck besteht darin, zu erklären, warum die beiden Urteile unterschiedlich sind, ohne einen Angriff auf einen echten Dienst zu reproduzieren. Historisches Anbieterverhalten, aktuelles Mieterverhalten und der abstrakte Vergleich bleiben gesondert gekennzeichnet.
Untersuchen Sie defensiv
Inventar autorisierte externe Spedition und deren Geschäftsinhaber. Bewahren Sie bei einem vermuteten Vorfall das Original und die weitergeleiteten Kopien, Zeitstempel, Routing-Methode, Authentifizierung vor der Weiterleitung und Endergebnisse auf. Überprüfen Sie die aktuelle Dokumentation und Nachrichtenverfolgung des Anbieters, bevor Sie eine Regel ändern. Die Microsoft-Quelle unterscheidet anwendbare Weiterleitungen von Relay-Pool- und lokalen Fällen, sodass ein einzelner Konfigurationsanspruch nicht ausreicht, um jeden Pfad abzudecken.
Wenden Sie Änderungen über den genehmigten E-Mail-Sicherheitsprozess der Organisation an und testen Sie anschließend legitime Arbeitsabläufe. Vermeiden Sie weitreichende Zulassungsregeln, die ausschließlich auf der Anbieterinfrastruktur oder den Downstream-Pass-Ergebnissen basieren. In diesem Artikel werden der Mechanismus und die Untersuchungsfragen erläutert. Es wird kein unbestätigter Behebungstermin, keine allgemeine Offenlegung, keine erfolgreiche Ausnutzung oder ein aktueller Microsoft-Dienstfehler behauptet.