Confirmez que Dynadot fait autorité
Un domaine enregistré chez Dynadot peut utiliser DNS d'une autre entreprise. Commencez par vérifier le délégué serveurs de noms et identifier le compte qui contrôle la zone faisant autorité. Si le domaine utilise des serveurs de noms externes, publiez-y. Changer les serveurs de noms du bureau d'enregistrement simplement pour utiliser l'éditeur Dynadot est une migration DNS , et non une modification ordinaire d'un enregistrement d'authentification.
Rassemblez le type d'enregistrement exact de la plateforme d'envoi, le nom complet du propriétaire et sa valeur, ainsi que les paramètres de zone existants. Ce guide explique la publication, et non quel expéditeur doit être autorisé. L'administrateur du courrier doit fournir et approuver le SPF politique, DKIM enregistrer ou DMARC politique avant que l’opérateur DNS ne l’enregistre.
Traduire les propriétaires dans les champs de l'éditeur
Dynadot documente Mes domaines > Gérer les domaines, la sélection du domaine, Action > Paramètres DNS et l'option DNS Dynadot. Pour les données TXT apex, utilisez Domain Record avec TXT et mettez la valeur dans Adresse IP/Destination. Il demande aux utilisateurs d'omettre les guillemets environnants. Instructions TXT
Ses règles de nom de propriétaire sont importantes : une instruction @ désigne la section d'enregistrement de domaine, et non une étiquette @ littérale. Un propriétaire non apex appartient à l'enregistrement de sous-domaine et le suffixe de zone d'un nom complet fourni doit être supprimé avant de saisir le préfixe. Par exemple, le propriétaire illustratif _dmarc.example.com dans la zone example.com devient _dmarc . Un propriétaire DKIM tel que selector1._domainkey.example.com devient selector1. _domainkey . Ce sont des exemples de syntaxe, pas de véritables valeurs de compte.
Enregistrez avec Enregistrer les paramètres, puis vérifiez le propriétaire complet publié. Ne présumez pas qu’une soumission réussie du formulaire signifie que le nom DNS est correct. Entrer l'intégralité du domaine où seul un préfixe est attendu peut produire un suffixe dupliqué et laisser le propriétaire requis vide.
Conserver la configuration racine requise
Le guide TXT de Dynadot indique que sa configuration DNS nécessite également une racine A, AAAA, CNAME ou transfert d'entrée. Il s'agit d'une contrainte de l'éditeur de fournisseur et non d'une règle DNS générale. Conservez la configuration racine réelle et approuvée du domaine. N'inventez pas d'adresse fictive et ne modifiez pas le site Web uniquement pour satisfaire le formulaire. Si une conception de messagerie uniquement n'a pas d'entrée racine appropriée, demandez à Dynadot une configuration prise en charge avant de l'enregistrer.
Pour un CNAME DKIM , utilisez la zone d'enregistrement de sous-domaine avec le sélecteur étiquette, type CNAME et destination. Dynadot Procédure CNAME utilise un exemple de site Web ; remplacez le sélecteur de courrier réel plutôt que de copier www ou l'exemple de destination de transfert. Évitez un CNAME chez un propriétaire qui propose déjà un autre service actif.
Vérifier l'enregistrement que les destinataires interrogeront
Méthode de vérification originale : conservez les réponses faisant autorité avant et après pour chaque propriétaire et type exact. Pour SPF , vérifiez le domaine d’enveloppe applicable et assurez-vous qu’une seule stratégie SPF candidate existe. Pour DKIM , interrogez le sélecteur fourni par la plateforme d'envoi et suivez son CNAME s'il est présent. Pour DMARC , interrogez le propriétaire _dmarc prévu et comparez la stratégie avec la modification approuvée.
Utilisez ensuite le contrôle de vérification de la plateforme d'envoi, puis envoyez un message inoffensif via l'itinéraire prévu. Enregistrez les résultats d'authentification du destinataire et comparez le domaine SPF ou DKIM passant avec le domaine From visible. Publication DNS , vérification du fournisseur et message alignement sont des observations différentes; conserver les trois plutôt que de considérer un seul indicateur vert comme concluant.
Récupérer l'enregistrement exact
Échec illustratif : _dmarc.example.com a été saisi dans un champ réservé uniquement au préfixe, créant ainsi un suffixe en double. Corrigez le propriétaire après avoir vérifié ce qui a été réellement publié ; ne créez pas plusieurs stratégies DMARC chez le propriétaire prévu comme solution de contournement. Conserver sans rapport Enregistrements TXT tels que les jetons de vérification de service.
En cas d'échec, restaurez l'enregistrement concerné à son état antérieur approuvé et autorisez la mise en cache. Revérifiez après une migration de serveur de noms ou un nettoyage d'enregistrement. La documentation a été examinée le 8 novembre 2026. Aucun compte Dynadot, changement DNS en direct ou message délivré n'a été testé ici.
Préparez une carte de traduction du nom du propriétaire
Pour chaque enregistrement, conservez les instructions du service d'envoi, le propriétaire DNS complet prévu, le suffixe de zone, le champ de l'éditeur, l'étiquette saisie, le type d'enregistrement et le résultat faisant autorité. Par exemple, _dmarc.example.com dans la zone example.com correspond à l'étiquette du sous-domaine _dmarc ; le sommet correspond à l'enregistrement de domaine. Comparez le propriétaire complet reconstruit avant de sauvegarder. Si l'interface actuelle diffère du modèle documenté, arrêtez et confirmez la sémantique du champ plutôt que de deviner.