Configurer SPF et DKIM chez Gandi

@ 10800 IN TXT "v=spf1 include:_mailcust.gandi.net ?all"

v=spf1 include:_mailcust.gandi.net include:spf.mailjet.com ~all

DKIM sur GandiMail : une activation, trois sélecteurs

SPF authentifie le serveur émetteur ; DKIM signe le message lui-même, et la signature survit aux transferts. Sur GandiMail, l'activation part de la section E-mail de l'administration du domaine — un bouton dédié déclenche tout ; le chemin exact dans l'interface évolue au fil des refontes, et la documentation Gandi reste la seule référence à jour sur ce point. Ce que produit l'activation, en revanche, est stable : trois enregistrements CNAME.

gm1._domainkey 10800 IN CNAME gm1.gandimail.net.
gm2._domainkey 10800 IN CNAME gm2.gandimail.net.
gm3._domainkey 10800 IN CNAME gm3.gandimail.net.

Si la zone est sur LiveDNS, ces trois lignes s'ajoutent automatiquement. Si le DNS est délégué ailleurs, il faut les créer à la main chez l'hébergeur de zone — mêmes noms, mêmes cibles. L'élégance du montage tient au CNAME : la clé publique reste hébergée chez Gandi, qui peut la renouveler sans que la zone du domaine bouge. Les trois sélecteurs gm1, gm2 et gm3 existent précisément pour cette rotation : pendant qu'une clé signe, la suivante se prépare. C'est un avantage opérationnel réel sur le TXT figé, collé une fois puis oublié pendant des années — la rotation des clés DKIM est une hygiène que peu d'équipes pratiquent quand elle reste manuelle.

Éditer la zone LiveDNS : interface, mode texte, API

LiveDNS offre trois portes d'entrée, et chacune a son piège. L'interface web présente la zone enregistrement par enregistrement : type, nom, TTL, valeur. Un TXT s'y ajoute en quelques clics, les guillemets sont gérés, et les chaînes dépassant 255 caractères — une clé DKIM 2048 bits, typiquement — sont découpées automatiquement. Le mode texte affiche la zone entière comme un fichier de zone : pratique pour coller plusieurs enregistrements d'un coup, mais il applique les règles de syntaxe des fichiers de zone, point final compris (le bêtisier ci-dessous y revient). L'API REST LiveDNS (v5), enfin, ouvre l'automatisation : authentification par jeton d'accès personnel, écriture d'un enregistrement par simple requête HTTP — la voie naturelle pour gérer SPF et DKIM en infrastructure-as-code, avec les connecteurs Terraform ou Ansible qui s'appuient dessus.

Un réglage transversal mérite l'attention : le TTL, à 10800 secondes (trois heures) par défaut. Avant une opération sur SPF ou DKIM, l'abaisser à 300 secondes raccourcit le délai de correction si une erreur se glisse ; il se remonte ensuite. Quant aux domaines enregistrés chez Gandi mais dont la zone est déléguée à Cloudflare, le même exercice côté Cloudflare — avec ses propres pièges, proxy orange en tête — est traité dans le guide dédié à Cloudflare.

Domaine chez Gandi, messagerie ailleurs : seules les valeurs changent

C'est probablement le cas le plus répandu : le domaine et sa zone vivent chez Gandi, les boîtes chez Microsoft 365 ou Google Workspace. Rien ne change dans la méthode — seuls les enregistrements changent.

Côté Microsoft 365, le SPF devient v=spf1 include:spf.protection.outlook.com -all, et DKIM prend la forme de deux CNAME, selector1._domainkey et selector2._domainkey, pointant vers le tenant en onmicrosoft.com ; l'activation de la signature se fait dans le portail Defender. Côté Google Workspace : SPF v=spf1 include:_spf.google.com ~all, et DKIM sous forme d'un TXT google._domainkey dont la clé — 2048 bits recommandés — se génère dans la console d'administration avant d'être collée dans LiveDNS, qui gère la découpe de la longue chaîne.

Deux réflexes complètent le tableau. D'abord, retirer include:_mailcust.gandi.net si plus aucun message ne part de GandiMail : un include mort consomme une résolution DNS sur les dix permises et élargit la surface autorisée sans contrepartie. Ensuite, remplacer les MX du modèle Gandi par ceux du fournisseur réel — des MX qui pointent vers spool.mail.gandi.net alors que la messagerie est chez Microsoft égarent le courrier entrant et brouillent le diagnostic.

Les erreurs courantes, du doublon SPF au point final

Les rapports DMARC et les forums d'entraide racontent toujours les mêmes histoires. Petit bêtisier :

• Le doublon SPF. La zone pré-remplie contient déjà un v=spf1 ; l'assistant de configuration d'un ESP recommande d'ajouter le sien ; les deux cohabitent, et c'est le permerror. La fusion en un seul enregistrement est la seule issue.
• Le vieux type SPF. D'anciennes zones héritées de l'infrastructure DNS « classique » de Gandi peuvent contenir un enregistrement de type SPF (type 99), déprécié de longue date par la RFC 7208 : seul le TXT compte, le doublon de type sème la confusion et se supprime.
• Le point final. En mode texte, gm1.gandimail.net sans point terminal devient gm1.gandimail.net.exemple.fr. — un CNAME qui ne résout rien. Le formulaire web complète le nom implicitement, le mode texte non : la règle dépend de l'éditeur utilisé, d'où des surprises en copiant une ligne d'un contexte à l'autre.
• L'impatience. Avec un TTL par défaut de trois heures, l'ancienne valeur reste servie par les résolveurs jusqu'à expiration du cache. Tester trente secondes après la modification et conclure à l'échec est un classique de la propagation DNS.
• Le sous-domaine oublié. SPF ne s'hérite pas : un sous-domaine émetteur (newsletter.exemple.fr) a besoin de son propre enregistrement.

L'étape suivante a son propre bêtisier : la syntaxe DMARC, avec ses points-virgules et ses balises pièges, cataloguée dans les erreurs de syntaxe d'un enregistrement DMARC.

Vérifier, puis brancher DMARC

La vérification ne se devine pas, elle se mesure. En ligne de commande, deux requêtes couvrent l'essentiel :

dig TXT exemple.fr +short
dig CNAME gm1._domainkey.exemple.fr +short

La première doit renvoyer un unique v=spf1…, la seconde la cible gm1.gandimail.net.. L'épreuve du réel complète le contrôle : un message envoyé vers une boîte Gmail, puis la lecture de l'en-tête Authentication-Results — spf=pass et dkim=pass avec l'un des sélecteurs gm1 à gm3 signent une configuration saine.

SPF et DKIM posés, il reste à brancher l'étage qui les exploite : DMARC, via un TXT sur _dmarc.exemple.fr, en commençant par v=DMARC1; p=none; rua=mailto:… pour observer sans rien bloquer. Plutôt que d'improviser la syntaxe, mieux vaut partir d'exemples d'enregistrements DMARC commentés et les adapter. Les rapports agrégés révèlent alors ce que l'inventaire a manqué — le vieux serveur qui envoie encore, l'outil branché par une filiale — et guident la montée vers p=quarantine puis p=reject, le point où l'usurpation du domaine cesse d'être rentable.

En résumé

Gandi livre une zone pré-remplie qui donne dix minutes d'avance, pas une authentification complète. Le SPF maison include:_mailcust.gandi.net couvre GandiMail et rien d'autre : il se durcit (~all, puis -all) et se fusionne — jamais ne se double — quand un ESP s'ajoute. DKIM s'active en un bouton et repose sur trois CNAME gm1 à gm3 qui laissent la rotation des clés à la charge de Gandi. La zone s'édite par formulaire, mode texte ou API, avec le point final et le TTL de trois heures comme pièges récurrents. Et quand la messagerie vit chez Microsoft 365 ou Google Workspace, la méthode demeure : seules les valeurs changent, à condition de purger les vestiges GandiMail. Pour les chemins d'interface précis, susceptibles de bouger à chaque refonte, la documentation Gandi fait foi.

Le contrôle final ne coûte rien : un passage du domaine dans l'analyse DMARC gratuite montre d'un coup d'œil l'état réel de SPF, DKIM et DMARC tels que les destinataires les voient. Et pour transformer l'essai — suivre les rapports, détecter la source oubliée, mener la politique jusqu'à p=reject — la création d'un compte ouvre la surveillance en continu, là où l'édition de zone s'arrête.