SPF, DKIM et DMARC pour Microsoft 365.
Microsoft 365 (Exchange Online) n'authentifie pas votre domaine à l'aide d'un assistant unique, contrairement à un ESP hébergé — la tâche est répartie entre deux consoles. Le SPF est un véritable include partagé (include:spf.protection.outlook.com) que vous fusionnez dans l'unique enregistrement SPF TXT de votre domaine, et le DKIM correspond à deux enregistrements CNAME de « sélecteur » que vous publiez, puis activez dans le portail Microsoft Defender. Le DMARC est un troisième enregistrement, distinct, que Microsoft ne crée jamais à votre place. Alignez correctement ces trois éléments et Exchange Online envoie des messages entièrement authentifiés au nom de votre propre domaine, au lieu de s'appuyer sur la signature onmicrosoft.com par défaut.
Pourquoi authentifier Microsoft 365 ?
L'authentification d'un domaine Microsoft 365 détermine si votre courrier atteint la boîte de réception, et M365 comporte un piège spécifique qui casse discrètement le DMARC. Depuis février 2024, Gmail et Yahoo exigent que tout expéditeur en masse (environ 5 000 messages par jour ou plus) réussisse SPF, DKIM et DMARC avec alignement, et à partir de mai 2025, Microsoft a commencé à appliquer les mêmes règles au courrier à fort volume destiné à Outlook.com/Hotmail/Live — le courrier professionnel qui arrive dans les boîtes Microsoft grand public doit donc lui aussi être authentifié. Le piège propre à M365 : par défaut, Exchange Online signe en DKIM votre courrier sortant avec le domaine onmicrosoft.com du locataire (d=contoso.onmicrosoft.com), ce qui ne s'aligne pas avec votre domaine d'expéditeur (From) personnalisé (contoso.com). Le SPF de Microsoft, lui, s'aligne, si bien que le courrier direct peut décrocher une validation DMARC sur le seul SPF — mais dès qu'un message est transféré (listes de diffusion, règles .forward, passerelles de filtrage), le SPF casse, et comme le DKIM signe avec le mauvais domaine, il ne reste plus rien pour porter le DMARC. Configurer le DKIM sur domaine personnalisé, c'est ce qui comble cette faille et permet à la réputation d'envoi que vous bâtissez de bénéficier à votre propre domaine.
La réalité SPF pour Microsoft 365
Microsoft 365 est un véritable fournisseur « include » — contrairement aux ESP à délégation par CNAME (Mailchimp, Klaviyo) ou aux expéditeurs par compte (Amazon SES), il existe un seul véritable include partagé à ajouter à votre SPF racine : include:spf.protection.outlook.com. Publiez-le dans un unique enregistrement SPF TXT sur le domaine, par exemple v=spf1 include:spf.protection.outlook.com -all. Deux choses rendent le SPF de M365 particulièrement bien conçu. Premièrement, l'include se résout en un enregistrement plat qui ne contient que des plages ip4:/ip6: et son propre -all — sans include imbriqué — de sorte qu'il ne coûte qu'UNE seule de vos 10 recherches DNS SPF (un mythe répandu prétend 2 à 3 ; l'enregistrement réel ne comporte aucun sous-include). Deuxièmement, comme Exchange Online utilise votre propre domaine comme MAIL FROM SMTP (enveloppe/Return-Path) par défaut, le SPF S'ALIGNE réellement avec votre domaine, si bien que l'include M365 contribue à lui seul à une validation DMARC — ce que ne peuvent pas faire les ESP qui possèdent le Return-Path. Microsoft recommande explicitement le qualificateur -all (échec strict) car il s'attend aussi à ce que vous exploitiez DKIM et DMARC. Deux réserves : seuls les clouds souverains/gouvernementaux diffèrent — GCC High et DoD utilisent include:spf.protection.office365.us, et 21Vianet (Chine) utilise include:spf.protection.partner.outlook.cn ; et chaque sous-domaine expéditeur a besoin de son propre enregistrement SPF (l'enregistrement de contoso.com ne couvre pas marketing.contoso.com).
Étape par étape
- 1
Confirmez le domaine et repérez ses enregistrements DNS
Connectez-vous sur admin.microsoft.com, allez dans Paramètres → Domaines, sélectionnez votre domaine et ouvrez l'onglet des enregistrements DNS. Si vous avez délégué vos serveurs de noms à Microsoft, il a peut-être déjà publié le SPF et le MX (yourdomain-com.mail.protection.outlook.com). Si votre DNS est hébergé chez un bureau d'enregistrement/hébergeur, notez que M365 n'a ici aucun contrôle SPF ni DMARC — vous ajouterez ces enregistrements vous-même chez votre hébergeur DNS.
- 2
Publiez ou fusionnez l'enregistrement SPF
Chez votre hébergeur DNS, créez UN enregistrement TXT sur la racine (hôte @) : v=spf1 include:spf.protection.outlook.com -all. Si un enregistrement v=spf1 existe déjà (Google Workspace, un outil marketing, etc.), fusionnez l'include dans cet unique enregistrement — n'ajoutez jamais un second SPF TXT. Microsoft recommande de terminer par -all (échec strict). GCC High/DoD utilisent spf.protection.office365.us ; 21Vianet utilise spf.protection.partner.outlook.cn.
- 3
Ouvrez l'onglet DKIM
Le DKIM personnalisé N'EST PAS dans le centre d'administration M365. Allez sur security.microsoft.com → E-mail et collaboration → Stratégies et règles → Stratégies de menace → Paramètres d'authentification de messagerie, puis sélectionnez l'onglet DKIM.
- 4
Révélez les deux valeurs CNAME
Cliquez sur votre domaine personnalisé. Un domaine qui n'a jamais été configuré affiche Statut = NoDKIMKeys et l'interrupteur Désactivé. Faites glisser l'interrupteur sur Activer — comme les CNAME n'existent pas encore, une boîte de dialogue « Client error » s'ouvre et le Statut passe à CnameMissing. C'est attendu, ce n'est pas un échec : la section « Publier les CNAME » fait alors apparaître les cibles CNAME exactes de selector1 et selector2. Copiez-les (ou exécutez Get-DkimSigningConfig -Identity yourdomain.com | Format-List Selector1CNAME,Selector2CNAME dans Exchange Online PowerShell).
- 5
Ajoutez les deux CNAME de sélecteur DKIM
Créez selector1._domainkey et selector2._domainkey en tant qu'enregistrements CNAME pointant vers les cibles exactes fournies par le portail. Les domaines plus récents (le format introduit par Microsoft en mai 2025) obtiennent des cibles comme selector1-<domain-with-dashes>._domainkey.<tenant>.<char>-v1.dkim.mail.microsoft (le <char>, par ex. n ou r, est un caractère de partition attribué par Microsoft) ; les domaines configurés avant cette date obtiennent selector1-<domain-with-dashes>._domainkey.<tenant>.onmicrosoft.com. Utilisez le format affiché par le portail — les deux formats ne peuvent pas être mélangés sur un même sélecteur. Ne les transformez pas en TXT.
- 6
Basculez le DKIM sur Activé
Une fois les CNAME propagés (généralement quelques minutes, jusqu'à 48 heures), revenez à l'onglet DKIM, sélectionnez le domaine et faites de nouveau glisser l'interrupteur sur Activer. Le Statut passe à Valide et « Faire tourner les clés DKIM » devient disponible. Désormais, M365 signe avec d=yourdomain.com au lieu du domaine onmicrosoft.com par défaut, de sorte que le DKIM s'aligne.
- 7
Ajoutez l'enregistrement DMARC
M365 ne crée pas de DMARC. Ajoutez un enregistrement TXT à l'hôte _dmarc : v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Commencez à p=none — le mode de surveillance « n'entreprendre aucune action » de Microsoft — pour que rien ne soit affecté pendant que vous confirmez que SPF et DKIM s'alignent tous les deux, puis durcissez plus tard.
- 8
Envoyez un test et lisez les en-têtes
Depuis une boîte aux lettres du domaine, envoyez-vous un e-mail sur Gmail, ouvrez le message et choisissez ⋮ → Afficher l'original. Vous voulez SPF: PASS affichant votre domaine, DKIM: PASS avec d=yourdomain.com (PAS onmicrosoft.com), et DMARC: PASS. Confirmez ensuite que chaque enregistrement se résout à l'aide d'un contrôle de santé du domaine.
Enregistrements à ajouter
Microsoft 365 génère les valeurs exactes dans son assistant de configuration — celles-ci illustrent la forme de ce que vous ajouterez chez votre hébergeur DNS.
| Type | Hôte | Valeur |
|---|---|---|
| TXT | @ | v=spf1 include:spf.protection.outlook.com -allSPF racine — conservez exactement UN seul enregistrement SPF ; fusionnez cet include si vous avez déjà un enregistrement v=spf1. Coûte environ 1 recherche DNS. |
| CNAME | selector1._domainkey | selector1-contoso-com._domainkey.contoso.n-v1.dkim.mail.microsoftClé DKIM 1 (rotation automatique). À titre indicatif — copiez la cible exacte depuis le portail Defender ; les domaines créés avant mai 2025 se terminent par .onmicrosoft.com au lieu de .n-v1.dkim.mail.microsoft. |
| CNAME | selector2._domainkey | selector2-contoso-com._domainkey.contoso.n-v1.dkim.mail.microsoftClé DKIM 2 (le second sélecteur permet à Microsoft de faire tourner les clés). À titre indicatif — utilisez la valeur exacte du portail. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comVous l'ajoutez vous-même — M365 ne le crée jamais. Un seul par domaine ; commencez à p=none. |
| MX | @ | contoso-com.mail.protection.outlook.comAchemine le courrier entrant vers Exchange Online (priorité 0). Ce n'est pas un enregistrement d'authentification, mais il fait partie de la configuration M365 ; les points de votre domaine deviennent des traits d'union. |
Conservez exactement un seul enregistrement SPF (v=spf1) TXT sur votre domaine racine — fusionnez-y tous vos expéditeurs. Avoir deux enregistrements SPF constitue en soi une erreur.
Le budget de 10 requêtes DNS
SPF est plafonné à une limite stricte de 10 requêtes DNS — dépassez-la et il renvoie une permerror et cesse de valider partout. Voici ce que coûte la configuration de Microsoft 365 sur ce budget.
Microsoft 365 utilise 1 de vos 10 requêtes ; les mécanismes ip4: et ip6: sont gratuits.
DKIM
Le DKIM dans Microsoft 365, c'est la partie que les gens ratent, parce que M365 « signe déjà » le courrier avant même que vous ne fassiez quoi que ce soit — mais avec le mauvais domaine. Par défaut, Exchange Online signe en DKIM le courrier sortant en utilisant le domaine onmicrosoft.com initial de votre locataire (d=contoso.onmicrosoft.com). Cette signature est valide, mais elle ne s'aligne pas avec votre domaine d'expéditeur (From) personnalisé, donc elle n'apporte rien au DMARC pour contoso.com. Pour corriger cela, vous activez le DKIM sur domaine personnalisé : deux enregistrements CNAME, selector1._domainkey et selector2._domainkey, qui délèguent les clés publiques à Microsoft. Comme il s'agit de CNAME (et non d'enregistrements TXT à coller), Microsoft conserve les clés privées et utilise les deux sélecteurs pour faire tourner les clés automatiquement sans que vous n'ayez plus jamais à toucher au DNS. Le format cible a changé en mai 2025 : les domaines personnalisés plus récents obtiennent selector1-<domain-with-dashes>._domainkey.<tenant>.<char>-v1.dkim.mail.microsoft (le <char>, par ex. n ou r, est un caractère de partition attribué par Microsoft), tandis que les domaines configurés avant cette date utilisent encore selector1-<domain-with-dashes>._domainkey.<tenant>.onmicrosoft.com — le portail (ou Get-DkimSigningConfig dans Exchange Online PowerShell) indique exactement lequel est attribué à votre locataire, et les deux formats ne peuvent pas coexister pour un même sélecteur. Marche à suivre : révélez les CNAME dans le portail Defender (Paramètres d'authentification de messagerie → DKIM), publiez les deux chez votre hébergeur DNS, attendez la propagation, puis basculez l'interrupteur DKIM du domaine sur Activé pour que le Statut affiche Valide. Les clés sont de 1024 bits par défaut ; le 2048 bits est disponible via New-DkimSigningConfig (avec -KeySize 2048). Ce n'est qu'une fois l'interrupteur sur Activé que M365 signe avec d=yourdomain.com et que le DKIM commence à s'aligner.
DMARC
Le DMARC est un enregistrement TXT de politique distinct sur votre domaine, que Microsoft 365 ne crée pas — vous l'ajoutez chez votre hébergeur DNS. Publiez-le à l'adresse _dmarc.yourdomain.com en commençant par v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none est le mode de surveillance « n'entreprendre aucune action » recommandé par Microsoft : il ne change rien à la remise pendant que vous examinez les rapports agrégés (rua) pour confirmer que M365 (et tout autre expéditeur) réussit SPF et DKIM alignés avec votre domaine. Le propre conseil de Microsoft est de mettre en place rapidement la signature DKIM et le DMARC en mode surveillance, puis de durcir la politique — resserrer vers p=quarantine, puis p=reject, une fois l'alignement cohérent. Ne conservez qu'un seul enregistrement _dmarc pour l'ensemble du domaine organisationnel ; les sous-domaines héritent automatiquement de la politique parente (vous pouvez remplacer un sous-domaine spécifique avec son propre enregistrement _dmarc ou la balise sp=). Comme le SPF de M365 s'aligne et que, une fois le DKIM personnalisé configuré, le DKIM s'aligne aussi, un domaine M365 correctement configuré réussit le DMARC sur les deux mécanismes — la configuration robuste qui survit au transfert.
Vérifiez que tout fonctionne réellement
Ne vous fiez pas au seul badge « Valide » du portail Defender — confirmez-le sur un vrai message. Envoyez-vous un test depuis une boîte aux lettres du domaine, ouvrez-le dans Gmail et choisissez ⋮ → Afficher l'original : vous voulez SPF: PASS, DKIM: PASS avec d=yourdomain.com (le signe révélateur d'un échec est d=yourtenant.onmicrosoft.com, qui indique que le DKIM personnalisé n'est pas encore activé), et DMARC: PASS. Dans le portail Defender, l'onglet DKIM doit afficher Statut = Valide et Interrupteur = Activé pour le domaine. Ensuite, passez votre domaine dans le {healthCheck} de Qualisend pour confirmer que le SPF, les deux CNAME de sélecteur DKIM et l'enregistrement DMARC se résolvent tous proprement, et une fois que les rapports agrégés DMARC commencent à arriver, déposez-en un dans le {dmarcAnalyzer} — Outlook.com / Exchange Online devrait apparaître comme une source alignée et validée.
Pièges courants
- Couverture
Le piège n°1 de M365 : tant que vous n'activez pas le DKIM sur domaine personnalisé, le courrier est signé en d=yourtenant.onmicrosoft.com, ce qui ne s'aligne PAS — le DMARC ne reçoit donc aucune aide du DKIM et casse dès qu'un message est transféré. Le SPF seul ne suffit pas.
- Configuration DNS
La boîte de dialogue « Client error » / le statut CnameMissing que vous obtenez la première fois que vous faites glisser l'interrupteur DKIM sur Activer est attendu, ce n'est pas un bug — c'est ainsi que le portail révèle les valeurs CNAME. Publiez les deux CNAME, puis revenez et basculez de nouveau sur Activer.
- Configuration DNS
Les cibles CNAME du DKIM ont changé en mai 2025 : les domaines personnalisés configurés depuis pointent vers <tenant>.<char>-v1.dkim.mail.microsoft, les plus anciens vers <tenant>.onmicrosoft.com. Copiez la cible exacte depuis le portail Defender (ou Get-DkimSigningConfig) — les anciens et nouveaux formats ne peuvent pas être mélangés sur le même sélecteur.
- Casse l'authentification
Conservez exactement UN seul enregistrement SPF TXT sur le domaine. Si vous envoyez déjà via Google Workspace, SendGrid, etc., fusionnez include:spf.protection.outlook.com dans cet unique enregistrement — deux enregistrements SPF TXT constituent en soi un PermError.
- Couverture
Un M365 provisionné par GoDaddy ou IONOS livre souvent un SPF par défaut de include:secureserver.net, qui n'autorise PAS les boîtes aux lettres Exchange Online. Il doit se résoudre en include:spf.protection.outlook.com.
- Configuration DNS
Les enregistrements DKIM de M365 sont des CNAME ; donc si votre DNS est derrière Cloudflare, réglez chaque enregistrement de sélecteur sur « DNS only » (nuage gris) — un CNAME proxifié en nuage orange ne se résoudra pas vers l'hôte Microsoft et l'activation du DKIM échouera.
- Configuration DNS
Attention aux erreurs de syntaxe SPF que Microsoft signale : pas de point final (include:spf.protection.outlook.com. est incorrect), un deux-points et non un signe égal après « include », et pas d'espace après le deux-points. De nombreux bureaux d'enregistrement ajoutent aussi automatiquement votre domaine aux champs CNAME/hôte, ce qui le double.
- Couverture
Chaque sous-domaine expéditeur a besoin de son propre SPF (et de son propre DKIM). L'enregistrement sur contoso.com ne couvre pas marketing.contoso.com — les outils en masse/marketing qui envoient depuis un sous-domaine y ont besoin d'un SPF, d'un DKIM et généralement de leur propre gestion DMARC.
Construisez votre enregistrement SPF
Microsoft 365 est présélectionné ci-dessous. Ajoutez toutes les autres plateformes par lesquelles vous envoyez, puis publiez l'enregistrement fusionné unique.
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listSPF Microsoft 365 — FAQ
Lectures complémentaires
Une fois publié, confirmez que tout se résout correctement avec la vérification de l'état du domaine, puis identifiez qui envoie en votre nom grâce à l'analyseur de rapports DMARC. Parcourez toutes les sources d'envoi dans le générateur. L'authentification ne représente toutefois que la moitié de la délivrabilité — une IP ou un domaine d'envoi inscrit sur une liste vous fait toujours atterrir dans les spams, quelle que soit la propreté de votre SPF ; il vaut donc la peine de surveiller les listes noires avec la surveillance des listes noires.
Authentifié — maintenant, gardez votre liste propre
Réussir SPF, DKIM et DMARC vous mène jusqu'à la boîte de réception ; une liste propre vous y maintient. Vérifiez la vôtre — commencez gratuitement avec 100 crédits, sans carte bancaire.