Confirmer que Gandi héberge la zone active
Un enregistrement de domaine chez Gandi ne prouve pas en soi que Gandi sert son DNS faisant autorité. Vérifiez le délégué serveurs de noms pour le domaine en premier. Gandi indique que les serveurs de noms hébergés en externe doivent être gérés via le fournisseur externe. Ce guide couvre l'éditeur Gandi LiveDNS documenté, et non une migration depuis un autre hôte DNS .
Séparez la configuration du service de messagerie de la publication DNS . Votre fournisseur d'envoi fournit ses services pris en charge sélecteur, clé ou CNAME cible et toutes les exigences du domaine d’enveloppe. Gandi publie ces archives ; créer un DKIM Enregistrement TXT n'entraîne pas le début de la signature d'un serveur de messagerie non lié. Ne pas en déduire un Gandi universel SPF inclure pour un domaine simplement parce que son DNS y est hébergé.
Identifiez l'administrateur DNS , le propriétaire du service d'envoi et la personne autorisée à approuver la politique de domaine. Enregistrez les jeux d’enregistrements existants pour tous les noms concernés. Vérifiez si le domaine est lié à une zone partagée : les documents Gandi qui changent en zone liée affectent tous les domaines liés. Une modification d’authentification apparemment locale peut donc avoir un impact plus large.
Utiliser un changement d'éditeur limité
L'itinéraire documenté est le domaine, le domaine sélectionné, puis les enregistrements DNS . Le mode Tableau prend en charge l'ajout ou la modification d'entrées individuelles ; le mode texte modifie toute la zone. Pour un petit changement d'authentification, les enregistrements individuels sont plus faciles à comparer avec la demande approuvée. Utilisez le mode texte uniquement lorsque l'éditeur est compris et que toute la différence proposée a été examinée.
Gandi LiveDNS propose de sauvegarder une sauvegarde et de restaurer. Effectuez une sauvegarde avant la modification, mais ne présumez pas que sa restauration ultérieure est inoffensive : une restauration complète peut annuler les modifications sans rapport effectuées depuis cet instantané. Enregistrez également un plan de récupération ciblé pour les enregistrements concernés. Si une zone partagée est impliquée, incluez les autres propriétaires de domaine dans ce plan.
Créez une feuille de travail de publication avec le propriétaire complet prévu, l'étiquette de l'éditeur, le type et la valeur. Pour un domaine synthétique example.com , le sommet est example.com , son DMARC le propriétaire est _dmarc.example.com et un propriétaire DKIM peut être rotation1._domainkey.example.com . Ces exemples d'étiquettes ne sont pas des paramètres générés par le fournisseur. Utilisez le sélecteur et le domaine réels du service d'envoi.
Préserver les limites et les noms TXT
La documentation TXT de Gandi utilise @ pour le domaine nu et un label relatif pour un sous-domaine. Ses exemples de zones de texte représentent de longues données TXT sous forme de plusieurs chaînes entre guillemets dans un même enregistrement, chacune ne dépassant pas 255 caractères. Ceci est différent de la création de plusieurs enregistrements TXT indépendants.
Cette distinction est importante pour l'authentification. Une politique SPF peut être constituée de plusieurs chaînes de caractères dans un seul enregistrement de ressource TXT , mais plusieurs chaînes candidates Enregistrements SPF chez le même propriétaire provoque une erreur SPF . Les éléments clés DKIM doivent également rester complets. Ne créez pas plusieurs clés ou stratégies sans rapport pour dépasser une limite de champ de texte, et n'insérez pas de sauts de ligne visuels dans une clé sans comprendre comment l'éditeur les sérialise.
Utilisez le type d'enregistrement TXT pour SPF . Utilisez TXT ou CNAME pour DKIM selon les instructions du fournisseur d'envoi, et non selon vos préférences personnelles. Un CNAME au niveau d'un sélecteur est un alias vers un autre nom de domaine, et non un conteneur de texte de clé publique. Si un CNAME demandé entre en collision avec des données existantes portant ce nom, résolvez la collision plutôt que de remplacer le sélecteur actif d'un autre service.
Publier la politique prévue, pas un échantillon
Une mise à jour SPF nécessite un examen de tous les expéditeurs légitimes et des dépendances de recherche DNS. Conservez les autorisations nécessaires dans une politique valide au niveau du domaine d’enveloppe concerné. Une mise à jour DMARC nécessite une décision politique délibérée pour le domaine visible From et ses sous-domaines applicables. L’ajout d’un fournisseur n’est pas une raison pour ajouter une autre stratégie DMARC chez un propriétaire où il en existe déjà une.
Ne copiez pas un exemple d’adresse de déclaration ou ne envoyez pas de rapports à un tiers sans approbation. Ne remplacez pas une politique DMARC appliquée par une surveillance uniquement parce qu'une capture d'écran d'intégration le montre p=none. Déterminez si le nouvel expéditeur dispose d’un chemin aligné pris en charge avant de modifier la protection à l’échelle du domaine.
Si un fournisseur demande des enregistrements sous une zone enfant déléguée séparément, publiez-les dans la zone qui a réellement autorité sur cet enfant. Une entrée attrayante dans l’éditeur parent ne remplace pas une délégation. Résolvez la limite de propriété DNS avant d’enregistrer.
Vérifier à deux niveaux techniques
Interrogez chaque serveur faisant autorité pour connaître le propriétaire et le type d'enregistrement complets prévus. Conservez les réponses et comparez le contenu logique TXT , pas seulement l'apparence des citations dans un outil. Vérifiez la clé entière, l'étiquette du sélecteur, toute cible d'alias et les limites du jeu d'enregistrements. Ce n'est que lorsque les réponses faisant autorité sont correctes que vous devez examiner les réponses récursives mises en cache. L'estimation large de la propagation d'un fournisseur ne remplace pas le diagnostic d'un nom de propriétaire incorrect.
Activez ou validez ensuite le service d'envoi à l'aide de son propre workflow et envoyez un message contrôlé. Enregistrez le De visible, l'identité de l'enveloppe, chaque DKIM d= et s=, et les résultats du destinataire de confiance. SPF authentifie l'identité de l'enveloppe ; DKIM vérifie une identité de signature. DMARC a besoin d'un chemin de dépassement aligné avec le De visible sous le mode applicable.
Cas d'échec synthétique : Gandi publie la bonne clé sur rotation1._domainkey.example.com , mais le message utilise s=rotation2 et d=example.com. L’enregistrement rotation1 publié ne peut pas valider cette signature. Le remède consiste à réconcilier le sélecteur de l'expéditeur avec sa publication requise, et non à affaiblir DMARC ou à ajouter une inclusion SPF sans rapport.
Récupérer et fermer la modification
Si la publication interrompt un itinéraire, identifiez le propriétaire exact modifié et restaurez le jeu d'enregistrements précédent approuvé. Ne restaurez pas une zone partagée entière sans comparer les modifications intervenues et les domaines affectés. Conserver les clés précédentes aussi longtemps que le plan de rotation du service de signature l'exige ; La suppression DNS et l’activation de la signature doivent être coordonnées.
Fermez le travail uniquement lorsque la zone active, les réponses DNS prévues, l'activation de l'envoi et l'authentification des messages observée sont d'accord. Il s'agit d'un guide documentaire avec un cas d'échec synthétique. Aucun compte Gandi, requête DNS faisant autorité ou message délivré n’a été utilisé comme preuve réelle. L'administrateur doit recueillir ces observations avant d'approuver l'achèvement de la production.
Empêcher une restauration de zone partagée d'annuler un travail non lié
Le cas écrit GAN-01 suppose que example.com et example.net partagent une zone. Un enregistrement de site Web approuvé ultérieurement a été ajouté après une sauvegarde, alors que le nouveau sélecteur sur example.com est erroné. La restauration de l'intégralité de l'ancienne sauvegarde supprimerait également cette modification de site Web dans la portée liée. Comparez les enregistrements actuels, identifiez la réparation approuvée uniquement par le sélecteur et confirmez les deux propriétaires de domaine avant de l'appliquer. Aucune zone, sauvegarde ou restauration n'a été inspectée ou exécutée ici.
Préserver la limite d’application
RFC 9989 La section 7.4 nécessite DKIM valide, et non SPF seul, pour la publication de domaines. p=reject, et met en garde contre l'interopérabilité du courrier indirect et des listes de diffusion. Un seul test réussi de message direct ne prouve pas que chaque voie légitime est prête à faire l’objet d’une politique plus forte. Conserver la protection approuvée existante tout en diagnostiquant l’écart réel ; tout changement de politique nécessite sa propre décision.