Een stroomafwaarts DMARC pass bewijst niet dat de persoon die een bericht heeft geïnitieerd, bevoegd was om de zichtbare afzender te gebruiken. Het LaunDroMARC-onderzoek van Engage Security uit december 2025 beschrijft een indirecte route waarbij remailing de identiteit verandert die wordt beoordeeld door SPF. Begrijp de afzonderlijke hops voordat u de bevinding beschrijft als een universele DMARC bypass of ervan uitgaat dat elke Microsoft-tenant zich vandaag de dag op dezelfde manier gedraagt.
Scheid de twee bewijsbronnen
De oorspronkelijke onderzoeker beschrijft een binnenkomend bericht dat SPF passeerde voor zijn eigen envelopdomein, maar DMARC mislukte tegen het geïmiteerde zichtbare Van-domein. In het gerapporteerde geval herschreef een Microsoft 365 doorstuurpad de envelop naar het doorstuurdomein, dat ook overeenkwam met het zichtbare Van-domein. De laatste ontvanger observeerde vervolgens uitgelijnde SPF . De onderzoekers melden een verschillende behandeling van het origineel en de doorgestuurde kopieën. Dit zijn toegeschreven bevindingen uit hun onderzoek, geen observaties die voor dit onderzoek zijn gedaan. Schakel beveiligingsonderzoek in.
De documentatie van Microsoft legt dat uit SRS veranderingen MAIL VAN, niet het zichtbare Van-veld, en geeft herschrijfpatronen voor toepasselijke doorstuurroutes. Het waarschuwt ook dat SRS DMARC normaal gesproken niet oplost uitlijning voor doorgestuurde post. Deze uitspraken zijn verenigbaar met de bijzondere identiteitstoeval van het onderzoek: normaal gesproken verschilt het oorspronkelijke Van-domein van het domein van de doorstuurder; de gemelde casus betreft bewust hetzelfde domein. Microsoft SRS-documentatie.
Begrijp het stroomafwaartse oordeel
Referenties: RFC 9989 §4.4, RFC 8601 §5.
SPF vraagt of de verbindende host geautoriseerd is voor de envelopidentiteit op die hop. DMARC vergelijkt een geverifieerd domein met het zichtbare Van-domein. Geen van beide resultaten reconstrueert op zichzelf hoe de oorspronkelijke actor toegang kreeg tot een doorstuurworkflow. Een stroomafwaarts afgestemd resultaat kan daarom correct zijn voor de geëvalueerde identiteiten, terwijl het nog steeds onvoldoende bewijs is van bedrijfsautorisatie.
Interpreteer geen SRS-uiterlijk Return-Path als bewijs dat Microsoft het heeft geproduceerd. Behoud de vertrouwde resultaten van de uiteindelijke ontvanger, peer-informatie en berichttracering, en vergelijk bewijsmateriaal van de ontvangst- en doorstuurgrenzen. Willekeurig ingebed Authentication-Results tekst is geen betrouwbaar oordeel. RFC 8601 legt de vereiste voor de vertrouwensgrens uit; RFC 9989 levert de domeinuitlijningscontext.
Reproduceer alleen de identiteitsvergelijking
Het niet-leveringsmodel van het privérecensiepakket bevat twee fictieve gevallen. In het normale geval verschilt het originele zichtbare domein auteur.test van de herschreven forwarder.test-envelop, dus de aangenomen stroomafwaartse SPF pas blijft niet uitgelijnd. In het tweede geval is het zichtbare domein forwarder.test; dezelfde herschreven envelop is nu uitgelijnd. Beide beginnen met een ander origineel envelopdomein en zijn niet uitgelijnd DKIM.
De bewaarde armatuurinvoer werd op 8 november 2026 offline opnieuw berekend met behulp van deze exacte domeinvergelijking. Het verzendt geen vervalste e-mail, maakt geen doorstuurregels, oefent geen Exchange Online uit, implementeert SRS-hashes of bewijst dat een huidige huurder de route accepteert. Het doel ervan is uit te leggen waarom de twee uitspraken verschillen zonder een aanval op een echte dienst te reproduceren. Historisch leveranciersgedrag, huidig huurdergedrag en de abstracte vergelijking blijven afzonderlijk gelabeld.
Defensief onderzoeken
Voorraad geautoriseerde externe expeditie en de bedrijfseigenaren. Bewaar bij een vermoedelijk incident de originele en doorgestuurde kopieën, tijdstempels, routeringsmethode, pre-forward authenticatie en eindresultaten. Bekijk de huidige documentatie en berichttracering van de provider voordat u een regel wijzigt. De Microsoft-bron maakt onderscheid tussen toepasbare doorstuurprocedures en relaispool- en on-premises gevallen, dus één enkele configuratieclaim is niet voldoende om elk pad te dekken.
Pas wijzigingen toe via het goedgekeurde e-mailbeveiligingsproces van de organisatie en test daarna legitieme workflows. Vermijd brede toestemmingsregels die uitsluitend zijn gebaseerd op de infrastructuur van de provider of de downstream-pasresultaten. In dit artikel worden het mechanisme en de onderzoeksvragen uiteengezet. Het claimt geen niet-geverifieerde hersteldatum, universele blootstelling, succesvolle exploitatie of een huidig Microsoft-servicedefect.