compauth=fail : Explication de l'authentification composite Microsoft
par
Dernière mise à jour : Temps de lecture : 7 min
Points clés à retenir
- Même si vos e-mails respectent parfaitement les normes internationales telles que SPF DKIM, Microsoft peut tout de même les signaler comme « non conformes » à l'aide de ses propres filtres de réputation internes.
- Depuis que Microsoft a pris des mesures contre les expéditeurs à fort volume, le fait de conserver une politique DMARC passive (p=none) entraîne désormais systématiquement des échecs d'authentification implicites (raison=001).
- Si vos e-mails ne parviennent pas à leur destinataire parce qu'ils ont été transférés, l'ancienne solution consistait à mettre en place un sceau ARC ( Authenticated Received Chain ). Cependant, un projet du groupe de travail de l'IETF (Internet Engineering Task Force) proposant de reclasser l'ARC en norme historique, vous devez veiller à ce que votre infrastructure DKIM actuelle fonctionne parfaitement afin de vous préparer au déploiement prochain de DKIM2.
- La plupart des problèmes sont dus à un décalage entre les domaines ou à des politiques trop laxistes. En passant à une version supérieure de p=none et en configurant des domaines « mail-from » personnalisés pour les outils tiers, vous résoudrez la grande majorité de vos problèmes liés à l'authentification des composants.
Vous avez configuré SPF, DKIM et DMARC, mais vos e-mails continuent d'atterrir dans le dossier Courrier indésirable d'Outlook. Le coupable est souvent « compauth=fail », une couche d'authentification propre à Microsoft qui va au-delà des protocoles mondiaux standard. Il est essentiel de comprendre ce que signifie ce signal de diagnostic, en quoi il diffère de DMARC et pourquoi il revêt plus d'importance que jamais après les mises à jour de mai 2025, afin de garantir la délivrabilité des e-mails professionnels.
Qu'est-ce que l'authentification composite (compauth) ?
L'authentification composite (compauth) est le système de notation d'authentification propriétaire de Microsoft utilisé par Exchange Online Protection (EOP) dans Microsoft 365 et Outlook.
Contrairement SPF, DKIM et DMARC classiques, qui constituent des contrôles de vérification explicites fondés sur des normes, compauth fonctionne comme un score d'intelligence composite. Il combine les résultats d'authentification explicites avec des signaux implicites avancés, notamment la réputation de l'expéditeur, les modèles d'interaction historiques, les données internes de Microsoft sur l'usurpation d'identité et l'analyse comportementale.
Le résultat final de l'évaluation est intégré dans l'en-tête « Authentication-Results » de chaque message entrant traité par Microsoft 365. En fonction des résultats obtenus par l'e-mail lors de ce contrôle hybride, l'en-tête affichera l'une des quatre valeurs possibles :
- compauth=pass : Le message a satisfait à la fois aux contrôles d'authentification explicites et aux évaluations de sécurité implicites.
- compauth=fail : Le message ne répond pas aux critères d'authentification composite de Microsoft et est signalé comme hautement suspect.
- compauth=softpass : Le message a été transmis via des signaux implicites ou de réputation, bien qu'il n'y ait pas eu d'authentification explicite fiable.
- compauth=none : aucune évaluation de l'authentification composite n'a été effectuée sur le message.
Pour en savoir plus sur la configuration de l'authentification des e-mails Microsoft 365, consultez notre guide sur DMARC pour Office 365.
compauth ou DMARC : quelle est la différence ?
Une source fréquente de confusion pour les administrateurs système est de voir un e-mail passer la vérification DMARC standard tout en déclenchant simultanément un statut « compauth=fail ».
| Caractéristique / Aspect | DMARC | Authentification composite Microsoft (compauth) |
|---|---|---|
| Champ d'application et mise en œuvre | Une norme Internet mondiale et ouverte, appliquée de manière uniforme par tous les principaux fournisseurs de messagerie. | Une couche de sécurité propriétaire, exclusive à Microsoft, fonctionnant uniquement au sein de Microsoft 365 et d'Outlook. |
| Indicateur clé d'évaluation | Vérifie que les contrôles SPF DKIM sont validés et correspondent bien au domaine indiqué dans l'en-tête « From » visible. | Évalue la conformité aux normes SPF, DKIM et DMARC, ainsi que les signaux de réputation et d'intelligence propres à Microsoft. |
| Traitement des signaux implicites | Ne tient pas compte du contexte externe, tel que l'historique des envois, les listes d'autorisation spécifiques aux clients ou l'IA comportementale. | Accorde une grande importance aux signaux implicites, notamment aux informations de spoofing et à l'historique des échanges entre l'expéditeur et le destinataire. |
En raison de ces différences, un message peut facilement passer la validation DMARC explicite tout en renvoyant un statut « compauth=fail » si les modèles d'apprentissage automatique de Microsoft le signalent comme anormal (par exemple, un domaine nouvellement enregistré, un pic soudain de volume ou un domaine fonctionnant avec une politique de surveillance passive « p=none »).
À l'inverse, un message peut échouer aux vérifications SPF DKIM explicites, mais obtenir un résultat « compauth=pass » si le système de détection d'usurpation de Microsoft ou un historique d'expéditeurs de confiance localisé confirme son authenticité (par exemple, « reason=130 » via une dérogation ARC ou « reason=201 » pour les expéditeurs M365 considérés comme fiables en interne).
Que sont les codes de raison compauth ?
Lors de l'analyse des en-têtes de vos e-mails, la chaîne « compauth=fail » ou « compauth=pass » est suivie d'un code de motif spécifique à trois chiffres. Ce code indique précisément pourquoi le moteur de filtrage de Microsoft est parvenu à cette conclusion.
| Code | Résultat | Signification |
|---|---|---|
| 000 | échouer | Échec de la validation DMARC avec une politique stricte de type « p=reject » ou « quarantine » appliquée. |
| 001 | échouer | Échec de l'authentification implicite : absence d'enregistrements d'authentification, politique DMARC passive (p=none), échec SPF (~all) ou décalage important entre les domaines. |
| 002 | softpass | Authentification souple : le message est transmis principalement par le biais de signaux implicites ou liés à la réputation, plutôt que par une authentification explicite. |
| 010 | échouer | Le message n'a pas passé les contrôles anti-usurpation mis en œuvre par le système automatisé de détection d'usurpation de Microsoft. |
| 100 | passer | Authentification explicite réussie (toutes les vérifications SPF, DKIM et DMARC sous-jacentes ont été validées et sont parfaitement alignées). |
| 109 | passer | Réussi : le domaine figurant dans SPF ou la signature DKIM correspond bien à l'adresse « De » affichée. |
| 130 | passer | Transmis via une dérogation ARC (un signataire de la chaîne de réception authentifiée, dont la fiabilité est garantie, a certifié le message au cours d'un processus de transfert). |
| 201 | passer | Réussi : l'expéditeur a été identifié comme un expéditeur Microsoft 365 interne ou structurellement fiable. |
| 601 | échouer | Échec : détection d'une incohérence entre le domaine de l'expéditeur tiers et le domaine de signature SPF DKIM (l'adresse « De » visible ne correspond pas au domaine de signature SPF DKIM). |
Remarque : tous les codes d'erreur proviennent directement de la documentation technique officielle de Microsoft. Pour diagnostiquer rapidement vos messages sortants, copiez les en-têtes bruts de vos e-mails et collez-les dans l'outil en ligne Microsoft Message Header Analyzer.
Pourquoi le paramètre « compauth=fail » prendra davantage d'importance après mai 2025
Les conséquences opérationnelles d'un résultat « compauth=fail » se sont considérablement aggravées à la suite de la mise en œuvre des mesures de Microsoft le 5 mai 2025. Les exigences de Microsoft en matière d'expéditeurs ont introduit des critères stricts et automatisés d'authentification des e-mails, ciblant les expéditeurs à fort volume (ceux qui envoient 5 000 messages ou plus par jour) vers des services grand public tels que Outlook.com, Hotmail et Live.com.
Dans le cadre de ces nouveaux mécanismes d'application, une classification « compauth=fail » entraîne directement le classement systématique dans le dossier des courriers indésirables ou le rejet pur et simple du message au niveau de la passerelle. Le filtrage de Microsoft considère désormais une politique DMARC « p=none » comme un facteur déclencheur principal pour « reason=001 », même lorsque SPF DKIM sont réussies individuellement. Les expéditeurs dont la distribution des e-mails était auparavant tolérée en mode de surveillance passive sont désormais confrontés à une baisse soudaine et perturbante de leur taux de délivrabilité dans tous les environnements gérés par Microsoft.
Qu'est-ce qui provoque l'erreur « compauth=fail » ?
Pour résoudre les problèmes de livraison, vous devez associer le code d'erreur spécifique figurant dans l'en-tête « Authentication-Results » à sa cause première :
- reason=000 : Le domaine expéditeur applique une politiquequarantine stricte de type « p=reject » ou «quarantine », et le message a échoué aux vérifications SPF DKIM. Pour obtenir des instructions détaillées sur la résolution des échecs d'authentification, consultez notre guide expliquant les causes des échecs DMARC.
- reason=001 (Standard) : Il s'agit du code d'échec le plus courant. Il indique qu'un domaine utilise une politique de surveillance passive (p=none), l'absence totale d'un enregistrement DMARC, un échec SPF non optimisé (~all) ou des domaines d'identificateurs non alignés.
- reason=001 & reason=601 (Expéditeurs tiers) : cela se produit lorsqu'un fournisseur de services de messagerie (ESP) ou un CRM externe envoie des messages au nom de votre marque, mais signe le message en utilisant les domaines de son infrastructure. Le domaine visible dans l'en-tête « De » ne correspondant pas aux domaines de suivi utilisés par le fournisseur, une erreur d'alignement critique est déclenchée.
- raison=010 : Le système de détection des usurpations de Microsoft signale que le comportement de l'expéditeur est frauduleux, ce qui correspond à une tentative d'hameçonnage ou d'usurpation de domaine.
Comment résoudre le problème « compauth=fail »
Pour résoudre un échec d'authentification composite, il est nécessaire d'apporter des modifications de configuration ciblées en fonction du scénario spécifique à l'origine de l'erreur.
Solution n° 1 : Mettez à jour votre politique DMARC au-delà de p=none
Étant donné qu'une politique de surveillance passive (p=none) est considérée comme un échec d'authentification implicite (reason=001), vous devez faire évoluer votre domaine vers une approche plus stricte. Veillez à faire évoluer votre politique en toute sécurité versquarantine p=reject. En abandonnant une approche purement axée sur la surveillance, vous éliminez la vulnérabilité à l'origine des règles d'échec implicites. Si vous craignez de bloquer des flux hérités légitimes pendant cette transition, consultez nos stratégies de gestion des dérogations aux politiques DMARC.
Solution n° 2 : Configurer correctement l'alignement DKIM
Configurez vos serveurs de messagerie principaux pour qu'ils signent tous les messages sortants à l'aide d'une clé cryptographique DKIM unique. Assurez-vous que le paramètre de domaine de signature (d=) dans l'en-tête DKIM correspond exactement au domaine racine indiqué dans l'en-tête « De: » visible. Cette correspondance cryptographique rigoureuse constitue le signal positif le plus fort possible pour le moteur CompAuth de Microsoft.
Solution 3 : Configurer des chemins de retour personnalisés pour les fournisseurs de services de messagerie tiers
Lorsque vous utilisez des plateformes externes (telles que des moteurs marketing ou des services d'assistance), ne vous fiez pas à leurs paramètres génériques par défaut. Configurez un domaine MAIL FROM ou Return-Path personnalisé utilisant le nom de domaine de votre entreprise, ou assurez-vous que le fournisseur dispose d'une délégation complète lui permettant de signer cryptographiquement les messages à l'aide des clés DKIM de votre domaine. Cela permet de résoudre les problèmes de non-correspondance des identifiants et d'éliminer les échecs de type « reason=601 ».
Correction n° 4 et l'avenir du transfert (passage d'ARC à DKIM2)
Historiquement, lorsque les flux de messagerie de votre organisation transitent régulièrement par des listes de diffusion ou des chaînes de transfert automatisées, les signatures DKIM standard ne fonctionnent plus. Pour résoudre ce problème, la mise en œuvre de Authenticated Received Chain (ARC) était la recommandation standard. Lorsqu'un serveur intermédiaire valide un message entrant et le scelle à l'aide d'un cachet cryptographique de confiance, Microsoft 365 lit la chaîne de contrôle, ignorant les défaillances localisées pour renvoyer un résultat positif compauth=pass reason=130.
Cependant, le paysage de l'authentification des e-mails est en pleine mutation. Le 22 avril 2026, une proposition du groupe de travail DMARC de l'IETF (draft-ietf-dmarc-arc-to-historic-00) a suggéré de reclasser ARC en tant que norme historique. Il s'agit d'un projet Internet (Internet-Draft) du groupe de travail, et non d'un RFC finalisé ; ARC (RFC 8617) reste un protocole actif.
Les enseignements tirés de l'ARC sont intégrés de manière native dans la nouvelle spécification DKIM2, qui traite des signatures corrompues lors du transfert et des attaques par rejeu DKIM. Selon la dernière ébauche de l'IETF datée du 17 mai 2026 (draft-ietf-dkim-dkim2-spec-02), chaque système qui traite un message enregistre les modifications et ajoute sa propre signature à une chaîne de contrôle inviolable.
Ce que cela signifie pour vous à l'heure actuelle :
- Pour l'instant, laissez l'ARC actif : Microsoft utilise toujours le code « reason=130 » (contournement de l'ARC) pour transférer les e-mails, alors ne désinstallez pas tout de suite votre configuration du sceau ARC de confiance Microsoft.
- Préparez-vous à DKIM2 : certains fournisseurs de messagerie majeurs pourraient commencer à déployer cette technologie dès la fin de l'année 2026, bien que la spécification en soit encore aux premiers stades de l'élaboration. Étant donné que les clés DKIM2 utiliseront votre structure d'enregistrements DNS existante, le meilleur moyen de vous prémunir contre de futurs échecs d'authentification est de vous assurer que votre infrastructure DKIM actuelle est irréprochable. Supprimez les sélecteurs obsolètes et veillez à ce que la rotation des clés soit effectuée correctement.
Solution n° 5 : tirer parti de la fonctionnalité « Spoof Intelligence » de M365 pour autoriser les connexions
Pour les applications internes, les anciens appareils sur site ou les profils d'expéditeurs légitimes hautement spécialisés qui déclenchent des faux positifs générés par l'apprentissage automatique (raison=010), les administrateurs Microsoft 365 peuvent passer outre l'algorithme manuellement. Accédez au portail Microsoft 365 Defender, ouvrez la console d'informations Spoof Intelligence, puis ajoutez une entrée d'autorisation explicite à la liste d'autorisation/de blocage du locataire pour ce profil d'expéditeur spécifique.
Comment lire le champ « compauth » dans les en-têtes d'e-mail
Pour identifier et analyser ces valeurs, il faut extraire les en-têtes bruts de routage Internet d'un message concerné.
- Extraire les en-têtes : dans la version de bureau d'Outlook, ouvrez l'e-mail concerné dans une fenêtre distincte, puis accédez à Fichier > Propriétés > En-têtes Internet. Sinon, si vous êtes administrateur et que vous cherchez à résoudre un problème de distribution plus général, demandez aux utilisateurs ou utilisez les journaux d'administration pour copier le texte brut des en-têtes et le coller directement dans l'outil Microsoft Message Header Analyzer (MHA) à l'adresse mha.azurewebsites.net afin d'obtenir une vue analysée et facilement consultable.
- Isoler la ligne concernée : recherchez dans le texte analysé le bloc spécifique intitulé « Authentication-Results ». Recherchez attentivement l'expression « compauth= », qui sera immédiatement suivie de son statut d'évaluation (pass, fail ou softpass) et du code « reason= » correspondant.
- Croisez les données : ne considérez pas le résultat d'authentification composite isolément. Vérifiez les paramètres adjacents dans cette même ligne d'en-tête, en examinant plus particulièrement les résultats individuels spf, dkim= et dmarc=. En comparant ces valeurs explicites côte à côte avec le code de motif compauth, vous identifierez précisément quelle vérification a échoué ou quel signal implicite a déclenché le classement dans le dossier des courriers indésirables.
Comment éviter définitivement les erreurs « compauth=fail » ?
L'analyse manuelle des en-têtes et la coordination de l'alignement entre une douzaine de fournisseurs tiers peuvent s'avérer une tâche écrasante pour les équipes informatiques internes. PowerDMARC simplifie ce processus en offrant une visibilité complète et des outils de gestion automatisés, vous aidant ainsi à résoudre les erreurs « compauth=fail » et à maintenir la qualité de vos enregistrements d'authentification des e-mails.
Commencez dès aujourd'hui un essai gratuit de DMARC pour bénéficier d'une visibilité claire sur vos flux de livraison Microsoft 365, éliminer les erreurs d'alignement et faire passer votre domaine en toute sécurité à une politique DMARC appliquée.
Foire aux questions
Que signifie « compauth=fail » dans les en-têtes d'e-mail ?
Cela signifie que le système Exchange Online Protection de Microsoft a analysé le message entrant et l'a rejeté en se basant à la fois sur des protocoles d'authentification explicites (SPF, DKIM, DMARC) et sur des signaux implicites issus de l'analyse des menaces (réputation de l'expéditeur, informations sur l'usurpation d'identité, historique).
Quelle est la différence entre Compauth et DMARC ?
DMARC est un protocole Internet ouvert et mondial utilisé par tous les fournisseurs de messagerie pour vérifier la cohérence des identifiants. compauth est une couche d'évaluation propriétaire, exclusive à Microsoft, qui s'appuie sur les résultats DMARC standard et intègre des indicateurs supplémentaires de réputation et de comportement en temps réel.
Pourquoi la vérification d'authenticité échoue-t-elle alors que SPF DKIM sont réussies ?
Cela se produit souvent si votre domaine est configuré avec une politique DMARC passive (p=none), que le système mis à jour de Microsoft considère comme un risque pour la délivrabilité. L'envoi peut également échouer si le système interne de détection des usurpations de Microsoft signale que le comportement transactionnel ou l'historique d'envoi de l'expéditeur présente des anomalies.
Que signifie « compauth fail reason=001 » ?
Le code d'erreur 001 indique que le message ne répond pas aux critères d'authentification implicites de Microsoft. Cela est généralement dû à l'absence SPF DMARC ou SPF , à un décalage entre les identifiants, ou au fait de maintenir une politique DMARC passive (p=none) au lieu de passer à la phase d'application.
Comment résoudre le problème « compauth=fail » dans Microsoft 365 ?
Assurez-vous que vos domaines SPF DKIM correspondent parfaitement à l'en-tête « De » visible, passez votre politique DMARC de « p=none » à un niveau d'application tel que «quarantine « p=reject », et configurez des sceaux ARC de confiance si vos flux de messagerie impliquent un transfert automatique.
Le paramètre « compauth=fail » fait-il en sorte que les e-mails soient envoyés dans le dossier Courrier indésirable dans Outlook ?
Oui. Conformément à des mesures de sécurité strictes, un statut « compauth=fail » déclenche directement le moteur de filtrage EOP, qui achemine les messages entrants directement vers le dossier des courriers indésirables ou les rejette complètement au niveau du périmètre.
Expert en sécurité des domaines et des courriels chez PowerDMARC
Yunes est chef d'équipe des opérations chez PowerDMARC et possède des connaissances approfondies en matière d'authentification et de sécurité des courriels. Yunes est certifié Microsoft Azure Administrator Associate et possède des certifications CompTIA A+ et bien d'autres encore.
Derniers messages de Yunes Tarada (voir tous)
