compauth i Microsoft 365: Composite Authentication og alle Reason Codes

I Authentication-Results-headeren til en e-post mottatt i Microsoft 365 står det, ved siden av standardresultatene for SPF, DKIM og DMARC, et Microsoft-eget felt:

Authentication-Results: spf=pass (sender IP is 192.0.2.10)
  smtp.mailfrom=example.com; dkim=pass (signature was verified)
  header.d=example.com; dmarc=pass action=none header.from=example.com;
  compauth=pass reason=100

compauth står for Composite Authentication: Microsoft 365 kombinerer resultatene fra SPF, DKIM og DMARC med ytterligere signaler i meldingen til en samlet vurdering av om den synlige From-adressen er troverdig. Vurderingen baseres på From-domenet, altså adressen mottakerne ser i e-postklienten. Dermed lukker Microsoft gapet som oppstår når et avsenderdomene ikke har publisert noen eller ufullstendige autentiseringsposter: Selv uten en DMARC-policy kontrolleres det implisitt om e-posten passer til det påståtte domenet.

De fire resultatene

• compauth=pass: Meldingen besto den eksplisitte (DMARC) eller implisitte autentiseringen.
• compauth=softpass: Den implisitte kontrollen ble bestått med lavere sikkerhet.
• compauth=fail: Meldingen strøk på den eksplisitte eller implisitte kontrollen.
• compauth=none: Ingen Composite-kontroll ble utført, eller den ble hoppet over.

En compauth=fail fører ikke automatisk til karantene eller søppelpostmappen. Det er et inngangssignal for filteravgjørelsen; avgjørende for den faktiske behandlingen er CAT og andre felt i X-Forefront-Antispam-Report. Omvendt gjelder følgende: Vil du vite hvorfor compauth tok denne avgjørelsen, trenger du reason-koden rett etter resultatet.

Oversikt over Reason Codes

Den tresifrede koden angir regelen som førte til resultatet. Det første sifferet grupperer: 0xx og 6xx er feil, 1xx og 7xx er beståtte kontroller, 2xx er softpass, mens 3xx, 4xx og 9xx betyr at ingen kontroll ble utført eller at den ble hoppet over.

De vanligste tilfellene i praksis

compauth=fail reason=001 er standardtilfellet for domener uten eller med svak autentisering. Løsningen ligger hos avsenderen: Publiser SPF med -all, DKIM-signering og en DMARC-policy. Så lenge postene mangler, avhenger leveringen av omdømmesignaler.

compauth=fail reason=601 oppstår når e-poster med eget domene som avsender kommer utenfra, klassisk ved Direct Send: Multifunksjonsenheter, applikasjoner eller tjenesteleverandører leverer direkte til MX uten en autentisert connector. Løsningen er en korrekt konfigurert Inbound Connector eller å legge kilden til i egen SPF.

compauth=fail reason=000 eller 010 betyr: DMARC ble håndhevet på vanlig måte. Hvis action=oreject står ved siden av, har Microsoft 365 oversatt avsenderens reject-policy til levering i karantene. Her er det ingenting å reparere, med mindre avsenderen er legitim og autentiseringen er defekt.

reason=108 og reason=130 gjelder videresendings- og gateway-scenarioer: Et mellomledd har endret e-posten, eller en klarert ARC-sealer har bevart de opprinnelige kontrollresultatene. Den som drifter en gateway foran Microsoft 365, bør konfigurere ARC-sealingen som klarert i antispam-konfigurasjonen, ellers vil legitime e-poster fortsatt henge på DMARC.

Lese compauth i headeren

I praksis står compauth sjelden alene: Først samspillet med de enkelte SPF-, DKIM- og DMARC-resultatene, alignment av de involverte domenene og Received-kjeden gir det komplette bildet. Mail Header Analyzer på dette nettstedet dekoder compauth med Reason Code direkte i nettleseren og viser de tilhørende domenene (From, Envelope-From, d=) ved siden av hverandre for alignment-vurderingen; den innsatte headeren forlater ikke nettleseren.