Les sammensatt autentisering som et Microsoft-resultat
Microsofts compauth-felt er ikke en annen stavemåte for DMARC. Det er en sammensatt vurdering som bruker autentisering og andre meldingssignaler, og tolkningen tilhører Microsofts dokumenterte behandling. En melding kan derfor inneholde forskjellige DMARC og sammensatte resultater uten at overskriften er iboende motstridende. Den riktige oppgaven er å lese hvert felt, dets identitetskontekst og den tilhørende årsakskoden før du bestemmer hva resultatet fastslår.
Denne artikkelen bruker Microsofts primærdokumentasjon som ble oppbevart 8. november 2026. Antispam-overskriftssiden identifiserer en oppdatering fra 27. juli 2026. Ingen original melding eller leietakerspor ble levert, og eksemplet nedenfor er eksplisitt oppdiktet i stedet for en redigert overskrift. Katalogen krever et ekte originalmeldingseksempel før operasjonelle konklusjoner kan frigis.
Hold identitetene synlige
Microsoft definerer header.from som det synlige From-domenet, smtp.mailfrom som konvolutten POST FRA domene, og header.d som DKIM signering av domene når det er tilstede. Disse feltene kan variere. Bevar forholdet deres når du leser resultater: en SPF pass for ett domene etableres ikke automatisk justering med den synlige avsenderen, og et DKIM pass må knyttes til signaturen og domenet det beskriver. Overskriftsfelt for Microsoft-autentisering
DMARC protokollavgjørelse gjelder justering med det synlige From-domenet under reglene. Microsoft sammensatt autentisering bruker det From-domenet som grunnlag mens den kombinerer SPF , DKIM , DMARC og annen informasjon. Ikke erstatt det separate DMARC resultatet med compauth i en samsvarserklæring eller en DNS feilsøkingskonklusjon. De svarer på relaterte, men ikke-identiske spørsmål. RFC 9989 Microsoft sammensatte felt
Tolk resultatet og begrunn sammen
Microsoft dokumenterer compauth-verdier pass, fail, softpass og none, med en tresifret grunn. Behold hele paret. En årsakskode er ikke en SMTP svarkode, selv når sifrene ligner en annen diagnose. Ikke dekod reason=130 ved å bruke en generisk SMTP tabell eller utlede en betingelse for hele leietakeren fra en meldings verdi. Bruk gjeldende Microsoft-tabell for den observerte konteksten. Microsoft sammensatt autentisering
Overskriftsreferansen beskriver årsak 000 som eksplisitt autentiseringsfeil med en DMARC feil og karantene eller avvisningspolicy, mens 001 gjelder implisitt autentiseringssvikt i dokumenterte svake eller fraværende policy-omstendigheter. Den beskriver 109 som et tilfelle hvor no DMARC rekord eksisterer, men meldingen ellers ville passert. Dette er leverandørdefinisjoner med omfang, ikke instruksjoner for å lage en overskrift eller bevis på at en slik melding ble observert her. Microsofts årsakskoder
Forstå bestguesspass uten å kreve en publisert policy
Microsofts dmarc=bestguesspass -etikett betyr at ingen DMARC TXT post eksisterer, men meldingen ville passere hvis domenet hadde en. Det må ikke rapporteres som bevis på at domenet publiserte en gyldig DMARC policy eller at den faktiske standard DMARC evalueringen returnerte bestått. Bevar leverandøretiketten ordrett og forklar den begrensede betydningen. Microsoft DMARC feltverdier
En avsender som vurderer et slikt resultat, bør fortsatt bekrefte den faktiske offentlige policyen og den tiltenkte autentiseringskonfigurasjonen. Ikke anta at sammensatt suksess fjerner behovet for eksplisitt domenepolicy eller garanterer at andre mottakere vil gjøre samme vurdering. En mottakerspesifikk heuristikk eller slutning er ikke en bærbar erstatning for domenets publiserte kontroller.
ARC og implisitte signaler omskriver ikke de underliggende fakta
Microsoft dokumenterer grunn 130 som en klarert ARC sealers resultat overstyrer en DMARC feil. Det kan forklare et sammensatt resultat i en videresendt eller formidlet bane, men det betyr ikke at den underliggende DMARC feilen skal slettes fra bevisposten. Hold det opprinnelige resultatet, ARC konteksten, årsaken og den endelige håndteringen forskjellig. Ikke påstå at noen vilkårlig ARC header er tilstrekkelig; den dokumenterte saken gjelder en betrodd forsegler. Microsoft grunn 130
På samme måte beskriver Microsoft andre implisitte signaler og bemerker at en sammensatt feil ikke direkte resulterer i blokkering. Den samlede vurderingen kan tillate en melding til tross for denne feilen, mens andre beskyttelsesteknologier kan identifisere risiko i autentisert post. Følgelig er ikke compauth=pass en garanti for innboksplassering eller innholdssikkerhet, og compauth=fail er ikke i seg selv bevis på avvisning. Microsofts håndteringsforklaring
Etabler grensen for overskriftstillit
Få en autorisert original melding fra den aktuelle mottakeren og identifiser hvilket pålitelig system som ga resultatene. RFC 8601 forklarer hvorfor Authentication-Results påstander trenger en tillitsgrense. Flere overskrifter kan vises langs en meldingsbane, og en upålitelig avsender kan sette inn tekst som ser autoritativ ut. Ikke velg den forekomsten som best samsvarer med den ønskede konklusjonen uten å spore herkomst. RFC 8601
Ta vare på en urørt original for intern verifisering og en separat redigert forklarende kopi. Endring av adresser eller signert innhold kan forhindre uavhengig kryptografisk revalidering, så merk kopien deretter. En merknad kan bevare identitetsrelasjoner for diskusjon, men den er ikke en nylig verifiserbar originalmelding. Hvis mottakeren trenger sterkere bevis, bruk en godkjent sikker overføringsprosess i stedet for å utvide avsløringen i det stille.
Originalt arbeidsark med sammensatt resultat
Følgende foreslåtte arbeidsark gjør felttolkning reproduserbar. Den er ikke fylt med en reell melding og bør ikke behandles som en fullført autentiseringsanalyse.
- Bevisopprinnelse: referanse for mottatt melding, mottaker, tidsstempel og klarert verifikator.
- Synlig identitet: header.from og dets forhold til bedriftens avsender.
- SPF : eksakt resultat, smtp.mailfrom og observert kildekontekst.
- DKIM : resultat for hver relevant signatur og tilhørende header.d.
- DMARC : eksakt leverandørfeltverdi og separat bekreftet policykontekst.
- Sammensatt: compauth-verdi, tresifret årsak og sitert Microsoft-definisjon.
- Formidling: videresending, klarert ARC eller annet rutebevis som faktisk er tilgjengelig.
- Utfall: observert håndtering, ustøttede konklusjoner og neste bevis er nødvendig.
Ikke kombiner resultater fra forskjellige meldinger for å lage en syntetisk all-pass-post. En vellykket direkteleveringsprøve og en videresendt feilprøve kan avsløre en ruteforskjell, men hver trenger sin egen identitet og tidsstempel. Bevar ukjente når et felt eller en original melding er utilgjengelig.
Fiktivt eksempel: utledet suksess forveksles med policyimplementering
Fictional Seabright Desk ser en hypotetisk rapport som inneholder dmarc=bestguesspass og compauth=pass reason=109. Den foreslåtte gjennomgangen forklarer at den dokumenterte betydningen ikke etablerer en publisert DMARC post. E-posteieren vil fortsatt inspisere den faktiske policyen og bekrefte den tiltenkte distribusjonen i stedet for å merke domenet komplett fra det sammensatte resultatet alene.
Ingen Seabright Desk-header, DNS svar eller leietakerresultat finnes i dette arbeidet. Verdiene brukes kun for å illustrere Microsofts dokumenterte tolkning, ikke som fabrikkert bekreftelsesbevis. En reell analyse krever den originale meldingen og pålitelig kildekontekst.
Katalogen krever gjeldende Microsoft-feltdefinisjoner og et redigert eksempel på originalmelding. Definisjonene er kildebaserte, men originalbeviset mangler. Originalbevis, menneskelig SMB, kildeanvendbarhet, produksjonsruter, visuell tilgjengelighet og eierfrigivelse forblir åpne. Dette utkastet er en tolkningsveiledning, ikke en verifisert leietakervurdering.