A DKIM la configuration est terminée lorsque le service signe le courrier prévu et qu'un destinataire peut le valider. Un statut DNS vert à lui seul n’établit aucun des deux résultats. Choisissez TXT ou CNAME du modèle de gestion des clés pris en charge par le fournisseur, plutôt que de les traiter comme des moyens interchangeables de coller une clé.
Identifier qui gère la clé
Une publication directement Enregistrement TXT transporte les données de vérification DKIM . Avec un arrangement CNAME , le sélecteur name donne un alias à un autre nom DNS où les données de vérification sont gérées. La clé de signature privée appartient au système de signature, jamais dans les archives publiques. RFC 6376 §3.6 et RFC 6376 §6.1.2 décrire la découverte et la récupération de clés ; Le comportement des alias DNS est défini dans RFC 1034 §3.6.2.
Procédure de domaine personnalisé Microsoft 365 utilise les enregistrements CNAME et les destinations générées par le locataire. Sa documentation actuelle est un exemple de la raison pour laquelle la copie d'un ancien modèle cible n'est pas sécurisée. Obtenez les valeurs affichées pour le locataire réel et le domaine sélectionné. Cet exemple n'implique pas qu'un service indépendant accepte les mêmes enregistrements.
Avant de modifier DNS , enregistrez le compte d'envoi, le domaine visible depuis, le domaine de signature prévu, les noms des sélecteurs, le type d'enregistrement, les valeurs générées exactes et le propriétaire responsable. Demandez quel système effectue la rotation et qui supprime la délégation à la fin du contrat. Si le fournisseur ne peut pas utiliser le domaine de signature requis, la modification du type d'enregistrement DNS ne créera pas cette fonctionnalité.
Publier au nom du propriétaire correct
Une signature illustrative avec d=example.com et s=billing mène à billing._domainkey.example.com. L'exemple identifie un nom de propriétaire DNS , et non une clé publique fonctionnelle ou une cible CNAME de production.
Vérifiez si l'interface DNS attend ce nom complet ou uniquement facturation. _domainkey. Certaines interfaces ajoutent le nom de la zone. Relisez le nom du propriétaire résultant au lieu de supposer que la zone de saisie l'a conservé. Inspectez les données existantes avant de modifier le nom. Un CNAME classique ne peut pas y coexister avec un enregistrement de clé TXT distinct ; conservez les sélecteurs non liés et suivez la procédure de migration prise en charge par le fournisseur.
Pour TXT , publiez la valeur publique exacte dans la représentation prise en charge. Pour CNAME , utilisez la destination générée, et non une clé copiée découverte aujourd'hui sur la destination. Copier localement la clé actuelle peut rompre le modèle de rotation ultérieur du fournisseur. Conservez les captures d'écran ou les enregistrements exportés dans l'enregistrement des modifications, à l'exclusion des informations d'identification et des clés privées.
Vérifier la résolution et l'envoi réel séparément
Recherchez le nom exact du propriétaire par rapport DNS faisant autorité, puis vérifiez la résolution récursive via le chemin que les destinataires utiliseront. Pour CNAME , suivez l'alias jusqu'au résultat TXT final et enregistrez tout délai d'attente ou cible manquante. Autorisez les anciennes données mises en cache, y compris les réponses négatives, lors de l’interprétation d’un désaccord. La publication et la convergence du cache global sont des observations différentes.
Envoyez ensuite un message contrôlé via l'application réelle. Conservez ses en-têtes bruts et le résultat de l'authentification du système de réception approuvé. Enregistrer d=, s= et vérification DKIM . Vérifier alignement avec le domaine From visible séparément. Une signature valide provenant d'un domaine appartenant à un fournisseur peut n'avoir aucun rapport avec l'identité du client que vous vouliez authentifier.
Si DNS est résolu mais que le courrier n'est pas signé, étudiez l'activation et le routage du service. Si la signature nomme un sélecteur différent, inspectez ce sélecteur plutôt que de modifier à plusieurs reprises l'enregistrement inutilisé. Si la vérification échoue après la modification du contenu, changer TXT en CNAME n'est pas la réparation.
Gardez la dépendance responsable
Clôturez la modification uniquement lorsque l'enregistrement, le signataire et les preuves reçues sont d'accord. Stockez la configuration précédente et un plan de récupération autorisé avant le basculement. Lors du départ, arrêtez l'intégration d'envoi et supprimez délibérément sa dépendance de vérification, en tenant compte du courrier légitime toujours en transit. Ne laissez pas indéfiniment un alias de fournisseur inexpliqué et ne supprimez pas un sélecteur actif simplement parce qu'une feuille de calcul de contrat indique que le service est terminé.
Lecture connexe
Délégation DNS DKIM : évaluer l’étendue du contrôle accordé à un fournisseur · Syntaxe de clé publique DKIM : identifiez les valeurs DNS tronquées ou mal formées.
Appliquer la distinction
Utilisez un dossier d'acceptation en trois parties : propriétaire/type/valeur publié et durée d'observation ; d/s réels reçus et vérification fiable ; alignement avec le domaine d'auteur prévu. Si DNS est correct mais que le courrier n'est pas signé, étudiez l'activation ou la sélection de l'itinéraire au lieu de modifier le type d'enregistrement. Si un sélecteur différent est émis, suivez cette preuve. La liste de contrôle est un travail de révision proposé, et non un test DNS ou de messagerie effectué.