Compauth=fail sur Microsoft 365 : comprendre l'authentification composite et corriger les reason codes
Par CaptainDNS
Publié le 1 juin 2026
compauthest le verdict d'authentification composite de Microsoft 365 : il combine SPF, DKIM, DMARC et des signaux internes (réputation, historique, PTR), ce n'est pas un standard RFC- Le champ s'écrit
compauth=<pass|softpass|fail|none> reason=<code>dans l'en-têteAuthentication-Results; lereasonindique pourquoi compauth=failne bloque pas automatiquement un message dans le cas général : Microsoft applique une évaluation holistique (SCL, CAT, SFTY) avant de décider boîte de réception, courrier indésirable ou quarantaine. Réserve : depuis 2023, un échec DMARC explicite contrep=rejectpeut être rejeté à la passerelle (NDR550 5.7.509) quand le MX pointe directement vers Microsoft 365- La correction durable passe presque toujours par l'alignement de SPF + DKIM + DMARC sur le domaine du
From: - Les codes 604, 605 et 703 cités par certains outils tiers ne sont pas documentés par Microsoft : ne basez pas un diagnostic dessus
Vous inspectez les en-têtes d'un message dans Microsoft 365 et vous tombez sur compauth=fail reason=001. Le courrier vient d'un expéditeur connu, SPF semble correct, et pourtant le message atterrit en courrier indésirable ou en quarantaine. Le champ compauth est l'un des plus mal compris d'Exchange Online, parce qu'il ne correspond à aucun protocole standard : c'est une mécanique propriétaire de Microsoft.
Ce guide est une référence exhaustive. Il explique ce qu'est l'authentification composite, comment Microsoft 365 calcule ce verdict à partir de SPF, DKIM, DMARC et de signaux internes, la différence essentielle entre authentification implicite et explicite, puis fournit le tableau complet des reason codes vérifié sur la documentation Microsoft officielle. Vous y trouverez enfin un plan de diagnostic et de correction organisé par famille de codes.
Il s'adresse aux administrateurs Microsoft 365 et Exchange Online dont les messages légitimes sont marqués comme usurpation ou mis en quarantaine, ainsi qu'aux responsables de délivrabilité qui doivent lire et interpréter un en-tête d'authentification Microsoft.
Analysez vos en-têtes Microsoft 365 et votre politique DMARC
Qu'est-ce que l'authentification composite (compauth) de Microsoft 365 ?
L'authentification composite est un verdict propriétaire de Microsoft. Contrairement à SPF (RFC 7208), DKIM (RFC 6376) et DMARC (RFC 7489), compauth n'est défini par aucune norme. C'est une couche d'évaluation que Microsoft 365 ajoute par-dessus ces trois protocoles pour produire un jugement global sur l'authenticité d'un expéditeur.
Concrètement, Exchange Online Protection (EOP) ne se contente pas de relayer les résultats SPF, DKIM et DMARC. Il les agrège avec des signaux supplémentaires : la réputation de l'adresse IP émettrice, l'historique des messages déjà reçus de cette infrastructure, l'enregistrement PTR (DNS inverse) de l'IP, et des modèles comportementaux issus de l'analyse de masse du trafic Microsoft. Le résultat de cette agrégation est inscrit dans le champ compauth de l'en-tête Authentication-Results.
L'unité de base de l'évaluation est le domaine du From: visible par le destinataire, c'est-à-dire l'adresse de l'en-tête 5322.From (aussi appelé domaine P2). C'est ce domaine que Microsoft cherche à protéger contre l'usurpation, et c'est sur lui que portent l'alignement et le verdict composite. Cette précision n'est pas anodine : un message peut très bien réussir SPF sur le domaine de l'enveloppe (5321.MailFrom) tout en échouant à l'authentification composite, parce que ce domaine d'enveloppe ne correspond pas au domaine affiché dans le From:. L'utilisateur final ne voit jamais l'enveloppe, seulement le From: ; c'est donc logiquement sur cette adresse que repose la protection contre l'usurpation.
Pourquoi Microsoft a-t-il créé cette couche supplémentaire plutôt que de s'en tenir à DMARC ? Parce que l'adoption de DMARC reste partielle. Une part importante des domaines légitimes n'a aucune politique DMARC, ou publie un p=none qui ne donne aucune instruction d'application. Sans signal composite, Microsoft devrait soit faire confiance aveuglément à ces domaines (et laisser passer l'usurpation), soit les pénaliser systématiquement (et bloquer du courrier légitime). L'authentification composite est la réponse à ce dilemme : elle permet d'évaluer un expéditeur même lorsque les protocoles standards ne fournissent pas de verdict tranché, en s'appuyant sur des signaux observables côté Microsoft.
Le champ apparaît typiquement sous cette forme dans un en-tête :
Authentication-Results: spf=pass (sender IP is 40.107.0.1)
smtp.mailfrom=captaindns.com; dkim=pass (signature was verified)
header.d=captaindns.com; dmarc=pass action=none
header.from=captaindns.com; compauth=pass reason=100
La syntaxe générale est compauth=<résultat> reason=<code>. Le résultat prend l'une de quatre valeurs, et le code à trois chiffres précise la raison exacte du verdict.
compauth=pass / softpass / fail / none : que veut dire chaque valeur ?
Le résultat composite ne se limite pas à réussite ou échec. Microsoft distingue quatre états, chacun avec une signification précise.
| Valeur | Signification |
|---|---|
pass | Le message a réussi l'authentification composite, par voie explicite (SPF/DKIM/DMARC alignés) ou implicite (signaux internes suffisants). |
softpass | Le message a partiellement réussi l'authentification implicite. Les signaux sont positifs mais faibles (alignement par PTR ou par sous-réseau, par exemple). |
fail | Le message a échoué à l'authentification composite, explicite ou implicite. Ce n'est pas un verdict de blocage, mais un facteur de risque. |
none | Le message n'a pas été évalué pour l'authentification composite, ou l'a contournée (routage particulier, message déjà traité en amont). |
La nuance entre fail et none est importante. fail signale un échec actif d'authentification : Microsoft a évalué le message et conclu qu'il ne pouvait pas garantir l'identité de l'expéditeur. none signale une absence d'évaluation, souvent due à un routage complexe ou à un message qui a déjà traversé une autre passerelle.
Authentification implicite vs explicite : la clé pour comprendre compauth
C'est la distinction la plus importante de tout l'article. Microsoft 365 évalue l'authentification d'un message selon deux voies, et le reason code indique laquelle a été empruntée.
L'authentification explicite repose sur les enregistrements DNS publiés par le domaine expéditeur : SPF, DKIM et la politique DMARC. C'est l'authentification standard. Si le domaine publie un DMARC strict (p=quarantine ou p=reject) et que le message s'aligne correctement, le verdict est explicite.
L'authentification implicite est une extension propre à Microsoft. Lorsqu'un domaine ne publie pas de DMARC, ou publie une politique permissive (p=none, SPF en ~all ou ?all), Microsoft ne peut pas s'appuyer sur une intention déclarée. Il applique alors ses propres signaux pour décider : réputation IP, historique d'envoi, alignement par PTR, MX du domaine. Cette voie permet à un message légitime sans DMARC de passer (par exemple le reason 109), mais expose aussi à un échec implicite (reason 001 ou 6xx) lorsque les signaux sont insuffisants.
Cette mécanique explique deux situations qui déroutent souvent les administrateurs. Un message d'un domaine sans aucune authentification peut obtenir compauth=pass si son IP a une excellente réputation et un historique propre (authentification implicite réussie). À l'inverse, un message d'un domaine avec un DMARC strict mais mal aligné obtient compauth=fail reason=000 (authentification explicite échouée), même si l'IP émettrice est par ailleurs réputée.
La voie explicite est toujours prioritaire. Si le domaine publie un DMARC exploitable, Microsoft applique sa politique avant de recourir aux signaux implicites. C'est pourquoi publier un DMARC correctement aligné est le levier de contrôle le plus puissant dont dispose un expéditeur sur son verdict composite.
Où trouver compauth=fail dans vos en-têtes ?
Le verdict composite se lit dans l'en-tête Authentication-Results, mais l'analyse complète demande de croiser plusieurs en-têtes Microsoft.
L'en-tête Authentication-Results rassemble les verdicts SPF, DKIM, DMARC et compauth. C'est le point de départ. Mais pour comprendre l'impact réel d'un compauth=fail, il faut aussi lire l'en-tête X-Forefront-Antispam-Report, qui contient les champs décisionnels d'EOP.
Dans X-Forefront-Antispam-Report, plusieurs champs sont utiles :
| Champ | Rôle |
|---|---|
CAT | Catégorie de verdict EOP (SPM pour spam, PHSH pour hameçonnage, SPOOF pour usurpation, BULK, etc.). |
SFV | Verdict du filtre (par exemple SKS pour règle de transport, SPM pour spam). |
SCL | Spam Confidence Level, de -1 à 9. Plus la valeur est haute, plus le message est jugé indésirable. |
SFTY | Indicateur de sûreté, notamment 9.x pour les messages de type usurpation ou hameçonnage : 9.19 usurpation de domaine, 9.20 usurpation d'utilisateur, 9.25 conseil de sécurité « premier contact ». |
Voici un exemple d'en-tête réel, commenté, où l'authentification composite échoue :
Authentication-Results: spf=none (sender IP is 203.0.113.20)
smtp.mailfrom=marketing.captaindns.com; dkim=none (message not signed)
header.d=none; dmarc=none action=none header.from=captaindns.com;
compauth=fail reason=001
X-Forefront-Antispam-Report: CIP:203.0.113.20; CTRY:US;
CAT:SPOOF; SFV:SPM; SCL:5; SFTY:9.19
Ici, le domaine ne publie ni SPF exploitable, ni DKIM, ni DMARC : l'authentification explicite est impossible et l'implicite échoue (reason=001). EOP classe le message en CAT:SPOOF avec un SCL:5 et un indicateur SFTY:9.19, ce qui le destine au courrier indésirable. C'est le croisement de compauth=fail et de ces champs décisionnels qui détermine le sort réel du message.
Encore faut-il savoir où récupérer ces en-têtes. Dans Outlook pour le web, ouvrez le message, puis le menu d'options et « Afficher les détails du message » pour copier la source brute. Dans le client Outlook lourd, ouvrez le message dans sa propre fenêtre, puis Fichier puis Propriétés : le champ « En-têtes Internet » contient l'ensemble. Côté administrateur, le suivi des messages (message trace) du centre d'administration Exchange permet de retrouver le verdict EOP d'un message livré sans même accéder à la boîte du destinataire. Pour un diagnostic à l'échelle, les rapports agrégés DMARC (RUA) recoupent les sources d'envoi qui échouent et complètent utilement la lecture d'en-tête unitaire.
Pour extraire et lire ces en-têtes sans erreur, copiez la source complète du message et passez-la dans un analyseur dédié. Le sujet de la lecture des en-têtes est détaillé dans notre guide Comment lire les en-têtes d'un email.
Le tableau complet des reason codes compauth
Voici la référence centrale de cet article. Le tableau ci-dessous est vérifié sur la documentation Microsoft officielle (page « Anti-spam message headers » de Microsoft Learn, à jour au 8 octobre 2025). Chaque ligne donne le code, le résultat composite associé, la signification exacte selon Microsoft, la cause typique et la résolution.
| Code | compauth | Signification (Microsoft) | Cause typique | Résolution |
|---|---|---|---|---|
| 000 | fail | Échec d'authentification explicite. DMARC échoue avec une politique p=quarantine ou p=reject. Depuis 2023, un p=reject honoré par défaut peut entraîner un rejet à la passerelle (NDR 550 5.7.509), pas seulement un classement en Indésirables. | Le domaine publie un DMARC strict mais le message ne s'aligne pas (SPF/DKIM cassent l'alignement, souvent en transfert ou source non autorisée). | Aligner SPF et DKIM sur le From: ; autoriser la source d'envoi ; configurer un ARC sealer de confiance en cas de transfert. |
| 001 | fail | Échec d'authentification implicite. Pas d'enregistrements d'authentification publiés, ou politique faible. | Le domaine n'a pas (ou peu) d'authentification : SPF en ~all/?all, ou DMARC en p=none. Microsoft manque de signal. | Publier SPF + DKIM + DMARC alignés ; durcir progressivement vers ~all puis -all. |
| 002 | fail | Une politique du tenant interdit explicitement ce couple expéditeur/domaine. | Entrée manuelle d'administrateur (Tenant Allow/Block List, blocage d'usurpation). | Vérifier et retirer l'entrée de blocage si l'expéditeur est légitime. |
| 010 | fail | DMARC échoue avec p=reject/p=quarantine, et le domaine expéditeur est un domaine accepté de votre organisation. | Usurpation intra-organisation : un service tiers envoie « en tant que » votre propre domaine sans y être autorisé. | Autoriser la source dans SPF/DKIM ou via la Tenant Allow/Block List. |
| 1xx | pass | Le message a réussi l'authentification explicite ou implicite. | Succès. | Aucune action. |
| 100 | pass | SPF a réussi ou DKIM a réussi, et MAIL FROM et From sont alignés. | Succès nominal. | Aucune action. |
| 101 | pass | Le message est signé en DKIM par le domaine du From:. | Succès DKIM aligné. | Aucune action. |
| 102 | pass | MAIL FROM et From alignés, et SPF a réussi. | Succès SPF aligné. | Aucune action. |
| 103 | pass | Le From: est aligné avec le PTR (DNS inverse) de l'IP source. | Succès via PTR. | Aucune action. |
| 104 | pass | Le PTR de l'IP source est aligné avec le domaine du From:. | Succès via PTR. | Aucune action. |
| 108 | pass | DKIM a échoué à cause d'une modification du corps par un saut légitime précédent. | Toléré (environnement on-premises, par exemple). | Surveiller les modifications en transit ; envisager ARC. |
| 109 | pass | Pas de DMARC, mais le message passerait quand même l'évaluation. | Toléré. | Publier DMARC pour formaliser l'intention. |
| 111 | pass | Malgré un temperror ou permerror DMARC, SPF ou DKIM est aligné avec le From:. | Toléré malgré une erreur DNS. | Corriger l'enregistrement DMARC. |
| 112 | pass | Un timeout DNS a empêché la récupération du DMARC. | Erreur DNS transitoire. | Vérifier la résolution DNS du domaine. |
| 115 | pass | Le message vient d'une organisation Microsoft 365 où le From: est un domaine accepté. | Toléré (Microsoft 365 vers Microsoft 365). | Aucune action. |
| 116 | pass | Le MX du From: est aligné avec le PTR de l'IP de connexion. | Toléré. | Aucune action. |
| 130 | pass | Le résultat ARC d'un ARC sealer de confiance a remplacé un échec DMARC. | Transfert via un service de confiance ARC. | Configurer des ARC sealers de confiance. |
| 2xx | softpass | Le message a partiellement réussi l'authentification implicite. | Signaux partiels. | Renforcer SPF/DKIM/DMARC. |
| 201 | softpass | Le PTR du From: est aligné avec le sous-réseau du PTR de l'IP de connexion. | Alignement faible (sous-réseau). | Renforcer l'authentification. |
| 202 | softpass | Le From: est aligné avec le domaine du PTR de l'IP de connexion. | Alignement faible (PTR). | Renforcer l'authentification. |
| 3xx | none | Le message n'a pas été vérifié pour l'authentification composite. | Non évalué. | Aucune. |
| 4xx | none | Le message a contourné l'authentification composite. | Contournement. | Aucune. |
| 501 | (s.o.) | DMARC non appliqué : NDR (rapport de non-remise) valide, contact préalablement établi. | Tolérance NDR. | Aucune action. |
| 502 | (s.o.) | DMARC non appliqué : NDR valide pour un message envoyé par cette organisation. | Tolérance NDR. | Aucune action. |
| 6xx | fail | Échec d'authentification email implicite. | Échec implicite. | Publier et aligner SPF, DKIM, DMARC. |
| 601 | fail | Le domaine expéditeur est un domaine accepté de votre organisation (envoi à soi-même / usurpation intra-org). | Application ou service interne ou tiers envoyant « comme vous » sans authentification. | Autoriser la source (SPF/DKIM, relais authentifié, Tenant Allow/Block List). |
| 7xx | pass | Le message a réussi l'authentification implicite. | Succès implicite. | Aucune action. |
| 701-704 | pass | DMARC non appliqué grâce à un historique de messages légitimes depuis cette infrastructure. | Réputation et historique. | Aucune action. |
| 9xx | none | Le message a contourné l'authentification composite. | Contournement. | Aucune. |
| 905 | none | DMARC non appliqué à cause d'un routage complexe (on-premises ou service tiers avant Microsoft 365). | Routage hybride. | Configurer ARC ou un relais authentifié. |
Encadré exactitude : les codes 604, 605 et 703
Certains outils tiers (dont des analyseurs DMARC commerciaux) citent les codes
604,605et703comme des reason codes compauth distincts. Ces codes n'apparaissent pas dans la documentation Microsoft officielle actuelle. Dans la famille 6xx, Microsoft ne documente que le code601. Dans la famille 7xx, la documentation couvre la plage701-704sans isoler703avec une signification propre. Aucun604ni605n'est défini.Nous ne leur inventons donc aucune signification. Si vous rencontrez l'un de ces codes, traitez-le selon sa famille : un
6xxest un échec implicite (à corriger comme un601), un7xxest un succès implicite. Ne fondez pas un diagnostic sur une définition non sourcée.
Codes d'échec : 000, 001, 002, 010 et 6xx/601
Ce sont les codes qui amènent un administrateur à lire cet article. Ils se répartissent en deux logiques.
Les codes 000 et 010 relèvent de l'échec explicite : le domaine publie un DMARC strict, mais le message ne s'aligne pas. Le 010 est le cas particulier où le domaine en échec est un domaine accepté de votre propre organisation. Le 000, lui, concerne tout domaine externe avec DMARC strict mal aligné.
Les codes 001, 6xx et 601 relèvent de l'échec implicite : Microsoft n'a pas pu s'appuyer sur une politique déclarée et ses signaux internes n'ont pas suffi. Le 601 est le sous-cas du domaine accepté de l'organisation. Le 002, enfin, est un cas à part : il ne reflète pas un défaut technique mais une décision d'administrateur (une entrée de blocage manuelle).
Codes de succès (1xx, 7xx) et softpass (2xx)
La famille 1xx regroupe les succès, qu'ils soient explicites (100, 101, 102) ou tolérés malgré une faiblesse (108, 109, 111, 112). Le 130 mérite une attention particulière : il indique qu'un ARC sealer de confiance a permis de récupérer un message qui aurait échoué en DMARC à cause d'un transfert.
La famille 7xx regroupe les succès implicites fondés sur la réputation et l'historique. La famille 2xx (softpass) signale un succès faible : l'alignement repose sur des signaux ténus comme le PTR ou le sous-réseau. Un softpass n'est pas un échec, mais il vaut mieux le renforcer en publiant une authentification explicite.
Codes none / bypass (3xx, 4xx, 9xx, 905) et NDR (501/502)
Les familles 3xx, 4xx et 9xx correspondent à des messages non évalués ou ayant contourné l'authentification composite. Le 905 est le plus instructif : il signale un routage complexe (passage par un serveur on-premises ou un service tiers avant Microsoft 365) qui empêche l'application normale du DMARC. La réponse à un 905 est généralement la mise en place d'ARC ou d'un relais authentifié.
Les codes 501 et 502 concernent les NDR (rapports de non-remise) légitimes : Microsoft ne leur applique pas DMARC car ils répondent à un contact préalablement établi.
Diagnostic et résolution par famille de codes
Le tableau donne la vue d'ensemble. Cette section approfondit les cas les plus fréquents et la marche à suivre concrète.
reason=000 : un DMARC strict cassé par l'alignement
Le reason=000 signifie que le domaine expéditeur publie un DMARC en p=quarantine ou p=reject, mais que le message ne respecte pas l'alignement DMARC. L'alignement DMARC exige que SPF ou DKIM réussisse et que le domaine vérifié corresponde au domaine du From:. À noter : depuis mi-août 2023, lorsque le destinataire pointe son MX directement vers Microsoft 365, un reason=000 face à un p=reject ne se contente plus de dégrader le message, il peut entraîner un rejet au niveau de la passerelle (NDR 550 5.7.509). L'enjeu de la correction n'est donc plus seulement la boîte de réception contre les Indésirables, mais la remise tout court.
La cause la plus fréquente est le transfert d'email. Lorsqu'un message est retransmis, l'IP émettrice change (l'IP du serveur de transfert remplace l'IP d'origine), ce qui casse l'alignement SPF. Si DKIM n'est pas présent ou si le corps est modifié en transit, DKIM échoue aussi, et DMARC échoue donc complètement.
La deuxième cause est l'envoi depuis une source non autorisée : un prestataire d'emailing qui n'a pas été déclaré dans le SPF ni configuré pour signer en DKIM avec votre domaine.
La résolution dépend du cas. Pour une source d'envoi légitime, autorisez-la : ajoutez son mécanisme include: au SPF et configurez la signature DKIM alignée sur votre domaine. Pour le transfert, la seule réponse robuste est ARC : le serveur de transfert doit apposer une signature ARC, et le destinataire Microsoft 365 doit reconnaître ce sealer comme de confiance (ce qui produit alors un reason=130).
Prenons un exemple concret de transfert qui produit un reason=000. Un message part de compta@captaindns.com, dûment signé en DKIM avec d=captaindns.com et émis depuis une IP autorisée par le SPF du domaine. Tout est aligné à l'origine. Le destinataire a configuré une redirection automatique vers une boîte hébergée chez Microsoft 365. Le serveur de redirection réexpédie le message depuis sa propre IP, qui n'est pas dans le SPF de captaindns.com : SPF échoue côté Microsoft. Si le serveur de redirection a, en plus, ajouté un avertissement « message transféré » au corps, le hash DKIM ne correspond plus et DKIM échoue aussi. Le From: est resté compta@captaindns.com avec un DMARC strict : DMARC échoue donc complètement, et Microsoft inscrit compauth=fail reason=000. Le message est pourtant parfaitement légitime. Seul ARC, en préservant les résultats d'authentification d'origine tout au long de la chaîne, permet de récupérer ce cas sans assouplir la politique du domaine émetteur.
reason=001 : authentification manquante ou trop faible
Le reason=001 est l'échec implicite par excellence. Le domaine ne fournit pas à Microsoft de quoi décider : pas de DMARC exploitable, SPF en ~all ou ?all, pas de DKIM aligné. Microsoft tente une authentification implicite, mais les signaux (réputation IP, historique) ne suffisent pas à conclure positivement.
La résolution est structurelle. Publiez les trois piliers de l'authentification email. Un SPF correct qui déclare toutes vos sources d'envoi, des signatures DKIM alignées sur votre domaine, et un enregistrement DMARC. Commencez DMARC en p=none correctement aligné pour observer sans bloquer, puis durcissez vers p=quarantine une fois vos sources maîtrisées. Côté SPF, faites évoluer le mécanisme de fin de ~all vers -all lorsque vous êtes certain de l'exhaustivité de vos sources.
Une nuance importante : un domaine en p=none ou un SPF en ~all n'est pas « cassé », il est seulement permissif. Microsoft interprète cette permissivité comme une absence d'intention claire et bascule sur l'authentification implicite. Le reason=001 n'est donc pas la sanction d'une erreur de syntaxe, mais le constat que le domaine ne donne pas à Microsoft de quoi conclure positivement par la voie standard. C'est précisément pourquoi renforcer les politiques fait disparaître le code : vous passez l'évaluation de la voie implicite (incertaine) à la voie explicite (déterministe).
reason=010 et reason=601 : l'usurpation intra-organisation
Ces deux codes partagent une caractéristique : le domaine expéditeur est un domaine accepté de votre propre organisation Microsoft 365. Autrement dit, un message prétend venir de votre domaine, mais Microsoft ne peut pas confirmer qu'il a bien été émis par une source autorisée. Le 010 correspond au volet explicite (DMARC strict en échec), le 601 au volet implicite.
C'est un scénario extrêmement courant en pratique : une imprimante réseau, une application métier, un CRM, un outil de facturation ou un prestataire marketing envoie des emails « en tant que » votre domaine sans avoir été déclaré dans votre SPF ni configuré en DKIM. Microsoft interprète cela comme une potentielle usurpation interne. Ce mécanisme est lié à l'avertissement « via » que Microsoft 365 affiche parfois ; nous le détaillons dans notre article sur l'usurpation intra-organisation et l'avertissement Microsoft.
La résolution consiste à autoriser explicitement la source légitime. Trois options, par ordre de préférence : ajouter la source à votre enregistrement SPF et la configurer pour signer en DKIM avec votre domaine ; faire transiter ses envois par un relais SMTP authentifié de votre tenant ; en dernier recours, créer une entrée dans la Tenant Allow/Block List. Évitez de vous reposer durablement sur la liste d'autorisation : c'est un correctif d'attente, pas une authentification.
reason=002 : un blocage manuel par la politique du tenant
Le reason=002 ne traduit aucun défaut technique. Il signale qu'un administrateur a explicitement bloqué ce couple expéditeur/domaine, généralement via la Tenant Allow/Block List ou une règle anti-usurpation. Si l'expéditeur est légitime, la résolution est simple : retirer l'entrée de blocage. Avant cela, vérifiez pourquoi le blocage a été posé, afin de ne pas rouvrir une porte fermée pour une bonne raison.
reason=130 : un ARC sealer a légitimement remplacé l'échec DMARC
Le reason=130 est un succès, pas un problème. Il indique qu'un message aurait échoué en DMARC (typiquement à cause d'un transfert), mais qu'un ARC sealer de confiance a préservé les résultats d'authentification d'origine, ce que Microsoft a accepté. C'est exactement le comportement recherché pour le transfert légitime. Si vous voyez ce code, votre chaîne ARC fonctionne. Le fonctionnement d'ARC est détaillé dans notre guide Qu'est-ce que l'ARC (Authenticated Received Chain).
Compauth=fail signifie-t-il que mon email est bloqué ?
Non dans le cas général, mais avec une réserve importante depuis 2023. La documentation Microsoft reste explicite sur le principe : un compauth=fail n'entraîne pas, à lui seul, un rejet ni une mise en quarantaine automatique. Le verdict composite est un facteur parmi d'autres dans l'évaluation holistique d'EOP. C'est vrai en particulier pour un échec implicite (reason=001) et pour les domaines sans DMARC strict : le message est alors évalué globalement et atterrit souvent en courrier indésirable, pas rejeté.
La réserve concerne l'échec explicite face à une politique DMARC stricte. Depuis la mi-août 2023, lorsque le domaine destinataire pointe son MX directement vers Microsoft 365, Exchange Online Protection honore par défaut la politique DMARC publiée par le domaine expéditeur. Un échec DMARC contre p=reject entraîne alors un rejet au niveau de la passerelle (avec un rapport de non-remise, NDR), et p=quarantine une mise en quarantaine, au lieu de l'ancien comportement qui classait tout en Indésirables. Ce changement provient du réglage anti-hameçonnage « Honorer la politique DMARC lorsqu'un message est détecté comme usurpation », actif par défaut, avec des actions configurables distinctes pour p=quarantine et pour p=reject. Concrètement, un échec explicite typé reason=000 contre un p=reject peut désormais être rejeté à la passerelle, et non plus seulement classé en Indésirables. Le NDR retourné prend la forme : 550 5.7.509: Access denied, sending domain ... does not pass DMARC verification and has a DMARC policy of reject.
Une réserve dans la réserve : ce rejet par défaut s'applique quand le MX du destinataire pointe directement vers Microsoft 365. Si le MX pointe vers une passerelle tierce placée devant Microsoft 365, EOP n'honore la politique DMARC que si le « filtrage amélioré pour les connecteurs » (Enhanced Filtering for Connectors) est activé, car il doit pouvoir retrouver l'IP d'envoi réelle derrière le relais.
Après avoir établi le verdict composite, EOP combine cette information avec d'autres signaux pour décider du sort du message : le SCL (Spam Confidence Level), la catégorie CAT, l'indicateur de sûreté SFTY, la réputation de l'IP, le contenu du message, et les politiques anti-spam et anti-hameçonnage configurées dans le tenant. Un message peut très bien obtenir compauth=fail et arriver malgré tout en boîte de réception si les autres signaux sont rassurants.
À l'inverse, c'est lorsque compauth=fail se combine avec une catégorie défavorable que le message est dégradé. Un CAT:SPOOF accompagné d'un SFTY:9.x oriente le message vers le courrier indésirable ou la quarantaine, avec souvent un bandeau d'avertissement d'usurpation. C'est donc le contexte global, pas le seul compauth, qui détermine la livraison.
Concrètement, plusieurs chemins de décision coexistent. Un compauth=fail reason=001 venant d'une IP à bonne réputation, sans contenu suspect, peut atterrir en boîte de réception avec un simple SCL bas. Le même reason=001 venant d'une IP nouvelle ou peu réputée, avec des liens ou des pièces jointes typés, hérite d'un SCL élevé et d'une catégorie SPM ou PHSH, et part en courrier indésirable. Enfin, un compauth=fail avec CAT:SPOOF et SFTY:9.19 (usurpation de domaine) déclenche la protection anti-usurpation et peut mener directement à la quarantaine. La même valeur compauth=fail produit donc trois issues différentes selon l'environnement de signaux qui l'entoure.
Cette logique a une conséquence pratique. Corriger un compauth=fail ne se résume pas à faire disparaître un drapeau : il s'agit de réduire le risque global perçu par Microsoft. Aligner SPF, DKIM et DMARC fait remonter le verdict composite vers pass, mais améliore aussi la réputation de votre infrastructure dans la durée, ce qui agit sur l'ensemble des signaux. Si vos messages partent en courrier indésirable malgré une authentification correcte, notre guide Pourquoi vos emails arrivent en spam couvre les autres leviers de délivrabilité.
Plan d'action recommandé pour corriger un compauth=fail
Voici la marche à suivre, du diagnostic à la vérification, applicable quel que soit le reason code.
Ouvrez la source complète du message et relevez la valeur exacte de
compauth=fail reason=<code>dans l'en-têteAuthentication-Results. Notez aussiCAT,SCLetSFTYdansX-Forefront-Antispam-Report. Le reason code oriente tout le diagnostic.Contrôlez que toutes vos sources d'envoi figurent dans l'enregistrement SPF et que l'alignement
MAIL FROM/Fromest respecté. Surveillez le nombre de requêtes DNS (limite de 10) qui provoque unpermerror.Assurez-vous que vos messages sont signés en DKIM et que le domaine de signature (
header.d=) correspond au domaine duFrom:. Sans alignement DKIM, DMARC ne peut pas réussir par cette voie.Contrôlez la présence et la cohérence de l'enregistrement DMARC. Vérifiez l'alignement et la politique (
p=). Une politique stricte mal alignée provoque unreason=000; une politique absente ou enp=nonefavorise unreason=001.Si l'échec vient d'un transfert, mettez en place ARC. Le serveur de transfert doit sceller le message, et Microsoft 365 doit reconnaître le sealer comme de confiance pour produire un
reason=130.Pour un
reason=010ou601, autorisez la source interne : ajout au SPF et signature DKIM alignée, relais SMTP authentifié, ou en dernier recours Tenant Allow/Block List.Après correction, envoyez un message de test et inspectez à nouveau l'en-tête. Le verdict doit remonter vers
compauth=pass(reason 100 ou 130 selon le cas).
Pour les étapes SPF et DKIM, deux outils accélèrent le diagnostic : le vérificateur SPF confirme l'alignement et compte les requêtes DNS, et le vérificateur DKIM valide la publication et la syntaxe de votre clé. Les causes détaillées d'un échec de signature sont couvertes dans notre guide DKIM fail : causes et correctifs, et les erreurs SPF dans SPF permerror : diagnostic et résolution et SPF : trop de requêtes DNS.
Les nouvelles exigences de Microsoft pour les expéditeurs à fort volume
Le compauth d'Exchange Online Protection concerne le courrier reçu par les organisations Microsoft 365. En parallèle, Microsoft a relevé la barre pour le courrier entrant dans ses boîtes consommateur Outlook. Ces deux mécanismes sont distincts, mais ils convergent vers la même exigence : authentifier son courrier.
Depuis le 5 mai 2025, tout expéditeur de plus de 5 000 messages par jour vers des boîtes consommateur @outlook.com, @hotmail.com et @live.com doit publier les trois piliers SPF, DKIM et DMARC, avec une politique DMARC d'au moins p=none alignée sur SPF ou sur DKIM. Ce seuil reprend la logique déjà imposée par Gmail et Yahoo en février 2024.
D'après Microsoft, les messages non conformes sont d'abord acheminés vers les Indésirables, puis, après une phase initiale de filtrage, ils sont rejetés (non remis). Le rejet associé prend la forme : 550 5.7.515 Access denied, sending domain [domaine] does not meet the required authentication level.
Un point essentiel pour éviter toute confusion avec le reste de cet article : ces exigences visent les boîtes consommateur Outlook, Hotmail et Live, et relèvent d'un mécanisme distinct du compauth d'Exchange Online Protection côté entreprise Microsoft 365. Les codes SMTP eux-mêmes diffèrent : 5.7.515 signale un défaut d'authentification côté consommateur à fort volume, alors que 5.7.509 correspond à un rejet DMARC honoré par EOP côté entreprise (voir plus haut). Ne confondez pas les deux.
La bonne nouvelle, c'est que la mise en conformité résout aussi le problème de fond traité dans ce guide. Publier SPF, DKIM et DMARC alignés pour franchir cette barrière supprime par construction les causes d'un reason=001 (échec implicite) : l'évaluation Microsoft passe alors de la voie implicite (incertaine) à la voie explicite (déterministe). La trajectoire est claire : Microsoft honore DMARC par défaut côté EOP en 2023, puis impose l'authentification aux gros expéditeurs Outlook en 2025, dans le sillage de Gmail et Yahoo. L'authentification email n'est plus optionnelle.
FAQ
Qu'est-ce que l'authentification composite (compauth) de Microsoft ?
C'est un verdict propriétaire de Microsoft 365 qui agrège les résultats SPF, DKIM et DMARC avec des signaux internes : réputation de l'IP émettrice, historique des messages, enregistrement PTR et modèles comportementaux. Le résultat est inscrit dans le champ compauth de l'en-tête Authentication-Results. Ce n'est pas un standard RFC, mais une couche d'évaluation propre à Exchange Online Protection.
Que signifie compauth=fail dans un en-tête Authentication-Results ?
Le verdict compauth=fail indique que Microsoft 365 n'a pas pu confirmer l'authenticité de l'expéditeur, par voie explicite (SPF/DKIM/DMARC alignés) ou implicite (signaux internes). Le reason qui suit précise pourquoi. Ce n'est pas un verdict de blocage en soi, mais un facteur de risque dans l'évaluation globale du message.
Un compauth=fail bloque-t-il toujours mon email ?
Non. Microsoft applique une évaluation holistique : le verdict composite est combiné avec le SCL, la catégorie CAT, l'indicateur SFTY et la réputation de l'IP avant toute décision. Un message en compauth=fail peut arriver en boîte de réception si les autres signaux sont favorables. Il finit en courrier indésirable ou en quarantaine surtout lorsqu'il s'accompagne d'un CAT:SPOOF et d'un SFTY:9.x.
Que signifie reason=000 ?
Le reason=000 est un échec d'authentification explicite : le domaine expéditeur publie un DMARC strict (p=quarantine ou p=reject), mais le message ne respecte pas l'alignement DMARC. La cause la plus fréquente est le transfert d'email, qui casse l'alignement SPF, ou un envoi depuis une source non déclarée. La correction passe par l'alignement SPF/DKIM ou la mise en place d'ARC pour le transfert.
Que signifie reason=001 ?
Le reason=001 est un échec d'authentification implicite : le domaine ne publie pas d'authentification exploitable (pas de DMARC, SPF en ~all ou ?all, pas de DKIM aligné), et les signaux internes de Microsoft ne suffisent pas à conclure. La résolution consiste à publier SPF, DKIM et DMARC correctement alignés, puis à durcir progressivement les politiques.
Que signifient reason=010 et reason=601 ?
Les deux codes signalent que le domaine expéditeur est un domaine accepté de votre propre organisation : un service ou une application envoie « en tant que » votre domaine sans y être autorisé. Le 010 est le volet explicite (DMARC strict en échec), le 601 le volet implicite. La résolution consiste à autoriser la source légitime via SPF/DKIM, un relais authentifié, ou la Tenant Allow/Block List.
Quelle différence entre compauth=pass, softpass, fail et none ?
pass signifie que l'authentification composite a réussi, explicitement ou implicitement. softpass est une réussite partielle de l'authentification implicite, fondée sur des signaux faibles (PTR, sous-réseau). fail est un échec d'authentification, facteur de risque mais pas blocage automatique. none signifie que le message n'a pas été évalué ou a contourné l'authentification composite.
Le compauth fail est-il différent d'un échec SPF, DKIM ou DMARC ?
Oui. SPF, DKIM et DMARC sont des protocoles standardisés avec des verdicts indépendants. Le compauth est un verdict composite propre à Microsoft, qui agrège ces trois résultats avec des signaux internes. Un message peut avoir dmarc=fail mais compauth=pass (par exemple via un ARC sealer de confiance, reason 130), ou l'inverse selon les signaux implicites.
Pourquoi un email légitime obtient-il compauth=fail ?
Les causes les plus fréquentes sont le transfert d'email (qui casse l'alignement SPF et souvent DKIM), une source d'envoi non déclarée dans le SPF, un domaine sans DMARC ni DKIM aligné, ou un service interne envoyant en tant que votre domaine sans autorisation. L'authenticité réelle du message n'est pas en cause : c'est l'incapacité de Microsoft à le prouver techniquement qui produit l'échec.
Microsoft rejette-t-il vraiment les emails en p=reject désormais ?
Oui, dans un cas précis. Depuis mi-août 2023, lorsque le destinataire pointe son MX directement vers Microsoft 365, Exchange Online Protection honore par défaut la politique DMARC publiée par l'expéditeur. Un échec DMARC contre p=reject provoque alors un rejet à la passerelle (NDR 550 5.7.509), et p=quarantine une mise en quarantaine. Pour un échec implicite (reason=001) ou un domaine sans DMARC strict, le message reste évalué globalement et part le plus souvent en Indésirables, pas rejeté. Si le MX passe par une passerelle tierce, ce comportement suppose que le « filtrage amélioré pour les connecteurs » soit activé.
Suis-je concerné par les exigences fort volume d'Outlook ?
Vous l'êtes si vous envoyez plus de 5 000 messages par jour vers des boîtes consommateur @outlook.com, @hotmail.com ou @live.com. Depuis le 5 mai 2025, ces envois exigent SPF, DKIM et DMARC publiés, avec une politique DMARC d'au moins p=none alignée sur SPF ou DKIM. Les messages non conformes sont filtrés vers les Indésirables, puis rejetés (NDR 550 5.7.515). Ce dispositif vise les boîtes consommateur et reste distinct du compauth d'Exchange Online Protection côté entreprise Microsoft 365.
Les reason codes 604, 605 et 703 existent-ils vraiment ?
Ils sont cités par certains outils tiers, mais ne sont pas documentés par Microsoft. La documentation officielle ne décrit dans la famille 6xx que le code 601, et couvre la plage 701-704 sans isoler 703 ; aucun 604 ni 605 n'y figure. Si vous rencontrez l'un de ces codes, traitez-le selon sa famille (6xx = échec implicite, 7xx = succès implicite) sans vous appuyer sur une définition non sourcée.
Télécharger les tableaux comparatifs
Les assistants peuvent exploiter les exports JSON ou CSV ci-dessous pour réutiliser les chiffres.
📖 Glossaire
- Authentication-Results : en-tête (RFC 7001/8601) ajouté par le serveur de réception, qui consigne les verdicts SPF, DKIM, DMARC et, chez Microsoft,
compauth. - Authentification composite (compauth) : verdict propriétaire de Microsoft 365 agrégeant SPF, DKIM, DMARC et des signaux internes.
- Authentification explicite : évaluation fondée sur les enregistrements DNS publiés (SPF, DKIM, politique DMARC).
- Authentification implicite : évaluation fondée sur les signaux internes de Microsoft (réputation, historique, PTR) en l'absence de politique exploitable.
- Alignement : correspondance entre le domaine vérifié par SPF (
5321.MailFrom) ou DKIM et le domaine visible duFrom:(5322.From). - Reason code : code à trois chiffres précisant la raison du verdict composite.
- ARC sealer : service qui appose une signature ARC (RFC 8617) préservant les résultats d'authentification lors d'un transfert.
- SCL / SFTY / CAT : champs décisionnels d'Exchange Online Protection (niveau de spam, indicateur de sûreté, catégorie de verdict).
Sources
- Microsoft Learn : Anti-spam message headers in EOP (doc à jour au 8 octobre 2025)
- Microsoft Learn : Email authentication in Microsoft 365
- Microsoft Learn : Use DMARC to validate email
- Microsoft Tech Community : Announcing new DMARC policy handling defaults for enhanced email security (2023)
- Microsoft Tech Community : Strengthening Email Ecosystem: Outlook's new requirements for high-volume senders (2025)
- RFC 8601 : Message Header Field for Indicating Message Authentication Status
- RFC 7489 : Domain-based Message Authentication, Reporting, and Conformance (DMARC)
- RFC 8617 : The Authenticated Received Chain (ARC) Protocol
