SPF, DKIM et DMARC pour Microsoft 365 : la configuration complète, domaine par domaine
Un domaine sans DMARC appliqué peut être usurpé par n'importe qui, et vos partenaires n'ont aucun moyen de le savoir. La configuration n'est pas complexe, mais elle doit être menée dans l'ordre et sur tous vos domaines, y compris ceux qui n'envoient jamais de courrier.
Trois mécanismes complémentaires
SPF déclare les serveurs autorisés à envoyer pour un domaine. DKIM signe chaque message avec une clé dont la partie publique est publiée dans le DNS. DMARC exige que l'un des deux soit valide et aligné sur le domaine visible dans le champ « De », indique au destinataire quoi faire en cas d'échec et vous renvoie des rapports. Aucun des trois ne suffit seul.
SPF : un seul enregistrement, complet
Pour un domaine qui n'envoie que via Exchange Online :
contoso.com. TXT "v=spf1 include:spf.protection.outlook.com -all"
Ajoutez les autres émetteurs légitimes (outil de marketing, application métier, relais d'imprimantes), en respectant la limite de dix recherches DNS de SPF. Un domaine ne doit porter qu'un seul enregistrement SPF ; deux enregistrements rendent le résultat invalide. Terminer par -all ou ~all fait débat ; avec DMARC appliqué, l'important est surtout que la liste soit exhaustive.
DKIM : activer les sélecteurs
Le domaine initial en onmicrosoft.com est signé par défaut, mais vos domaines personnalisés ne le sont pas tant que DKIM n'est pas activé pour eux. Dans le portail Defender (Stratégies de messagerie > DKIM), chaque domaine affiche deux enregistrements CNAME, selector1._domainkey et selector2._domainkey, à publier dans votre DNS avant d'activer la signature. Copiez les valeurs exactes affichées par le portail : leur format a évolué et diffère selon l'ancienneté du domaine. La rotation des clés s'effectue ensuite depuis le même écran.
DMARC : une progression maîtrisée
- p=none avec rapports agrégés : observation, sans impact sur la distribution ;
- analyse des rapports pendant plusieurs semaines pour identifier tous les émetteurs légitimes et corriger leur alignement ;
- p=quarantine, éventuellement avec
pctpour une montée progressive ; - p=reject une fois les rapports propres.
_dmarc.contoso.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@contoso.com"
Les rapports agrégés sont des fichiers XML difficiles à lire en volume : un service ou un outil d'analyse DMARC fait gagner beaucoup de temps.
Erreur fréquente. Rester indéfiniment en p=none. Cette valeur ne protège personne : elle sert uniquement à préparer l'application de la politique.
Les domaines parqués
Les domaines enregistrés mais inutilisés (anciennes marques, variantes, domaines défensifs) sont des cibles de choix, car personne ne surveille leur usage. Publiez pour chacun :
parked.example. TXT "v=spf1 -all" _dmarc.parked.example. TXT "v=DMARC1; p=reject" parked.example. MX 0 .
Le dernier enregistrement est un « null MX », qui indique que le domaine ne reçoit pas de courrier.
Les exigences des grands fournisseurs de messagerie
Depuis 2024, plusieurs grands fournisseurs de messagerie grand public ont durci leurs exigences envers les expéditeurs de gros volumes : authentification SPF et DKIM, publication d'une politique DMARC, désinscription simplifiée pour les envois commerciaux. Les seuils et modalités varient selon le fournisseur et évoluent ; vérifiez les conditions en vigueur si vous envoyez des volumes importants, notamment via des plateformes tierces qui signent pour votre domaine.
Ce qu'un audit vérifie
- un enregistrement SPF unique et valide sur chaque domaine accepté ;
- la signature DKIM activée pour tous les domaines personnalisés émetteurs ;
- une politique DMARC en quarantine ou reject, avec rapports exploités ;
- la protection des domaines parqués.