Le nouveau site peut fonctionner parfaitement alors que les factures, les liens de réinitialisation et les réponses des clients n’arrivent plus. L’erreur consiste à considérer le changement des serveurs de noms comme un réglage réservé au site. Ce plan s’adresse à une petite entreprise qui change de fournisseur DNS en conservant son service de messagerie. Il décrit une procédure, pas une garantie de livraison ininterrompue. Les exemples utilisent le nom réservé example.com : remplacez-le par votre domaine et les valeurs fournies par votre prestataire. DÉFINIR CE QUI CHANGE Notez trois services distincts : le registraire du domaine, le fournisseur qui répond aux requêtes DNS faisant autorité et l’entreprise qui héberge les boîtes mail. Pour cette migration, ne changez que le deuxième. Conservez l’hébergement du site, l’abonnement de messagerie et les services d’envoi. Si un collègue souhaite également déplacer les boîtes mail, prévoyez un autre projet avec une autre date. Cette séparation permet d’identifier l’origine d’un incident plutôt que d’enquêter sur plusieurs migrations à la fois. INVENTORIER AVANT DE MODIFIER LES SERVEURS Exportez la zone existante et gardez une version lisible à côté de l’export. Votre tableau doit contenir le nom, le type, la valeur, la priorité, le TTL, l’usage, le responsable du service et le résultat du contrôle. Incluez le nom racine, www, mail, autodiscover, les sélecteurs DKIM, _dmarc et tous les enregistrements de vérification. Ajoutez ceux du CRM, du logiciel de facturation et du support, même si personne ne se rappelle qui les a créés. Demandez aux responsables si ces outils envoient toujours des messages avec votre domaine. Les enregistrements MX désignent les serveurs de courrier ; les TXT peuvent publier des politiques de messagerie. SPF, DKIM et DMARC remplissent des fonctions différentes : conserver l’un ne remplace pas les autres. Leurs spécifications sont liées ci-dessous. Relevez les valeurs réellement utilisées au lieu de copier une configuration générique. Ne publiez pas une seconde politique SPF concurrente simplement parce que le nouveau tableau de bord la suggère. RÉPÉTER LA MIGRATION DANS LA NOUVELLE ZONE Créez la zone de destination et comparez chaque ligne à l’inventaire. La découverte automatique constitue un point de départ, pas une preuve de conformité. Dans notre exemple fictif, sales@example.com reste chez le même hébergeur de messagerie : les destinations MX et leurs priorités doivent donc rester identiques. L’enregistrement A du site peut également être conservé. Migrer le DNS n’impose pas d’inventer de nouvelles adresses web ou mail. Avant de modifier la délégation, interrogez directement chaque nouveau serveur faisant autorité. Conservez les réponses pour MX, le TXT racine, _dmarc et chaque sélecteur DKIM actif. Utilisez par exemple dig @NEW_NAMESERVER example.com MX, en remplaçant le paramètre par le serveur attribué. Comparez les valeurs complètes, pas uniquement l’existence des enregistrements. Un sélecteur absent peut n’affecter qu’un seul expéditeur et échapper à un test superficiel. Choisissez une période calme et désignez une seule personne pour effectuer le changement. Notez les anciens serveurs de noms et l’identifiant de la nouvelle zone dans le même ticket. Si vous souhaitez réduire les TTL, faites-le à l’avance et attendez l’expiration des anciens TTL : une modification de dernière minute ne vide pas instantanément les caches. Fixez une heure de décision pour le retour arrière et indiquez qui peut l’autoriser. TRAITER DNSSEC COMME UNE ÉTAPE DISTINCTE Si DNSSEC est activé, examinez les informations DS existantes et suivez la procédure de migration du nouveau fournisseur. Ne laissez pas dans la zone parente un DS renvoyant à une clé que la nouvelle zone ne peut pas utiliser. La documentation Cloudflare sur la configuration complète explique cette dépendance. Une zone signée exige une étape DNSSEC explicite dans le ticket, plutôt que l’hypothèse que le formulaire des serveurs de noms s’occupe de tout. TESTER LE PARCOURS CLIENT, PAS SEULEMENT LE SITE Avant et après le changement, envoyez un message portant une référence unique depuis une boîte externe vers une véritable adresse de l’entreprise, puis répondez. Recommencez avec un second fournisseur externe. Déclenchez ensuite une réinitialisation de mot de passe, une notification de support et une facture de test depuis les outils inventoriés. Utilisez des clients fictifs et des données non sensibles. Notez le message attendu, sa réception et les résultats d’authentification observés dans ses en-têtes. Si le site fonctionne mais pas la réception des messages, commencez par les MX et le service destinataire. Si seuls les messages du CRM échouent, comparez ses enregistrements d’authentification et ses journaux. Si un réseau rencontre le problème et pas un autre, comparez les réponses DNS avant de modifier l’application. Ce parcours de diagnostic proposé réduit le champ de recherche ; il ne démontre pas à lui seul la cause. TERMINER AVEC DES PREUVES Gardez les deux services DNS disponibles pendant la période d’observation convenue. Évitez les changements sans rapport pendant la collecte des résultats. Fermez le ticket seulement lorsque la comparaison de l’inventaire, les tests de courrier externe et les contrôles des outils métier ont des responsables et des résultats consignés. Conservez l’export final, l’heure et les exceptions encore ouvertes. Ce dossier sera plus utile lors de la prochaine migration qu’une capture indiquant que le domaine est actif. Vous préparez une nouvelle marque ? Comparez les noms dans le catalogue DomainEvery: https://domainevery.com/fr/domains, puis attribuez la responsabilité du courrier et du DNS dans le plan de lancement. SOURCES PRIMAIRES Cloudflare : changer les serveurs de noms: https://developers.cloudflare.com/dns/zone-setups/full-setup/setup/; Cloudflare : enregistrements de messagerie: https://developers.cloudflare.com/dns/manage-dns-records/how-to/email-records/; Formats DNS, RFC 1035: https://www.rfc-editor.org/rfc/rfc1035.html; SPF, RFC 7208: https://www.rfc-editor.org/rfc/rfc7208; DKIM, RFC 6376: https://www.rfc-editor.org/rfc/rfc6376.html; DMARC, RFC 7489: https://www.rfc-editor.org/rfc/rfc7489.html.