Identificer, hvilken Microsoft-tjeneste, der modtager beskeden
"Microsoft-hostet mail" identificerer ikke én universel videresendelsespolitik. Begynd med at fastslå, om destinationen er en Microsoft 365 organisation, en Outlook .com-forbrugerkonto eller en rute, der går gennem en anden sikkerhedstjeneste, før den når en Microsoft-postkasse. Den administrative kontrol og dokumentation, der er tilgængelig i et miljø, bør ikke antages for et andet.
Denne arbejdsgang bruger den aktuelle Microsoft 365 dokumentation til organisationsadministreret post og kræver, at den faktiske rute skal verificeres. Det er en foreslået undersøgelse og ændringsplan, ikke en rapport om, at eventuelle lejerindstillinger er blevet inspiceret eller ændret. Få først en direkte-versus-videresendt sammenligning, og vælg derefter den mindste ændring, der løser den påviste fejl, samtidig med at organisationens sikkerhedskontroller bevares.
Find den grænse, hvor godkendelsen er ændret
Tegn stien fra den oprindelige afsender gennem hver speditør eller gateway til den modtagende tjeneste. For hver grænse skal du registrere den tilsluttede vært, der er tilgængelig konvolutafsender, forfatterdomæne, DKIM signaturer og observerede transformationer. Skelne en indgående tredjepartsformidler fra Exchange Online der videresender post udad. De er forskellige operationelle tilfælde, selv når begge opstår i den samme samtale.
SPF bruger den endelige forbindelseskilde til den identitet, der vurderes der, så den oprindelige kildes autorisation beskriver muligvis ikke videresendelsesforbindelsen. RFC 7208 afsnit 10.3 forklarer den begrænsning. En analytiker bør ikke ændre den oprindelige afsenderes SPF rekord indtil den berørte identitet og påtænkte autorisation er forstået.
Sammenlign de originale og endelige signaturer vha RFC 6376. En gateways indholdsændring kan ugyldiggøre en signatur, når den ændrer dækket materiale efter kanonisering. Dette er betinget, ikke en påstand om, at alle tilføjede overskrifter eller alle videresendelsesregler ødelægger DKIM . Bevar råbeskedkopier, hvor de er godkendt, så hypotesen kan testes i stedet for at udledes af et leverandørdiagram.
Læs Microsoft-resultater uden at omdøbe dem
Microsofts autentificeringsoversigt skelner SPF , DKIM og DMARC fra sammensat godkendelse, optaget som compauth. Sidstnævnte indeholder yderligere vurdering. Opbevar hvert felt og den endelige håndteringshandling i separate kolonner. Et sammensat pas bør ikke omskrives i hændelsesjournalen som et almindeligt DMARC -pas.
Den nuværende betroet ARC forseglervejledning beskriver brugen af legitime mellemmænds tidligere vurderinger og giver et diagnostisk eksempel med compauth=pass og reason=130 mens dmarc=fail forbliver synlig. Den advarer også om, at anden filtrering stadig kan virke. Det er en udbyderspecifik fortolkning til at verificere i betroede modtagergenererede resultater, ikke et løfte om, at de samme felter vises på hver konto.
Stol ikke på en vilkårlig Authentication-Results linje, simpelthen fordi den er nær toppen af en indsat overskrift. Bestem, hvilket modtagesystem der genererede resultatet, og hvordan den betroede grænse identificeres. Hvis kun et skærmbillede eller strippet uddrag er tilgængeligt, skal du registrere den manglende herkomst og anmode om en korrekt redigeret fuld prøve gennem den godkendte proces.
Hold SRS- og ARC beslutninger adskilt
Microsofts SRS dokumentation vedrører relevante videresendelses- og relæscenarier og adskiller eksplicit den omskrevne MAIL FRA fra den synlige Fra. Det dokumenterer også undtagelser. Antag ikke, at hver meddelelse, der kommer ind i Microsoft 365 modtager den samme omskrivning, eller behandl en udadgående SRS adfærd som rettelsen for en ikke-relateret indgående gateway.
En omskrevet konvolut kan understøtte SPF for omskrivningsdomænet uden justering til den oprindelige forfatter. Det relevante domæneforhold er stadig påkrævet af RFC 9989 afsnit 4.4. ARC formidler i stedet tidligere autentificeringsvurderinger, som en modtager kan overveje. RFC 8617 afsnit 7.2.1 beskriver brug af lokal politik, ikke automatisk erstatning af det almindelige godkendelsesresultat.
Ethvert forslag om at stole på en forsegler er en sikkerhedsbeslutning. Identificer den nøjagtige lovlige tjeneste, dens operationelle behov og en ansvarlig godkender; bevare de tidligere konfigurations- og fjernelseskriterier. Tilføj ikke bred tillid, blot fordi en meddelelse bærer et syntaktisk gyldigt ARC sæt. Den nuværende ARC omklassificering udkast er i gang, mens RFC 8617 forbliver Eksperimentel på denne revisionsdato.
Fiktiv gateway-ændring med en afgrænset accepttest
I dette fiktive eksempel modtager Eksempeltjenester mail gennem en indholdsgateway før en Microsoft 365 postkasse. En opfundet direkte prøve verificerer en aligned DKIM signatur; en tilsvarende gateway-rutet prøve har en omskrevet vedhæftet fil og verificerer ikke længere denne signatur. Scenariet antager disse observationer udelukkende for at forklare undersøgelsen. Ingen lejer eller besked blev tilgået.
Ejeren vil først afgøre, om transformationen er nødvendig, og om en mindre forstyrrende konfiguration understøttes. Hvis en ARC-baseret behandling blev foreslået, ville gennemgangen kræve den faktiske forsegleridentitet, autentificeret kædebevis og en specifik lejergodkendelse. Acceptkriterier vil registrere almindelig autentificering, sammensatte resultater, sikkerhedsfiltrering og disposition separat. Et vellykket indbakkeoptræden alene ville ikke demonstrere den tilsigtede mekanisme.
Gendannelseskriterier bør omfatte uventet bred tillid, ny fejlklassificering eller manglende bevarelse af det påkrævede bevis. Rollback-planen skal identificere den nøjagtige godkendte konfiguration, ikke blot instruere nogen om at deaktivere sikkerhedsbehandling, indtil meddelelser ankommer.
Luk kun den rute, der blev bekræftet
Efter en autoriseret ændring skal du sammenligne nye direkte og indirekte prøver med basislinjen på tværs af repræsentative meddelelser. Bevar indstillingsversionen, tidsstempler og eventuel resterende udbyder- eller lejerusikkerhed. En arbejdssti gennem én gateway validerer ikke alle videresendelsesregler i organisationen.
Den originale bevisport er uændret og synlig: direkte og indirekte leveringsprøver med rute, konvolut, signaturer og pålidelige resultater sammenlignet. Ingen sådanne operationelle beviser, lejergodkendelse, livetest eller gendannelsesudførelse er inkluderet her. Leverancen er en procedure, der kan gennemses med kildebaserede skel, ikke en fuldført Microsoft 365 remediering.