A DMARC Une valeur TXT portant un nom incorrect peut être parfaitement écrite et n'avoir aucun rapport avec le message que vous étudiez. Avant de modifier sa politique, prouvez que le destinataire peut la découvrir pour le domaine utilisé dans l'adresse De visible.
Un piège courant consiste à tester le domaine du site Web de l'entreprise pendant que l'application envoie en tant que sous-domaine. Une autre consiste à saisir un nom complet dans un champ DNS qui ajoute le nom de la zone. Le remède est une comparaison exacte des noms, suivie de preuves DNS faisant autorité.
Dériver le nom de recherche du message
Prenez un message reçu du workflow concerné et identifiez le domaine dans son adresse De. Pour un message synthétique de notices@billing.example.com , la découverte de stratégie initiale interroge TXT à _dmarc.billing.example.com . Un record sur example.com , www.example.com ou le domaine non lié du fournisseur expéditeur n'est pas la même recherche. Si la recherche initiale ne trouve aucune stratégie valide, la découverte peut se poursuivre selon les règles DMARC applicables. RFC 9989 , section 4.10.1.
Ne remplacez pas le Return-Path domaine pour le domaine visible De. Sous RFC 7208 §2.4, l'identité de l'enveloppe est importante pour SPF, mais il ne détermine pas cette recherche initiale de stratégie DMARC . Conservez les deux champs dans des colonnes séparées lors du diagnostic du problème.
Écrivez le nom absolu attendu du propriétaire avant d’ouvrir l’éditeur DNS . Ce petit pas empêche les étiquettes de l’interface utilisateur de devenir la source de vérité.
Trouver la zone faisant autorité et le modèle d'entrée
Identifiez lequel serveurs de noms desservent actuellement la zone concernée. Un compte de bureau d'enregistrement, un tableau de bord d'hébergement ou un service DNS précédemment utilisé peut afficher des enregistrements qui ne font plus autorité. Si billing.example.com est délégué, déterminez qui contrôle cette zone enfant avant de modifier la zone parent.
Consultez l'aide de l'éditeur pour son champ Nom ou Hôte. Certaines interfaces acceptent les noms relatifs ; certains acceptent les noms complets et les normalisent. Une convention de fichier de zone n'est pas une promesse concernant un formulaire Web. Dans les fichiers maîtres DNS , un nom se terminant par un point est absolu, tandis qu'un nom relatif est interprété en utilisant l'origine actuelle. RFC 1035 , section 5.1.
À titre d'exemple d'interface utilisateur documenté, le flux de travail d'enregistrement actuel de Cloudflare indique de choisir le type d'enregistrement et de remplir les champs obligatoires, qui varient selon l'enregistrement. Utilisez les instructions d'enregistrement actuelles du fournisseur et vérifiez le résultat enregistré plutôt que d'y projeter le comportement de terrain d'un autre fournisseur. Gestion des enregistrements DNS Cloudflare.
Réglez le cas du nom doublé
Prenons un éditeur illustratif configuré pour la zone example.com qui ajoute la zone à chaque valeur de nom relative. Entrer _dmarc.example.com comme valeur relative créerait _dmarc.example.com.example.com . Un validateur pointant vers ce nom accidentel pourrait trouver un enregistrement, alors que la recherche _dmarc.example.com prévue n'en a aucun.
Comparez explicitement trois éléments :
- Propriétaire absolu prévu : _dmarc.example.com .
- Propriétaire enregistré affiché par le service DNS ou l'exportation de zone.
- Réponses TXT faisant autorité pour les noms accidentels prévus et suspectés.
Si la réponse erronée contient la politique souhaitée, conservez-la comme preuve. Publier ou corriger le dossier approuvé chez le propriétaire prévu, en prenant soin de ne pas y introduire un deuxième candidat DMARC . Supprimez l’enregistrement erroné via le contrôle normal des modifications après avoir vérifié qu’il n’a pas d’utilisation prévue séparément. Ne considérez pas un exemple de nom de cet article comme votre domaine de production.
Vérifier la réparation sans faux délai
Demandez au service faisant autorité le propriétaire exact et le type d’enregistrement. Comparez ensuite la réponse d'un résolveur récursif, en notant l'horodatage, l'état de la réponse et la durée de vie. Si le nom souhaité n’existait pas auparavant, un cache négatif peut continuer à renvoyer ce résultat antérieur pendant sa durée de vie restante. Un TXT TTL positif nouvellement choisi n'efface pas un ancien cache négatif. RFC 2308 §3, RFC 2308 §4 et RFC 2308 §5.
L'utilisation admissible de réponses périmées peut continuer au-delà de l'expiration de la durée de vie sous RFC 8767 §4, le TTL n'est donc pas une date limite de convergence mondiale. Une notification d'enregistrement du tableau de bord confirme l'action du formulaire, et non la visibilité globale. De même, une réponse DNS publique correcte n’établit pas que votre service signe le courrier avec un domaine aligné. Envoyez un nouveau message via l'itinéraire d'origine et inspectez le résultat fiable du système de réception.
Résolvez le problème de dénomination séparément de l'authentification du courrier
Conservez le nom du propriétaire d'origine, le propriétaire corrigé, la valeur approuvée et les horodatages de test dans l'enregistrement des modifications. Si DMARC s'applique maintenant mais que le message échoue, continuez avec diagnostic d'identité et d'alignement. C'est un progrès : l'enregistrement peut être trouvé et le problème restant appartient au chemin d'envoi.
Si les récepteurs semblent toujours découvrir des politiques différentes, comparez leurs domaines From, leurs réponses DNS et leur comportement de mise en œuvre observés. Ne continuez pas à déplacer un enregistrement correct entre des noms simplement pour mettre d'accord deux contrôleurs non liés.
Enregistrer une décision pouvant être révisée
Pour l'appareil à nom doublé, comparez les noms absolus prévus et enregistrés avant de modifier la valeur TXT . Une police valide trouvée chez le propriétaire accidentel ne montre pas que la recherche initiale prévue la trouve. Conservez l’enregistrement accidentel comme preuve, puis utilisez les actions de correction et de suppression approuvées séparément. Il s'agit d'un modèle d'éditeur illustratif et non d'une affirmation selon laquelle Cloudflare ajoute des noms de cette manière ou qu'une modification DNS a été effectuée.