Test de conformité DMARC Microsoft
Testez SPF, DMARC et les sélecteurs DKIM courants pour Outlook.com. Confirmez par un vrai e-mail test.
Que vérifie le test de conformité Microsoft ?
Ce test lit les SPF et DMARC publics et les sélecteurs DKIM courants. Prenez-le comme base DNS, puis testez un e-mail de la plateforme concernée pour l’alignement SPF, DKIM et DMARC. Les seuls enregistrements publiés ne prouvent pas l’acceptation par Outlook.com.
Exigences vérifiées le 28 septembre 2026 d’après le guide 550 5.7.515 de Microsoft. Pour diagnostiquer un e-mail, suivez le guide de réparation 550.
Base de connaissances e-mail
Ce test prouve-t-il la conformité Microsoft ?
Le test de conformité Microsoft lit les SPF et DMARC publics et sonde les sélecteurs DKIM courants. Il ne peut établir qu’un e-mail réel passe SPF, DKIM ou l’alignement DMARC. Testez un e-mail par la même plateforme d’envoi et lisez ses résultats d’authentification.
Qui doit respecter les exigences d’Outlook.com ?
Microsoft documente 550 5.7.515 pour les domaines envoyant 5 000 e-mails ou plus par jour à ses services grand public (Outlook.com, Hotmail, Live.com, MSN) avec le même domaine From visible. Ce n’est pas un diagnostic général des rejets de tenants Microsoft 365.
SPF a-t-il besoin d’un include ?
Non. Un SPF peut autoriser directement des IP d’envoi. La vraie question n’est pas de savoir si le SPF contient include:, mais si la source réelle du message est autorisée par son domaine Return-Path.
Un DKIM non confirmé veut-il dire signature désactivée ?
Non. Ce test sonde les sélecteurs courants ; une plateforme peut en utiliser un autre. Trouvez-le dans l’en-tête DKIM-Signature du message ou les réglages du fournisseur, puis lisez ce sélecteur exact et vérifiez un nouvel e-mail.
Dois-je passer DMARC en p=reject ?
Microsoft accepte une politique p=none, p=quarantine ou p=reject valide pour cette exigence. SPF et DKIM doivent passer sur le message, et au moins un identifiant qui passe doit s’aligner sur le From visible pour que DMARC passe. Durcir la politique ne répare pas l’authentification.
Comment analyser les résultats avec Palisade MCP ?
Copiez le prompt MCP préparé du résultat et connectez Palisade à votre assistant. Il contient le domaine testé et les constats DNS. Palisade peut lire les rapports et tâches liés, proposer un correctif à relire et vérifier le DNS après publication approuvée. La publication DNS externe passe par un accès fournisseur approuvé ou le déploiement DNS de l’app. Retestez ensuite le flux d’envoi réel.
Les règles de Microsoft reposent sur DMARC. Voici les balises DMARC à connaître.
- vVersion
- La balise Version est indispensable dans un DMARC et doit valoir strictement « DMARC1 ». Si la valeur est incorrecte ou la balise absente, l’enregistrement DMARC n’est pas valide et il est ignoré.
- pPolitique DMARC
- La balise de politique DMARC accepte trois valeurs pour le courrier qui échoue : none ne demande aucune application, quarantine un traitement suspect, reject le rejet. Les destinataires décident en dernier et peuvent filtrer ou rejeter via d’autres contrôles en p=none. Les rapports agrégés se demandent à part, via la balise rua.
- ruaDestination des rapports agrégés
- La destination des rapports agrégés est une URI « mailto: », que les fournisseurs de messagerie (ESP) utilisent pour envoyer les rapports agrégés. La balise n’est pas obligatoire, mais sans elle vous ne recevez aucun rapport.
- rufDestination forensique
- La destination des rapports forensiques (d’échec) est une URI « mailto: », que les fournisseurs de messagerie (ESP) utilisent pour livrer les rapports d’échec. La balise n’est pas obligatoire, mais sans elle vous ne recevez aucun rapport.
- spSous-domaines
- Par défaut, la politique des sous-domaines hérite de la balise de politique du domaine principal (p=), décrite plus haut, sauf mention contraire. Comme pour le domaine, les valeurs possibles sont « none », « quarantine » ou « reject ». Cette option reste toutefois peu utilisée en pratique.
- adkimAlignement DKIM
- Cette balise fixe l’alignement de la signature DKIM, c’est-à-dire la correspondance entre le domaine DKIM et le domaine d’origine du « Header From ». Valeurs possibles : « r » (relaxed) et « s » (strict). Par défaut, « r » accepte une correspondance partielle entre ces domaines, tandis que « s » exige qu’ils soient identiques.
- aspfAlignement SPF
- Cette balise fixe l’alignement SPF, c’est-à-dire la compatibilité entre le domaine SPF (l’expéditeur) et le domaine du « Header From ». Deux valeurs : « r » (relaxed) et « s » (strict). Par défaut, « r » tolère une correspondance partielle entre les domaines. À l’inverse, « s » exige une correspondance exacte des domaines.
- foOptions forensiques
- Les options des rapports forensiques sont « 0 », « 1 », « d » et « s ». Par défaut, « 0 » déclenche un rapport seulement quand les alignements SPF et DKIM échouent tous deux. « 1 » en déclenche un dès que SPF ou DKIM ne passe pas. « d » produit un rapport pour les échecs de validation DKIM, « s » pour les problèmes SPF. Pour recevoir ces rapports forensiques, il faut renseigner la balise « ruf ».
- rfFormat des rapports
- Le format des rapports d’échec peut valoir « afrf » ou « iodef », les deux seules options autorisées.
- pctPourcentage (historique)
- L’ancienne balise Pourcentage demandait d’appliquer quarantine ou reject à une partie seulement du courrier en échec DMARC. La RFC 9989 a retiré pct, l’application partielle étant mise en œuvre de façon inégale. Les nouveaux enregistrements l’omettent et échelonnent via les rapports agrégés, des politiques entières et des sous-domaines à faible volume.
- riFréquence des rapports
- L’intervalle des rapports indique, en secondes, la fréquence des rapports XML. La valeur standard est 86400 secondes, soit un rapport par jour. Notez toutefois que, quel que soit l’intervalle indiqué, les fournisseurs d’accès (FAI) envoient en général ces rapports selon leur propre calendrier, le plus souvent une fois par jour également.