Defaults.Exposed › Corrections › Guides

DKIM en échec après un changement d'outil e-mail : le guide de migration CNAME et sélecteurs (2026)

Publié 2026-07-08

Chiffres au 2026-06-29 · méthodologie v7. Données de recensement agrégées sur 261 millions de domaines évalués. Voir comment nous notons.

DKIM casse après un changement d’outil pour deux raisons mécaniques : votre panneau DNS a mutilé les cibles CNAME du nouvel outil — le plus souvent en y ajoutant votre propre zone — ou les sélecteurs de l’ancien outil ont été supprimés avant l’écoulement de son courrier. Seuls 3,87 % des domaines — 10 092 481 — complètent la triade SPF+DKIM+DMARC, selon le recensement Defaults.Exposed portant sur 261 086 232 domaines évalués.

L’ordre de réparation : scannez le domaine, puis vérifiez la cible stockée de chaque nouveau CNAME avec dig — une cible qui se termine par votre propre nom de domaine est la preuve flagrante. Réparez les enregistrements sur les serveurs de noms autoritaires, confirmez que le nouvel outil signe et passe avant d’y router du courrier réel, et gardez les sélecteurs de l’ancien outil publiés jusqu’à l’écoulement de son trafic.

Pourquoi DKIM a-t-il cassé quand vous avez changé d’outil ?

Rien n’a changé dans DKIM lui-même — ce sont vos sélecteurs qui ont changé. L’ancien outil signait avec ses sélecteurs ; le nouveau signe avec d’autres, généralement délégués via deux ou trois enregistrements CNAME ajoutés lors de la mise en route. Quatre pièges expliquent presque tous les échecs DKIM post-migration :

1. Votre panneau DNS a ajouté votre zone à la cible du CNAME. Beaucoup de panneaux traitent tout nom d’hôte collé comme relatif et stockent silencieusement target.provider.com.yourdomain.com au lieu de target.provider.com. L’enregistrement existe, le panneau affiche une coche verte, et il ne se résout vers rien.
2. La confusion du point final. Certains panneaux exigent un point final (target.provider.com.) pour signifier « nom absolu — cessez d’ajouter ma zone » ; d’autres rejettent le point comme invalide et gèrent eux-mêmes le caractère absolu. La même valeur collée est correcte dans un panneau et mutilée dans le suivant.
3. Les sélecteurs de l’ancien outil ont été supprimés le jour de la bascule. Le courrier déjà signé par l’ancien outil reste dans les files de réessai et les chemins de transfert pendant des jours ; supprimer ses sélecteurs — ou fermer l’ancien compte, ce qui tue ses CNAME délégués — casse ce courrier rétroactivement.
4. Vous avez vérifié sur les mauvais serveurs de noms. Si la migration comprenait un changement de serveurs de noms, les enregistrements corrigés peuvent exister sur un jeu de NS pendant que les serveurs de réception interrogent encore l’autre.

Seuls 51,84 % des 261 millions de domaines du recensement présentent une clé DKIM découvrable au moment du scan (données au 2026-06-29).

La même migration laisse en général aussi des débris SPF — 1 013 416 domaines, environ 1 sur 138 parmi ceux qui tentent SPF, portent deux enregistrements v=spf1, signe classique qu’un changement de prestataire a ajouté un enregistrement au lieu d’en fusionner un. Ce versant du déménagement a son propre guide : SPF a cessé de fonctionner après un changement de prestataire e-mail.

Comment repérer un enregistrement CNAME mutilé ?

Ne faites pas confiance au panneau — demandez au DNS ce qu’il a réellement stocké. Interrogez la cible CNAME de chaque sélecteur fourni par le nouvel outil. Un exemple illustratif, imitant un sélecteur délégué façon SendGrid (la forme de la cible variera selon votre prestataire) :

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.yourdomain.com.

Le prestataire demandait s1.domainkey.u1234567.wl123.sendgrid.net — mais la cible stockée se termine par .yourdomain.com. Le panneau a ajouté la zone ; ce nom ne se résout vers rien, donc les serveurs de réception ne trouvent aucune clé. La version saine :

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.

(Un point final unique dans la sortie dig est normal — il marque un nom pleinement qualifié.) Si la cible est correcte, suivez-la d’un saut : dig TXT s1._domainkey.yourdomain.com +short doit renvoyer la clé du prestataire. Une réponse vide avec un CNAME correct signifie que le problème est du côté prestataire de la délégation — terminez son étape de vérification, ou voyez DKIM « no key for signature » pour le diagnostic au niveau du sélecteur.

Le runbook de migration : avant, pendant, après

L’échec ne vient généralement pas des enregistrements — il vient de l’ordre. Les migrations DKIM déraillent à la bascule parce que la vérification se fait après le changement, quand le courrier réel échoue déjà.

La ligne en gras est celle où les migrations se gagnent ou se perdent : chacune de ses vérifications peut se faire des jours avant la bascule, sans aucun risque pour le courrier en production. La mécanique du retrait de sélecteurs — y compris pourquoi republier avec un p= vide vaut mieux que supprimer — est couverte dans le runbook de rotation ; ce tableau porte sur le séquencement du changement d’outil lui-même.

Comment réparer DKIM après la bascule ?

1. Lancez le scan gratuit sur defaults.exposed avant de toucher au DNS. Il lit vos enregistrements en direct et montre ce que les serveurs de réception voient réellement — y compris les cibles CNAME ayant subi un ajout de zone et les sélecteurs qui ne se résolvent pas.
2. Listez les enregistrements DKIM attendus par le nouvel outil. Depuis sa console d’administration — pour les fournisseurs de boîtes mail, les guides de configuration Google Workspace et Microsoft 365 montrent où ; les outils de newsletter et CRM listent leurs CNAME sous l’authentification de domaine (voir les e-mails Mailchimp/Brevo/Klaviyo échouent à DMARC).
3. Vérifiez la valeur stockée de chaque enregistrement avec dig CNAME <name> +short et comparez-la caractère par caractère avec ce que l’outil demandait. Une cible qui se termine par votre propre domaine = ajout de zone ; ressaisissez-la, et si le panneau continue d’ajouter, mettez le point final (ou retirez-le, si le panneau rejette les points).
4. Vérifiez sur les serveurs de noms autoritaires. dig +short NS yourdomain.com, puis refaites les vérifications CNAME @<that nameserver>. Si la migration a changé de serveurs de noms, contrôlez les deux jeux — les serveurs de réception peuvent encore interroger l’ancien jusqu’à propagation de la délégation.
5. Relancez la vérification de l’outil et envoyez un message de test. L’en-tête Authentication-Results doit afficher dkim=pass avec d= égal à votre domaine — un pass sur le domaine par défaut de l’outil ne s’aligne pas pour DMARC.
6. Laissez les sélecteurs de l’ancien outil publiés jusqu’à écoulement de son courrier, puis retirez-les délibérément. Relancez ensuite le scan et traitez tout ce qui reste signalé sur la page corriger DKIM.

Questions fréquentes

Faut-il ou non le point final sur mon CNAME DKIM ? Cela dépend entièrement du panneau. Le point signifie « nom absolu — n’ajoutez pas ma zone » ; certains panneaux l’exigent, d’autres l’ajoutent pour vous, d’autres le rejettent. Le seul test qui compte est la sortie de dig CNAME <selector>._domainkey.yourdomain.com +short après enregistrement : si la cible se termine par votre propre domaine, le panneau a ajouté la zone et il vous faut le point (ou un autre format de saisie).

Puis-je supprimer les enregistrements DKIM de l’ancien outil le jour de la bascule ? Non. Le courrier signé par l’ancien outil est encore dans les files de réessai et les chemins de transfert, et supprimer la clé vers laquelle il pointe casse ces messages rétroactivement. Gardez les anciens sélecteurs actifs jusqu’à ce qu’ils cessent d’apparaître dans vos rapports agrégés DMARC — une semaine ou plus — et ne fermez pas non plus l’ancien compte avant.

Mon panneau DNS et le nouvel outil disent tous deux « verified », mais les serveurs de réception font encore échouer DKIM. Comment ? Deux cas fréquents : l’outil a vérifié contre une réponse en cache pendant que les serveurs de noms autoritaires servent autre chose (interrogez-les directement avec dig @<ns>), ou DKIM passe mais sur le domaine de signature par défaut de l’outil plutôt que le vôtre, donc DMARC échoue toujours à l’alignement. Le scan distingue les deux.

Les enregistrements DKIM des deux outils peuvent-ils coexister pendant le chevauchement ? Oui — et ils le doivent. DKIM n’a pas de règle d’enregistrement unique : chaque sélecteur est son propre nom DNS, donc les enregistrements des deux outils vivent côte à côte sans conflit, ce qui rend la règle « gardez les anciens sélecteurs jusqu’à l’écoulement » gratuite à suivre. (SPF est l’inverse — deux enregistrements v=spf1 l’annulent, raison pour laquelle le guide de migration SPF parle de fusion.)

Envoyez le rapport au propriétaire

Si vous menez cette migration pour un client ou votre employeur, clôturez-la avec des preuves. Une fois que le nouvel outil signe et s’aligne, relancez le scan gratuit et transmettez le rapport noté au chef d’entreprise : une preuve datée, en langage clair, que la bascule a laissé le domaine pleinement authentifié. C’est la pièce dont il aura besoin au renouvellement de la cyberassurance et au prochain questionnaire de sécurité fournisseur — elle transforme « la migration est terminée » d’une affirmation en un document.

Vérifiez votre DKIM gratuitement

Voyez si les sélecteurs de votre nouvel outil se résolvent — et exactement quoi corriger — en privé, visible du propriétaire uniquement.

Vérifiez votre domaine → · SPF cassé après un changement de prestataire → · Corriger DKIM → · Configurer DKIM sur Google Workspace → · Données agrégées uniquement. Données stockées et traitées dans l’UE.