Defaults.Exposed › Corrections › Guides

SPF a cessé de fonctionner après un changement de prestataire de messagerie — le correctif de migration (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.

SPF casse généralement après un changement de prestataire de messagerie parce que l’enregistrement du nouveau prestataire a été ajouté à côté de l’ancien. Deux enregistrements v=spf1 constituent une erreur permanente — SPF s’annule entièrement. 1 013 416 domaines — environ un sur 138 de ceux qui tentent SPF — sont dans cet état, selon le recensement Defaults.Exposed portant sur 261 millions de domaines. Fusionnez-les en un seul.

Le correctif prend environ dix minutes : scannez le domaine pour voir exactement ce que la migration a laissé derrière elle, listez chaque enregistrement SPF à vos serveurs de noms faisant autorité, fusionnez-les en un seul enregistrement qui n’inclut que votre nouveau prestataire, et re-vérifiez avec dig. Ce guide parcourt chaque étape, plus les vérifications DKIM et serveurs de noms que la plupart des migrations oublient.

Pourquoi SPF a-t-il cassé juste après la migration ?

Parce que le guide de configuration du nouveau prestataire disait « ajoutez cet enregistrement TXT » — et vous l’avez fait, à côté de l’ancien. C’est la seule chose que le standard SPF n’autorise pas. Le RFC 7208 (§3.2, résultat d’erreur prescrit au §4.5) permet exactement un enregistrement v=spf1 par domaine ; un destinataire qui en trouve deux ou plus doit retourner PermError plutôt que deviner lequel fait autorité. PermError signifie que SPF est nul : ni l’ancien enregistrement, ni le nouveau, aucun SPF du tout.

Et cela ne s’arrête pas là. DMARC traite un PermError comme un échec de la branche SPF, donc votre courrier dépend désormais entièrement de DKIM. Si le DKIM du nouveau prestataire n’est pas encore configuré non plus — courant en cours de migration — vous envoyez du courrier non authentifié exactement au moment où vous avez changé d’infrastructure, ce qui est le moment où les destinataires vous scrutent le plus.

C’est le copier-coller qui annule la protection quand vous changez de prestataire, et ce n’est pas rare : 1 013 416 domaines publient en ce moment deux enregistrements SPF ou plus — environ un sur 138 de la population de 139 millions de domaines qui tentent SPF, selon le recensement Defaults.Exposed sur 261 millions de domaines (données au 2026-06-29). Les chiffres complets sur le piège des deux enregistrements ont leur propre rapport ; cette page est le correctif procédural.

Qu’est-ce que la migration a laissé derrière elle ?

Cinq reliquats causent presque tous les échecs SPF post-migration. Vérifiez-les dans cet ordre :

Comment corriger cela ? La checklist de migration

1. Lancez d’abord le scan gratuit sur defaults.exposed. Il lit votre DNS en direct et vous dit si vous avez plusieurs enregistrements SPF, un include manquant, ou un trou DKIM — diagnostiquez avant de toucher à quoi que ce soit.

2. Listez chaque enregistrement SPF aux serveurs de noms faisant autorité. dig +short NS votredomaine.com, puis dig +short TXT votredomaine.com @<serveur-de-noms> contre l’un d’eux. Comptez les chaînes commençant par v=spf1. Le seul décompte sûr est 1.

3. Fusionnez en un seul enregistrement. Un enregistrement, commençant par v=spf1, contenant l’include de votre nouveau prestataire et tout autre expéditeur que vous utilisez encore (outil de facturation, CRM, plateforme de newsletter), un -all ou ~all terminal unique. Exemple — ancien Google Workspace, nouveau Microsoft 365, en cours de vidage :

   Avant :  "v=spf1 include:_spf.google.com ~all"
            "v=spf1 include:spf.protection.outlook.com -all"
   
   Après :  "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"
   Plus tard : "v=spf1 include:spf.protection.outlook.com -all"
   

   Les valeurs des prestataires et les subtilités des panneaux DNS se trouvent dans les guides de configuration pour Google Workspace et Microsoft 365.

4. Supprimez les enregistrements en trop. Fusionner sans supprimer ne corrige rien — le PermError vient du décompte.

5. Gardez l’include de l’ancien prestataire uniquement tant que l’ancien système envoie encore — rapports programmés, ancien connecteur CRM, boîte aux lettres oubliée. Une fois le vidage terminé, retirez-le : un include obsolète laisse l’ancienne infrastructure autorisée à envoyer en votre nom, et chaque include coûte des lookups DNS contre le plafond strict de 10 de SPF — au moins 797 263 domaines ont annulé SPF en dépassant ce plafond (recensement, 2026-06-29).

6. Configurez le DKIM du nouveau prestataire — et ne supprimez pas encore les anciens sélecteurs. Les nouveaux sélecteurs signent le nouveau courrier ; les anciens sélecteurs doivent rester publiés jusqu’à ce que chaque message signé avec eux ait été livré et que tout transfert soit réglé. Guide complet dans DKIM en échec après un changement d’outils de messagerie.

7. Si vous avez aussi changé de serveurs de noms, vérifiez les deux. Les migrations DNS accompagnent souvent les migrations e-mail. Interrogez directement l’ancien et le nouveau jeu de NS (dig TXT votredomaine.com @ancien-ns et @nouveau-ns) — tant que la délégation registrar ne s’est pas entièrement propagée, certains destinataires interrogent encore les anciens serveurs, donc l’enregistrement corrigé doit exister sur celui qui répond.

8. Relancez le scan et confirmez que SPF montre un seul enregistrement valide avec un pass.

Quel domaine SPF vérifie-t-il réellement ?

Les destinataires évaluent SPF contre le domaine du Return-Path (RFC5321.MailFrom) — l’adresse de rebond — pas l’en-tête From que voient vos destinataires. Après une migration, cela compte doublement : votre nouveau prestataire peut utiliser son propre domaine de rebond jusqu’à ce que vous en configuriez un personnalisé, et un SPF qui « passe » sur un domaine qui n’est pas le vôtre ne s’alignera pas pour DMARC. Le correctif pour cela est le DKIM du nouveau prestataire, signé avec votre domaine.

Migration et changement de marque en même temps ?

Vous avez changé de domaine en même temps que de prestataire ? Traitez-les comme deux travaux distincts. Le nouveau domaine a besoin de la pile complète — SPF, DKIM, DMARC — dès le premier jour ; utilisez la checklist e-mail nouveau domaine. L’ancien domaine reste authentifié tant que le transfert ou le trafic de réponse y transite, et est explicitement verrouillé (pas simplement abandonné) une fois mis en attente. Un ancien domaine avec un SPF laissé à moitié cassé est une cible d’usurpation portant votre ancien nom.

Questions fréquentes

Puis-je garder deux enregistrements SPF pendant ma migration ? Non. Il n’y a aucune période de grâce dans le standard — deux enregistrements v=spf1 sont un PermError dès que le second existe, et 1 013 416 domaines sont dans cet état au moment du recensement (2026-06-29). Le schéma sûr pour la migration est un seul enregistrement portant les includes des deux prestataires pendant le chevauchement.

Combien de temps dois-je garder l’include de l’ancien prestataire ? Jusqu’à ce que plus rien ne transite par l’ancien prestataire — typiquement la durée de votre fenêtre de chevauchement, de quelques jours à quelques semaines. Surveillez le Return-Path de tout ce qui arrive encore via l’ancien système ; quand ce trafic s’arrête, retirez l’include et revérifiez votre décompte de lookups.

Pourquoi un vérificateur montre-t-il encore mon ancien enregistrement après que je l’ai corrigé ? La mise en cache DNS honore le TTL de l’enregistrement, et si vos serveurs de noms ont changé, certains résolveurs interrogent encore l’ancien jeu. Vérifiez directement aux serveurs de noms faisant autorité avec dig TXT votredomaine.com @<ns> — si la réponse est correcte là, le correctif est fait et les caches vont rattraper. Si c’est faux à un jeu de NS, voir « SPF record not found » — les vraies causes.

Dois-je changer DMARC quand je change de prestataire ? Généralement pas l’enregistrement lui-même — il nomme votre boîte de rapport et votre politique, pas votre prestataire. Mais vos résultats DMARC dépendent du SPF et du DKIM que vous venez de migrer : attendez-vous à une baisse des rapports pendant la bascule, et confirmez que les deux branches passent avant de resserrer la politique. Commencez par corriger SPF si le scan montre que la branche SPF échoue encore.

Envoyez le rapport au propriétaire

Si vous faites cette migration pour un client, terminez avec des preuves. Relancez le scan gratuit une fois la fusion en ligne et transmettez le rapport noté au chef d’entreprise : SPF, DKIM et DMARC qui passent sur le nouveau prestataire, en langage clair, daté. C’est l’artefact qu’il classera pour le renouvellement de cyberassurance et le prochain questionnaire de sécurité fournisseur — la preuve que la migration a laissé le domaine mieux authentifié qu’il ne l’était au départ.

Vérifiez votre domaine → · DKIM en échec après un changement d’outils de messagerie → · « SPF record not found » — les vraies causes → · Comment nous notons → · Données agrégées uniquement. Données stockées et traitées dans l’UE.