Configurer SPF, DKIM et DMARC sur Microsoft 365 (guide PME)

N'importe qui avec une connexion Internet peut envoyer un courriel qui prétend provenir de votre domaine. Pas de mot de passe requis, pas de piratage. Le protocole qui achemine le courriel date des années 1980 et accepte l'adresse d'expéditeur qu'on lui donne. C'est exactement ce que corrige le trio SPF, DKIM et DMARC. Ce guide vous montre comment configurer DMARC sur Microsoft 365, avec SPF et DKIM, pour que les serveurs destinataires puissent vérifier qu'un message signé contoso.com a bel et bien quitté un serveur autorisé.

Pour une PME, les enjeux sont concrets. Des fraudeurs envoient de fausses factures à vos clients avec votre domaine exact. Des fournisseurs reçoivent de « nouvelles coordonnées bancaires » qui semblent venir de votre comptabilité. Et depuis que Google et Yahoo ont resserré leurs exigences en 2024, le courriel non authentifié aboutit de plus en plus dans les indésirables, même légitime.

La bonne nouvelle : la configuration initiale tient en un après-midi, et le déploiement complet prend environ un mois. Ce tutoriel détaille chaque étape avec les chemins exacts du portail et les enregistrements DNS, avec contoso.com comme domaine d'exemple.

Points clés à retenir

• SPF, DKIM et DMARC permettent aux serveurs destinataires de vérifier le courriel envoyé au nom de votre domaine.
• Microsoft 365 exige un enregistrement TXT pour SPF et deux CNAME pour DKIM dans votre DNS public.
• Commencez toujours DMARC en mode p=none, lisez les rapports, puis passez à quarantine et reject.
• Google et Yahoo exigent l'authentification des expéditeurs de masse : votre délivrabilité en dépend.
• Un déploiement sur quatre semaines mène la plupart des PME à p=reject sans bloquer le courriel légitime.

Pourquoi l'usurpation de courriel coûte cher

L'usurpation de courriel est la matière première de la fraude d'affaires. Le scénario classique : un fraudeur identifie vos clients, puis leur envoie une facture depuis facturation@contoso.com avec un seul changement, les coordonnées bancaires. Le client paie. Vous le découvrez des semaines plus tard, l'argent est déjà parti. Votre entreprise n'a rien fait de mal, mais le courriel portait votre nom.

L'atteinte à la réputation aggrave les pertes directes. Quand une vague d'hameçonnage part sous votre domaine, les destinataires la signalent et les filtres apprennent à se méfier de votre nom. Une partie de votre courriel légitime tombe alors dans les indésirables, précisément chez les clients que vous devez joindre.

Ensuite, la délivrabilité. Depuis 2024, Google et Yahoo exigent SPF ou DKIM de tous les expéditeurs et un DMARC complet des expéditeurs de masse, et Microsoft a annoncé des exigences semblables pour les boîtes outlook.com en 2025. Un domaine non authentifié se bat donc pour la boîte de réception avec une main dans le dos : soumissions et factures glissent vers les indésirables, et personne ne vous avise.

Le côté réception est couvert dans notre guide visuel pour repérer les courriels d'hameçonnage. Ce tutoriel traite de l'autre direction : empêcher qu'on envoie du courriel convaincant en votre nom.

Comment SPF, DKIM et DMARC protègent votre domaine Microsoft 365

Chaque norme répond à une question différente; il vous faut les trois.

SPF (Sender Policy Framework) est une liste d'invités. Vous publiez un enregistrement DNS qui nomme les serveurs autorisés à envoyer pour votre domaine, et les destinataires comparent le serveur émetteur à cette liste. Simple, mais fragile : SPF se brise au réacheminement et ne dit pas quoi faire en cas d'échec.

DKIM (DomainKeys Identified Mail) est un sceau inviolable. Microsoft 365 signe chaque message sortant avec une clé privée; les destinataires vérifient la signature avec la clé publique publiée dans votre DNS. Elle survit au réacheminement et prouve que le message n'a pas été modifié en route.

DMARC (Domain-based Message Authentication, Reporting and Conformance) est la couche de politique qui relie le tout. Il indique aux destinataires quoi faire quand un message échoue aux deux vérifications (livrer, mettre en quarantaine ou rejeter), et il vous envoie des rapports listant chaque serveur qui prétend expédier au nom de votre domaine. DMARC impose aussi l'alignement : le domaine que vos destinataires voient dans le champ De doit correspondre au domaine qui a réussi SPF ou DKIM, c'est ce qui bloque l'usurpation.

Ces enregistrements protègent votre domaine, pas vos comptes d'utilisateurs. La protection des connexions est un chantier distinct, couvert par notre base d'accès conditionnel gratuite.

Étape 1 : publier votre enregistrement SPF

SPF tient dans un seul enregistrement TXT à la racine de votre domaine. La démarche :

1. Inventoriez vos expéditeurs. Listez chaque service qui envoie du courriel au nom de votre domaine : Microsoft 365, plateforme marketing, CRM ou PSA, formulaires web, imprimantes en numérisation vers courriel, outils de surveillance. Si vous en oubliez un, les rapports DMARC de l'étape 3 attraperont les retardataires.
2. Construisez l'enregistrement. Si tout passe par Microsoft 365, il reste court :

contoso.com    TXT    "v=spf1 include:spf.protection.outlook.com -all"

1. Ajoutez les services tiers avec la valeur include de leur documentation, par exemple une plateforme marketing :

contoso.com    TXT    "v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net -all"

1. Publiez-le chez votre hébergeur DNS, le registraire ou le fournisseur qui gère votre zone. Un seul enregistrement SPF par domaine, jamais deux. S'il en existe déjà un, fusionnez les nouveaux includes dedans.
2. Vérifiez. Lancez nslookup -type=txt contoso.com dans un terminal ou utilisez un vérificateur SPF gratuit, et confirmez que l'enregistrement se résout tel que publié.

Deux détails à retenir. Le -all final signifie « rejetez tout ce qui n'est pas sur cette liste »; le ~all, plus permissif, reste acceptable les premières semaines. Et SPF tolère un maximum de 10 recherches DNS par vérification, alors évitez les includes inutiles.

Étape 2 : activer DKIM dans Defender pour Office 365

Microsoft 365 signe automatiquement votre domaine onmicrosoft.com, mais votre domaine personnalisé doit être activé à la main.

1. Connectez-vous au portail Microsoft Defender à security.microsoft.com.
2. Rendez-vous dans Email & collaboration > Policies & rules > Threat policies > Email authentication settings (libellés anglais du portail).
3. Ouvrez l'onglet DKIM et sélectionnez votre domaine personnalisé, contoso.com dans notre exemple.
4. Activez Sign messages for this domain with DKIM signatures. Si les enregistrements DNS manquent, le portail affiche une erreur contenant les deux valeurs CNAME requises. Copiez-les.
5. Créez les deux CNAME chez votre hébergeur DNS, sur ce modèle, avec le nom de votre tenant à la place de contoso :

selector1._domainkey.contoso.com    CNAME    selector1-contoso-com._domainkey.contoso.onmicrosoft.com
selector2._domainkey.contoso.com    CNAME    selector2-contoso-com._domainkey.contoso.onmicrosoft.com

1. Attendez la propagation DNS, de quelques minutes à quelques heures, puis revenez au portail et réactivez le bouton.
2. Testez. Envoyez un message vers une boîte externe (un compte Gmail par exemple), ouvrez les en-têtes du message et cherchez dkim=pass avec votre domaine dans la signature.

Les deux sélecteurs permettent à Microsoft de faire la rotation des clés sans interrompre le courriel. Laissez les deux CNAME en place en permanence et utilisez le bouton Rotate DKIM keys une fois par année.

Étape 3 : configurer DMARC, de la surveillance au rejet

DMARC ajoute un dernier enregistrement TXT, publié à _dmarc.contoso.com. Version de départ :

_dmarc.contoso.com    TXT    "v=DMARC1; p=none; rua=mailto:dmarc@contoso.com; fo=1"

Le sens des balises :

• p=none demande aux destinataires de livrer le courriel normalement même en cas d'échec, tout en vous envoyant des rapports. C'est le mode surveillance.
• rua=mailto: indique où livrer les rapports agrégés. Créez une boîte ou un alias dédié, le volume grimpe vite.
• fo=1 demande un rapport d'échec dès que SPF ou DKIM échoue, pour plus de détails de diagnostic.
• Plus tard, vous passerez p à quarantine (livraison dans les indésirables) puis à reject (refus de livraison). La balise facultative pct applique la politique à un pourcentage du courriel.

Ne commencez jamais à p=reject. Vous découvrirez presque à coup sûr des expéditeurs légitimes oubliés, dont le courriel disparaîtrait en silence.

Le plan de déploiement sur quatre semaines

• Semaine 1, surveillance. Publiez l'enregistrement avec p=none. Confirmez que les rapports arrivent en un jour ou deux. Rien ne change pour vos utilisateurs.
• Semaine 2, corrections. Ajoutez les services manquants à SPF et activez DKIM sur les plateformes tierces; la plupart des outils marketing et CRM offrent une page d'authentification de domaine. Repérez les sources qui ne sont pas les vôtres.
• Semaine 3, quarantaine. Passez à p=quarantine, au besoin avec pct=25 au départ. Le courriel en échec aboutit dans les indésirables plutôt que dans la boîte de réception : une erreur de bonne foi reste récupérable.
• Semaine 4, rejet. Quand les rapports montrent vos sources légitimes conformes et alignées, passez à p=reject. Le courriel qui usurpe votre domaine est désormais refusé net.

Gardez la boîte de surveillance active ensuite : chaque nouvel outil adopté par votre équipe est un expéditeur potentiel, et c'est par les rapports que vous le remarquerez.

Lire les rapports DMARC sans y perdre son latin

Les rapports agrégés arrivent en pièces jointes XML, environ un par fournisseur par jour. Ils listent chaque adresse IP qui a envoyé du courriel avec votre domaine, les volumes, et si SPF et DKIM ont réussi et sont alignés. Le XML brut étant pénible à lire, la plupart des équipes l'envoient vers un service d'analyse DMARC (plusieurs offrent un palier gratuit pour un domaine) et consultent des tableaux de bord.

Trois motifs à surveiller :

• Un service légitime qui échoue à l'alignement. Votre plateforme marketing affiche un gros volume avec des échecs DKIM : activez sa fonction d'authentification de domaine ou ajoutez son include à SPF.
• Les réacheminements. Les listes de diffusion et le réacheminement automatique brisent souvent SPF alors que DKIM tient bon. C'est attendu et sans conséquence : DMARC accepte que l'une ou l'autre vérification s'aligne.
• Les sources inconnues. Des serveurs dans des pays où vous n'avez jamais fait affaire, qui envoient des milliers de messages au nom de contoso.com. C'est l'usurpation que DMARC existe pour stopper. À p=reject, ces messages meurent à la porte.

Bénéfice secondaire : les rapports révèlent les TI fantômes. Un département abonné en douce à son propre outil d'envoi apparaîtra dans les données en quelques jours. Et si vous préférez ne pas surveiller des fichiers XML, nos services TI gérés incluent la surveillance DMARC dans la trousse de sécurité standard.

FAQ

Microsoft 365 configure-t-il SPF, DKIM et DMARC automatiquement?

En partie seulement. Votre adresse onmicrosoft.com est signée DKIM d'office, mais pas vos domaines personnalisés. SPF exige un enregistrement TXT que vous publiez vous-même à l'ajout de votre domaine, et DMARC n'est jamais créé automatiquement. Présumez que rien n'est appliqué tant que vous n'avez pas vérifié votre DNS.

DMARC va-t-il bloquer mon infolettre ou mes courriels CRM?

Pas si vous respectez la phase de surveillance. Commencez à p=none et les rapports montreront quelles plateformes échouent à l'authentification. Presque tous les outils marketing et CRM sérieux offrent une page d'authentification de domaine où ajouter leurs enregistrements DKIM; corrigez cela avant la quarantaine et le courriel légitime continuera de circuler.

Combien de temps faut-il pour atteindre p=reject sans risque?

Comptez environ quatre semaines pour une PME : une à deux semaines à p=none, une semaine en quarantaine, puis le rejet quand les rapports sont propres. Une organisation qui n'envoie que par Microsoft 365 peut aller plus vite; une entreprise avec beaucoup d'expéditeurs tiers devrait prolonger la quarantaine.

Quelle est la différence entre p=quarantine et p=reject?

Quarantine demande aux serveurs destinataires de livrer le courriel en échec dans les indésirables, donc une erreur reste récupérable par le destinataire. Reject refuse carrément la livraison et le message n'atteint personne. La quarantaine est le filet de sécurité; le rejet est la destination, parce qu'une fausse facture dans les indésirables peut encore être cliquée.

Ai-je encore besoin de DMARC si j'ai déjà un filtre antipourriel?

Oui, parce qu'ils règlent des problèmes opposés. Le filtre antipourriel protège le courriel qui entre chez vous. DMARC protège ceux qui reçoivent du courriel prétendant venir de votre domaine : clients, fournisseurs, partenaires. Il améliore aussi la délivrabilité de votre courriel sortant, ce qu'aucun filtre entrant ne peut faire.

La plupart des tenants que nous évaluons ont un enregistrement SPF et rien d'autre, ce qui laisse la porte à moitié ouverte. Deux courtes sessions DNS et un mois de lecture de rapports suffisent à la fermer pour de bon. Si vous préférez confier le tout, nous configurons et surveillons l'authentification courriel via nos services de cybersécurité, et une évaluation TI rapide vous dira où votre domaine se situe aujourd'hui.