compauth=fail: Uitleg over Microsoft Composite Authentication

U hebt SPF, DKIM en DMARC ingesteld, maar uw e-mails belanden nog steeds in de map met ongewenste e-mail van Outlook. De boosdoener is vaak compauth=fail, een Microsoft-specifieke authenticatielaag die verder gaat dan de standaard wereldwijde protocollen. Om de afleverbaarheid van uw zakelijke e-mails te waarborgen, is het van cruciaal belang dat u begrijpt wat dit diagnostische signaal betekent, waarom het verschilt van DMARC en waarom het na de updates van mei 2025 belangrijker is dan ooit.

Wat is samengestelde authenticatie (compauth)?

Composite Authentication (compauth) is het eigen authenticatiescoresysteem van Microsoft dat wordt gebruikt door Exchange Online Protection (EOP) in Microsoft 365 en Outlook.

In tegenstelling tot de standaardprotocollen SPF, DKIM en DMARC, die fungeren als expliciete, op standaarden gebaseerde verificatiecontroles, werkt compauth als een samengestelde intelligentiescore. Het combineert expliciete authenticatieresultaten met geavanceerde impliciete signalen, waaronder de reputatie van de afzender, historische interactiepatronen, Microsofts interne informatie over spoofing en gedragsanalyse.

Het uiteindelijke evaluatieresultaat wordt opgenomen in de header ‘Authentication-Results’ van elk inkomend bericht dat door Microsoft 365 wordt verwerkt. Afhankelijk van hoe de e-mail presteert bij deze hybride controle, zal de header een van de vier mogelijke waarden weergeven:

• compauth=pass: Het bericht heeft zowel de expliciete authenticatiecontroles als de impliciete veiligheidsbeoordelingen doorstaan.
• compauth=fail: Het bericht voldoet niet aan de criteria voor samengestelde authenticatie van Microsoft en wordt als zeer verdacht gemarkeerd.
• compauth=softpass: Het bericht is doorgestuurd via impliciete signalen of op basis van reputatie, ondanks het ontbreken van robuuste expliciete authenticatie.
• compauth=none: Er is geen samengestelde authenticatiebeoordeling uitgevoerd op het bericht.

Voor meer informatie over het configureren van e-mailverificatie voor Microsoft 365-e-mails kun je onze handleiding over DMARC voor Office 365 raadplegen.

compauth versus DMARC: wat is het verschil?

Een veelvoorkomende bron van verwarring voor systeembeheerders is wanneer een e-mail de standaard DMARC-controle doorstaat, maar tegelijkertijd de status `compauth=fail` activeert.

Vanwege deze verschillen kan een bericht gemakkelijk de expliciete DMARC-validatie doorstaan, maar toch de status `compauth=fail` opleveren als de machine learning-modellen van Microsoft het als afwijkend markeren (bijvoorbeeld een nieuw geregistreerd domein, een plotselinge piek in het volume of een domein dat werkt met een passief `p=none`-monitoringbeleid).

Omgekeerd kan een bericht weliswaar niet voldoen aan expliciete SPF- of DKIM-controles, maar toch een compauth=pass krijgen als de spoof-detectie van Microsoft of een lokale geschiedenis van veilige afzenders de authenticiteit ervan bevestigt (zoals reason=130 via een ARC-override of reason=201 voor intern vertrouwde M365-afzenders).

Wat zijn de compauth-redencodes?

Bij het analyseren van je e-mailheaders wordt de tekenreeks compauth=fail of compauth=pass gevolgd door een specifieke driecijferige foutcode. Deze code geeft precies aan waarom de filterengine van Microsoft tot deze beslissing is gekomen.

Opmerking: Alle foutcodes zijn rechtstreeks afkomstig uit de officiële technische documentatie van Microsoft. Om snel een diagnose te stellen van uw uitgaande berichten, kopieert u de onbewerkte e-mailheaders en plakt u deze in de webversie van de Microsoft Message Header Analyzer.

Waarom compauth=fail na mei 2025 nog belangrijker wordt

De operationele gevolgen van een ‘compauth=fail’-resultaat zijn aanzienlijk ernstiger geworden na de invoering van de handhavingsmaatregelen door Microsoft op 5 mei 2025. De ‘Sender Requirements’ van Microsoft hebben strenge, geautomatiseerde vereisten voor e-mailverificatie ingevoerd die gericht zijn op verzenders met een hoog verzendvolume (die 5.000 of meer berichten per dag versturen) naar consumentenplatforms zoals Outlook.com, Hotmail en Live.com.

Onder deze aangepaste handhavingsmechanismen leidt een classificatie van `compauth=fail` direct tot het agressief plaatsen in de spamfolder of het direct afwijzen van berichten op gateway-niveau. De filtering van Microsoft beschouwt een DMARC-beleid met `p=none` nu als een primaire aanleiding voor `reason=001`, zelfs wanneer SPF en DKIM afzonderlijk worden goedgekeurd. Afzenders van wie de e-mailbezorging voorheen in een passieve monitoringmodus werd getolereerd, krijgen nu te maken met plotselinge, verstorende dalingen in de bezorgbaarheid in alle door Microsoft beheerde omgevingen.

Wat is de oorzaak van compauth=fail?

Om leveringsproblemen op te lossen, moet u de specifieke foutcode in uw Authentication-Results-header koppelen aan de onderliggende oorzaak:

• reason=000: Het verzendende domein hanteert een strikt DMARC-beleid met de instelling p=reject of p=quarantine, en het bericht is niet geslaagd voor zowel de SPF- als de DKIM-verificatie. Raadpleeg onze handleiding over de oorzaken van DMARC-fouten voor gedetailleerde stappen om authenticatiefouten op te lossen.
• reason=001 (Standaard): Dit is de meest voorkomende foutcode. Deze duidt op een domein dat een passief p=none-bewakingsbeleid hanteert, het volledig ontbreken van een DMARC-record, een niet-geoptimaliseerde SPF soft fail (~all) of niet-overeenkomende identificatiedomeinen.
• reason=001 & reason=601 (externe afzenders): Dit gebeurt wanneer een externe e-mailserviceprovider (ESP) of CRM-systeem berichten namens uw merk verstuurt, maar het bericht ondertekent met domeinen van zijn eigen infrastructuur. Omdat het zichtbare ‘From’-header-domein niet overeenkomt met de trackingdomeinen die door de provider worden gebruikt, wordt er een kritieke afstemmingsfout gegenereerd.
• reason=010: De spoof-detectiesysteem van Microsoft signaleert het gedrag van de afzender als frauduleus, wat wijst op phishing of het misbruiken van een domeinnaam.

Hoe los je 'compauth=fail' op?

Om een fout bij samengestelde authenticatie te verhelpen, zijn gerichte configuratiewijzigingen nodig, afhankelijk van de specifieke situatie die de fout veroorzaakt.

Oplossing 1: Werk je DMARC-beleid bij en ga verder dan p=none

Aangezien een passief monitoringbeleid (p=none) wordt beschouwd als een impliciete authenticatiefout (reason=001), moet u uw domein omzetten naar een beleid waarbij regels worden afgedwongen. Zorg ervoor dat u uw beleid op een veilige manier aanpast naar p=quarantine of p=reject. Door af te stappen van een beleid dat uitsluitend op monitoring is gericht, wordt de kwetsbaarheid weggenomen die de regels voor impliciete fouten activeert. Als u zich zorgen maakt over het blokkeren van legitieme legacy-mailstromen tijdens deze overgang, raadpleeg dan onze strategieën voor het beheren van DMARC-beleidsoverschrijvingen.

Oplossing 2: Zorg voor een nauwkeurige DKIM-afstemming

Stel uw primaire mailservers zo in dat alle uitgaande berichten worden ondertekend met een unieke cryptografische DKIM-sleutel. Zorg ervoor dat de parameter voor het ondertekenende domein (d=) in de DKIM-header exact overeenkomt met het hoofddomein dat wordt weergegeven in de zichtbare From:-header. Deze strakke cryptografische afstemming vormt het sterkst mogelijke positieve signaal voor de compauth-engine van Microsoft.

Oplossing 3: Aangepaste retourpaden configureren voor externe e-maildienstverleners

Vertrouw bij het gebruik van externe platforms (zoals marketingtools of helpdesks) niet op hun standaardinstellingen. Stel een aangepast MAIL FROM- of Return-Path-domein in dat gebruikmaakt van de eigen domeinnaam van uw bedrijf, of zorg ervoor dat de provider volledig bevoegd is om berichten cryptografisch te ondertekenen met behulp van de DKIM-sleutels van uw domein. Dit lost problemen met niet-overeenkomende identificatiegegevens op en voorkomt fouten met de statuscode 601.

Oplossing 4 & De toekomst van doorsturen (van ARC naar DKIM2)

In het verleden werkten standaard DKIM-handtekeningen vaak niet als de e-mailstromen van uw organisatie regelmatig via mailinglijsten of geautomatiseerde doorstuurketens liepen. Om dit op te lossen, kunt u Authenticated Received Chain (ARC) . Wanneer een tussenliggende server een inkomend bericht valideert en het verzegelt met een vertrouwde cryptografische stempel, leest Microsoft 365 de chain of custody en negeert lokale fouten om een succesvolle compauth=pass reason=130 weer te geven.

Het landschap op het gebied van e-mailverificatie is echter volop in beweging. Op 22 april 2026 werd in een voorstel van de IETF DMARC-werkgroep (draft-ietf-dmarc-arc-to-historic-00) voorgesteld om ARC te herclassificeren als een historische standaard. Dit is een internet-draft van de werkgroep, geen definitieve RFC; ARC (RFC 8617) blijft een actief protocol.

De lessen van ARC worden op organische wijze geïntegreerd in de opkomende DKIM2-specificatie, die gebroken handtekeningen tijdens het doorsturen en DKIM-replay-aanvallen aanpakt. Volgens het laatste IETF-ontwerp van 17 mei 2026 (draft-ietf-dkim-dkim2-spec-02) registreert elk systeem dat een bericht verwerkt de wijzigingen en voegt het zijn eigen handtekening toe aan een onbreekbare bewakingsketen.

Wat dit op dit moment voor u betekent:

• Laat ARC voorlopig nog actief: Microsoft gebruikt nog steeds reason=130 (ARC-override) om doorgestuurde e-mail door te sturen, dus verwijder je Microsoft Trusted ARC Seal-configuratie nog niet.
• Bereid u voor op DKIM2: bij grote e-mailproviders kunnen eind 2026 de eerste implementaties van start gaan, hoewel de specificatie zich nog in een vroeg conceptstadium bevindt. Aangezien DKIM2-sleutels gebruikmaken van uw bestaande DNS-recordstructuur, is het voor u de beste bescherming tegen toekomstige authenticatiefouten om ervoor te zorgen dat uw huidige DKIM-infrastructuur vlekkeloos functioneert. Verwijder overbodige selectors en zorg voor een correcte sleutelrotatie.

Oplossing 5: Maak gebruik van M365 Spoof Intelligence om toegang te verlenen

Voor interne toepassingen, verouderde apparaten op locatie of zeer gespecialiseerde legitieme afzenderprofielen die automatische valse positieven op basis van machine learning veroorzaken (reden=010), kunnen Microsoft 365-beheerders het algoritme handmatig overschrijven. Ga naar het Microsoft 365 Defender-portaal, open de Spoof Intelligence-inzichtconsole en voeg een expliciete toelatingsregel toe aan de toelatings-/blokkeerlijst van de tenant voor dat specifieke afzenderprofiel.

Hoe compauth in e-mailheaders te lezen

Om deze waarden te achterhalen en te analyseren, moeten de onbewerkte internet-routeringsheaders uit het betreffende bericht worden gehaald.

1. De headers extraheren: Open in de desktopversie van Outlook het betreffende e-mailbericht in een apart venster en ga naar Bestand > Eigenschappen > Internetheaders. Als u als beheerder een algemener bezorgingsprobleem aan het oplossen bent, kunt u gebruikers ook vragen of via beheerderslogboeken de onbewerkte headertekst kopiëren en deze rechtstreeks in de Microsoft Message Header Analyzer (MHA) op mha.azurewebsites.net plakken voor een overzichtelijke, geparseerde weergave.
2. Zoek de betreffende regel: doorzoek de geparseerde tekst naar het specifieke blok met de naam Authentication-Results. Let goed op de zin compauth=, die direct wordt gevolgd door de uitkomst (pass, fail of softpass) en de bijbehorende reason=code.
3. Vergelijk de gegevens: bekijk het samengestelde authenticatieresultaat niet op zichzelf. Controleer de aangrenzende parameters binnen precies diezelfde kopregel, en let daarbij met name op de afzonderlijke spf=-, dkim=- en dmarc=-resultaten. Door deze expliciete waarden naast elkaar te vergelijken met de compauth-redencode, wordt precies duidelijk welke controle is mislukt of welk impliciet signaal ervoor heeft gezorgd dat het bericht naar de spamfolder is doorgestuurd.

Hoe kan ik 'compauth=fail'-fouten voorgoed voorkomen?

Het handmatig analyseren van headers en het afstemmen van de opmaak bij een tiental externe leveranciers kan een te zware last vormen voor interne IT-teams. PowerDMARC vereenvoudigt dit proces door uitgebreid inzicht en geautomatiseerde beheertools te bieden, waardoor u ‘compauth=fail’-fouten kunt oplossen en uw e-mailverificatiegegevens in orde kunt houden.

Start vandaag nog een gratis DMARC-proefperiode om duidelijk inzicht te krijgen in uw Microsoft 365-bezorgingsstromen, afstemmingsfouten te voorkomen en uw domein veilig over te zetten naar een strikt DMARC-beleid.

Veelgestelde Vragen

Wat betekent „compauth=fail“ in e-mailheaders?

Dit betekent dat het Exchange Online Protection-systeem van Microsoft het inkomende bericht heeft beoordeeld en geweigerd op basis van een combinatie van expliciete authenticatieprotocollen (SPF, DKIM, DMARC) en impliciete signalen uit dreigingsinformatie (reputatie van de afzender, informatie over spoofing, geschiedenis).

Wat is het verschil tussen compauth en DMARC?

DMARC is een open, wereldwijd internetprotocol dat door alle e-mailproviders wordt gebruikt om de overeenstemming van identificatiegegevens te controleren. compauth is een eigen, exclusief door Microsoft ontwikkelde evaluatielaag die standaard DMARC-resultaten verwerkt en daarbij rekening houdt met aanvullende realtime reputatie- en gedragsstatistieken.

Waarom mislukt compauth, zelfs als SPF en DKIM geslaagd zijn?

Dit komt vaak voor als uw domein is geconfigureerd met een passief DMARC-beleid (p=none), wat door het bijgewerkte systeem van Microsoft wordt beschouwd als een risico voor de afleverbaarheid. De verzending kan ook mislukken als de interne spoof-detectie van Microsoft het transactiegedrag of de verzendgeschiedenis van de afzender als afwijkend markeert.

Wat betekent "compauth fail reason=001"?

Foutcode 001 betekent dat het bericht niet voldoet aan de impliciete authenticatiecriteria van Microsoft. Dit wordt meestal veroorzaakt door ontbrekende DMARC- of SPF-records, een verkeerde afstemming van identificatiegegevens, of het hanteren van een passief DMARC-beleid met p=none in plaats van over te gaan tot handhaving.

Hoe los ik de foutmelding 'compauth=fail' in Microsoft 365 op?

Zorg ervoor dat uw SPF- en DKIM-domeinen volledig overeenkomen met uw zichtbare ‘From’-header, pas uw DMARC-beleid aan van p=none naar een handhavingsstatus zoals p=quarantine of p=reject, en configureer vertrouwde ARC-zegels als uw e-mailverkeer geautomatiseerde doorsturing omvat.

Zorgt de instelling `compauth=fail` ervoor dat e-mails in Outlook in de map ‘Ongewenste e-mail’ terechtkomen?

Ja. Bij strikte beveiligingsmaatregelen zorgt een status ‘compauth=fail’ ervoor dat de EOP-filterengine inkomende berichten direct naar de map met ongewenste e-mail doorstuurt of ze al bij de perimeter volledig weigert.

• Over
• Laatste berichten

Yunes Tarada

Expert domein- en e-mailbeveiliging bij PowerDMARC

Yunes is teamleider Operations bij PowerDMARC en heeft expertise in e-mailauthenticatie en -beveiliging. Hij is een door Microsoft gecertificeerde Azure Administrator Associate en beschikt over certificeringen zoals CompTIA A+ en vele andere.

Laatste berichten van Yunes Tarada (Bekijk alle berichten)

• Hoe een DKIM-record splitsen - 5 juni 2026
• compauth=fail: Uitleg over Microsoft Composite Authentication - 1 juni 2026
• Is Windows Defender voldoende voor de beveiliging van kleine bedrijven? - 14 mei 2026