Comprendre les DNS : connecter son site sans interrompre ses e-mails

Vous voulez connecter votre domaine à votre site ou ajouter un service, mais les lignes A, CNAME, MX et TXT semblent mystérieuses ? Commencez par identifier qui gère la zone DNS et quels services utilisent le domaine. Le site et les e-mails peuvent être hébergés à des endroits différents.

Ce guide explique les principaux enregistrements et une méthode de modification vérifiable. Les valeurs réelles doivent venir de votre hébergeur ou du service concerné ; aucune adresse d’exemple ci-dessous n’est un réglage iMasterWeb.

1. Distinguer domaine, hébergement et zone DNS

Le gestionnaire du domaine, le fournisseur DNS, l’hébergement du site et la messagerie peuvent être quatre acteurs différents. Le panneau où le domaine a été acheté n’est pas forcément celui dont la zone DNS est actuellement utilisée.

Retrouvez les serveurs de noms actifs et demandez à votre support où modifier la zone faisant autorité. Changer une zone inutilisée ne modifie pas le résultat public. À l’inverse, remplacer les serveurs de noms change la délégation de toute la zone et mérite une préparation plus large qu’une simple mise à jour d’adresse web.

2. Lire les principaux types d’enregistrements

Exemple pédagogique uniquement : example.com et les adresses ci-dessous ne sont pas des valeurs de votre hébergement. Ne les copiez pas dans votre zone réelle.

Le nom peut être présenté comme @, une case vide ou le domaine complet selon le panneau. Vérifiez sa convention : certains panneaux ajoutent automatiquement le domaine à un nom court. Le symbole @ n’est pas une valeur à recopier partout.

Repères sur les types DNS · Principes du DNS.

3. Relier le domaine au site sans toucher à la messagerie

Demandez les valeurs exactes pour le domaine principal et pour www. Préparez un tableau avec l’ancien réglage, le nouveau, la raison et la vérification attendue. Notez aussi les enregistrements AAAA : une ancienne destination IPv6 peut expliquer un résultat différent selon la connexion.

1. Exportez la zone actuelle ou conservez une copie lisible des réglages.
2. Vérifiez le nom et le type de chaque ligne à modifier.
3. Appliquez uniquement les changements web demandés et gardez les autres services identifiés.
4. Contrôlez le domaine principal et www, puis le site en HTTPS.
5. Testez également réception et envoi d’e-mails, même si la messagerie devait rester identique.

Un CNAME désigne un nom, pas une URL avec https:// ou un chemin. Il ne réalise pas une redirection HTTP. Un CNAME classique ne coexiste pas avec d’autres données au même nom ; le domaine racine peut nécessiter un mécanisme propre au fournisseur. Ne supprimez pas les MX ou TXT de la racine pour forcer un CNAME. Contraintes du CNAME.

4. Protéger les e-mails pendant la modification

Les MX indiquent où recevoir les messages ; ils ne déplacent pas les anciennes boîtes. Leur cible est un nom de serveur et la priorité numérique la plus faible est préférée. Utilisez les valeurs de votre fournisseur, sans inventer de cible ou de priorité. Fonctionnement des MX.

Les enregistrements d’authentification demandent également une vérification :

• SPF : réunit les expéditeurs autorisés. Ne créez pas deux politiques SPF concurrentes au même nom ; faites intégrer les sources légitimes dans une politique cohérente.
• DKIM : publie les informations correspondant aux signatures du service d’envoi ; recopiez son sélecteur et sa valeur exacts.
• DMARC : exprime une politique fondée sur les résultats et l’alignement de l’authentification. N’appliquez pas une politique stricte générique sans examiner les sources d’envoi.

Plusieurs TXT peuvent être légitimes : la règle concernant une politique SPF ne signifie pas qu’un domaine ne doit avoir qu’un seul TXT. Un TXT de vérification Search Console ne remplace ni SPF ni DKIM. Spécification SPF.

5. Comprendre le TTL et les différences temporaires

Le TTL indique une durée de mise en cache. Si une baisse de TTL est prévue pour une bascule, elle doit être appliquée suffisamment en amont pour que les anciennes réponses aient pu expirer. La modifier au dernier moment ne retire pas les copies déjà en cache.

Les réponses peuvent donc différer temporairement selon les résolveurs et les caches. Il n’existe pas un délai universel de propagation de 24 ou 48 heures applicable à tout changement. Vérifiez le réglage faisant autorité puis les réponses publiques. Comprendre le TTL.

6. Cas particulier : changer les serveurs de noms

Préparez la nouvelle zone complète avant de changer la délégation : site, messagerie, sous-domaines, vérifications et services utilisés. Une copie automatique ou une détection ne garantit pas que toutes les lignes nécessaires ont été retrouvées.

Si DNSSEC est actif, faites coordonner les signatures et l’enregistrement DS avec le gestionnaire du domaine et le fournisseur DNS. Une incohérence peut provoquer des échecs de validation. DNSSEC authentifie les données DNS ; ce n’est pas le chiffrement HTTPS du site. Documentation DNSSEC.

7. Vérifier et diagnostiquer sans multiplier les changements

Après l’enregistrement, comparez la zone active et les réponses observées. Un site qui arrive sur la bonne adresse peut encore avoir un problème de certificat ou de configuration serveur : DNS et HTTPS sont deux contrôles distincts.

• Ancien site visible : examinez les caches, les serveurs de noms actifs, les variantes du domaine et les anciennes lignes A ou AAAA.
• E-mails interrompus : comparez MX, authentification et existence des boîtes avec la configuration attendue.
• Sous-domaine en erreur : vérifiez le nom réellement créé et un éventuel domaine ajouté deux fois.
• Vérification de propriété refusée : contrôlez le nom, la valeur TXT complète et la zone effectivement utilisée.

Si vous êtes bloqué, transmettez au support le domaine, le type et le nom de l’enregistrement, l’ancienne et la nouvelle destination, l’heure du changement et le résultat observé. Évitez d’exposer des clés privées ou des codes d’accès.

Checklist et questions fréquentes

• Zone faisant autorité identifiée et ancienne configuration conservée.
• Valeurs reçues du service concerné, sans utiliser un exemple générique.
• Messagerie et sous-domaines pris en compte.
• TTL et DNSSEC examinés si la bascule le nécessite.
• Site, HTTPS et e-mails testés séparément.

Dois-je changer de serveurs de noms pour changer d’hébergement ?

Pas toujours. Selon l’organisation choisie, une modification des seules adresses web peut suffire. Faites confirmer le périmètre.

Changer les MX copie-t-il mes anciens messages ?

Non. La migration des boîtes et de leur contenu est un travail distinct.

Pour la suite, consultez les guides sauvegarde WordPress, migration et Search Console. Pour les valeurs de votre compte, contactez iMasterWeb.

Pour utiliser une adresse à votre nom de domaine, voir aussi la page adresse e-mail professionnelle.