Configurer SPF et DKIM chez OVHcloud

SPF selon l'offre — et le piège de l'enregistrement par défaut

SPF répond à une question simple : quelles adresses IP ont le droit d'envoyer du courrier au nom du domaine ? La réponse tient dans un enregistrement TXT unique posé à la racine. Pour MX Plan, la valeur documentée tient en une ligne :

exemple.fr.  IN TXT  "v=spf1 include:mx.ovh.com ~all"

Le mécanisme include:mx.ovh.com autorise l'infrastructure d'envoi mutualisée d'OVHcloud, celle par laquelle transitent les messages des boîtes MX Plan et des scripts d'hébergement web. Pour Email Pro et Exchange, l'infrastructure d'envoi n'est pas la même et la valeur à inclure diffère : elle figure dans le guide OVHcloud propre à chaque offre, et c'est là qu'il faut la prendre plutôt que de recopier celle de MX Plan. Le principe stable, lui, ne change jamais : un seul TXT v=spf1, qui fusionne toutes les sources légitimes — l'offre OVHcloud, mais aussi le routeur marketing (Brevo, Mailchimp…), l'outil de facturation, le CRM. Chaque include consomme une partie du budget de dix résolutions DNS que la norme impose ; empiler sans compter mène au permerror.

Vient le piège maison. À la création d'une zone avec les enregistrements par défaut, OVHcloud dépose déjà un TXT SPF autorisant sa propre infrastructure. Ce défaut bienveillant a deux effets pervers. Premièrement, il survit aux migrations : un domaine dont le courrier vit désormais chez Microsoft 365 ou Google Workspace garde une autorisation ouverte vers l'infrastructure mutualisée d'OVHcloud — et du point de vue de SPF, toute machine de cette infrastructure partagée devient un expéditeur légitime du domaine. Deuxièmement, il nourrit le réflexe d'« ajouter » un nouvel enregistrement SPF plutôt que de modifier l'existant : deux TXT v=spf1 coexistent alors, et la norme est sans appel — le résultat est une erreur permanente, pas une fusion. La même question du défaut posé par le registrar se retrouve chez les autres acteurs du marché ; la configuration équivalente chez Gandi montre une mécanique différente pour un remède identique : une seule ligne, tenue à jour.

Reste le choix du qualificateur final. ~all (softfail) marque les sources non listées comme suspectes sans exiger leur rejet ; -all (fail) demande le rejet pur. Pendant la phase d'inventaire, ~all est le choix prudent ; une fois DMARC en place, c'est de toute façon la politique DMARC qui décide du sort des messages non alignés, et le durcissement de SPF devient un raffinement plus qu'une nécessité.

DKIM : sélecteurs CNAME et activation par l'espace client ou l'API

DKIM ajoute au message une signature cryptographique, vérifiée par le destinataire grâce à une clé publique publiée dans le DNS sous un nom de la forme <sélecteur>._domainkey.exemple.fr. Chez OVHcloud, pas de clé à copier-coller : l'activation crée deux sélecteurs sous forme d'enregistrements CNAME, qui pointent vers des cibles gérées par OVHcloud (des noms hébergés sous dkim.mail.ovh.net). L'intérêt de ce montage est réel : la clé publique reste chez OVHcloud, qui peut la faire tourner régulièrement sans aucune intervention sur la zone — les deux sélecteurs alternent, l'un signe pendant que l'autre attend la prochaine rotation.

L'activation dépend de l'offre. Pour Exchange et Email Pro, elle se pilote depuis l'espace client, dans la configuration du domaine associé au service, ou par l'API. Pour MX Plan, OVHcloud a largement automatisé l'activation sur les offres récentes, et l'API permet de la déclencher ou de la vérifier sur les domaines plus anciens. Les libellés exacts des boutons évoluant régulièrement, la procédure à jour est celle de la documentation OVHcloud — les mécanismes décrits ici (deux sélecteurs, CNAME, rotation gérée), eux, sont stables.

Un cas particulier mérite l'attention : quand la zone DNS n'est pas hébergée chez OVHcloud, les deux CNAME ne peuvent pas être posés automatiquement. Les valeurs à créer sont alors affichées dans l'espace client ou récupérables par l'API, et c'est chez l'hébergeur DNS réel qu'il faut les recopier, à l'identique. Un sélecteur mal orthographié produit une signature invérifiable — donc un échec DKIM silencieux.

Les erreurs vues en pratique

Trois familles d'erreurs reviennent sans cesse dans les rapports DMARC de domaines hébergés chez OVHcloud.

• Deux TXT v=spf1. La plus fréquente, née du SPF par défaut. Un récepteur qui trouve deux enregistrements SPF sur le même nom retourne une erreur permanente : le message ne peut plus passer SPF, quelle que soit la qualité des deux lignes. Le remède tient en une opération : fusionner, puis supprimer le doublon — le mode textuel de la zone rend le diagnostic immédiat.
• L'oubli post-migration. Courrier migré de MX Plan vers Microsoft 365, ou d'Exchange vers une autre plateforme : le SPF garde l'ancien include devenu inutile (voire dangereux, sur une infrastructure mutualisée), et DKIM signe encore avec les sélecteurs de l'ancienne offre — ou ne signe plus du tout, les CNAME ayant été supprimés avec le service. Les rapports DMARC révèlent ces fantômes en quelques jours : une source qui envoyait hier et n'envoie plus, une signature qui échoue depuis une date précise.
• Le TTL qui fausse les tests. Une correction publiée ne s'observe qu'après expiration des caches, soit jusqu'à une heure avec le TTL par défaut. Tester trente secondes après la modification, conclure à l'échec et « corriger » de nouveau mène à des zones incohérentes. La discipline utile : abaisser le TTL avant une migration planifiée, puis patienter un cycle complet avant tout verdict.

Vérifier avant de durcir

La vérification se fait à trois niveaux. D'abord le DNS brut : une interrogation TXT de la racine du domaine doit retourner un et un seul v=spf1 ; une interrogation des noms selector1._domainkey et selector2._domainkey doit suivre les CNAME jusqu'aux clés hébergées par OVHcloud. La méthode détaillée, outils et pièges compris, est déroulée dans le contrôle d'un enregistrement SPF.

Ensuite, le test grandeur nature : un message envoyé vers une boîte Gmail ou Outlook.com, puis la lecture de l'en-tête Authentication-Results du message reçu. Les mentions attendues : spf=pass, dkim=pass avec un sélecteur OVHcloud, et l'alignement des domaines. Enfin, l'observation dans la durée : la publication d'un enregistrement DMARC en mode surveillance permet de voir ce que les récepteurs du monde entier constatent réellement, semaine après semaine :

_dmarc.exemple.fr.  IN TXT  "v=DMARC1; p=none; rua=mailto:rapports-dmarc@exemple.fr"

Les exemples d'enregistrements DMARC donnent le modèle adapté à chaque situation — domaine actif, domaine de marque défensif, sous-domaines. C'est cette phase d'observation qui transforme une configuration « qui a l'air bonne » en configuration prouvée.

En résumé

Chez OVHcloud, SPF et DKIM se configurent vite dès lors que trois repères sont posés : l'offre e-mail réellement souscrite (MX Plan, Email Pro ou Exchange — chacune son infrastructure, sa valeur SPF, sa procédure DKIM), la zone DNS comme lieu unique de vérité (avec le mode textuel comme outil d'audit), et le piège du SPF par défaut, responsable de la plupart des doubles v=spf1 du terrain. DKIM s'active depuis l'espace client ou l'API, sous forme de deux sélecteurs CNAME dont OVHcloud gère la rotation ; les erreurs classiques — doublon SPF, oubli post-migration, TTL mal anticipé — se détectent toutes par une lecture attentive de la zone et des rapports.

Le point de départ le plus court reste une analyse DMARC gratuite du domaine : elle montre en quelques secondes l'état réel de SPF, DKIM et DMARC tels qu'un récepteur les voit, doublon compris. Une fois le diagnostic posé, la création d'un compte permet de collecter les rapports, de surveiller les deux sélecteurs OVHcloud dans la durée et de mener la politique vers p=reject sur des preuves plutôt que des suppositions.