Un vérificateur DNS peut répondre rapidement à des questions de configuration utiles. Il peut montrer s'il a trouvé un Enregistrement DMARC à un nom particulier, expliquez la stratégie sélectionnée et identifiez la syntaxe ou les résultats de la recherche. Il s’agit d’une preuve précieuse, mais sa portée dépend de ce qu’elle demande et de la manière dont elle interprète la réponse.
Un résultat vert n'est pas un message capturé, un inventaire des expéditeurs ou une garantie que chaque destinataire acceptera le courrier légitime. L'étape suivante consiste à connecter la configuration observée au service métier et à l'identité réelle faisant l'objet de l'enquête.
Demander ce qui a été demandé
Commencez par le domaine saisi dans l'outil et les noms DNS réels interrogés. Pour un message, le domaine visible De est l'identité de départ pour DMARC découverte de politique sous RFC 9989 §4.10.1. La vérification d'un domaine de site Web associé n'est pas équivalente lorsque l'application envoie sous un nom différent.
Conservez l’heure de recherche, le résolveur, la réponse et l’enregistrement sélectionné. Si l'outil suit le courant RFC 9989 découverte, demandez-lui de montrer les preuves pertinentes de la promenade dans les arbres. S'il implémente un autre modèle, enregistrez ce modèle plutôt que de supposer que chaque vérificateur utilise le même algorithme.
Enquête sans dossier permet de distinguer un mauvais nom d'hôte d'une absence réelle à l'emplacement concerné. Une stratégie peut être découverte via des règles parent ou suffixe applicables même lorsqu'aucun enregistrement direct n'existe pour le nom saisi.
Lire correctement les limites des enregistrements
Sous RFC 9989 §4.5, a Enregistrement TXT peut contenir plusieurs chaînes de caractères que DMARC rejoint dans l'ordre avant l'analyse. Cela est différent de plusieurs enregistrements TXT distincts prétendant chacun être une politique DMARC . Un affichage qui enveloppe une valeur longue ou montre plusieurs fragments cités peut donc être trompeur à moins qu'il ne préserve les limites des enregistrements.
Le vérificateur doit distinguer les données TXT non liées des candidats à la politique DMARC et expliquer ce qu'ils ont rejeté. Un problème d’ensemble d’enregistrements n’est pas résolu en ajoutant un autre enregistrement de stratégie à côté de ceux existants.
Vérifiez à la fois la publication faisant autorité et la vue du résolveur lorsque vous étudiez une modification. La mise en cache et les réponses négatives peuvent expliquer différentes observations à différents moments. Un délai d'attente ou une erreur DNS n'est pas la même chose qu'une réponse réussie ne montrant aucune politique.
Utilisez un tableau de preuves avec des inconnues explicites
Ce qui suit est un modèle de sortie original pour un outil de diagnostic hypothétique. Il s'agit d'un exemple synthétique de la façon d'étiqueter des preuves, et non d'un rapport provenant d'un domaine réel.
- Question : Une stratégie est-elle visible au nom interrogé ? ; La recherche DNS uniquement que l'outil peut établir : données TXT renvoyées exactes et état de recherche ; Preuves supplémentaires nécessaires : autres observations pertinentes du résolveur lorsque le timing est important
- Question : Quelle politique cette implémentation sélectionne-t-elle ? ; La recherche DNS uniquement, l'outil peut établir : Sa trace de découverte et l'enregistrement sélectionné ; Preuves supplémentaires nécessaires : implémentation du récepteur et données pour un message spécifique
- Question : La valeur est-elle syntaxiquement valide ? ; La recherche DNS uniquement par l'outil peut établir : le résultat de l'analyse selon la spécification indiquée ; Preuves supplémentaires nécessaires : validation réelle des messages et configuration du service
- Question : Une destination de rapport demandée est-elle autorisée ? ; La recherche DNS uniquement par l'outil peut établir : un résultat de recherche d'autorisation externe pertinent ; Preuves supplémentaires nécessaires : livraison du courrier, traitement des pièces jointes, analyse et examen du rapport
- Question : Est-ce qu'un DKIM clé récupérable pour une entrée sélecteur?; La recherche DNS uniquement que l'outil peut établir : résultat de la recherche de clé publique pour les d et s fournis ; Preuve supplémentaire requise : signature active et vérification de la signature sur un message réel
- Question : Est-ce que tous les courriers légitimes sont authentifiés ? ; La recherche DNS uniquement peut établir : Non établi ; Preuves supplémentaires nécessaires : inventaire de l'expéditeur détenu et preuve d'itinéraire représentatif
Un outil honnête peut avoir confiance dans la requête qu’il a effectuée tout en laissant la dernière question non résolue. Il s’agit là de meilleures informations diagnostiques qu’une large étiquette « entièrement protégée » sans une population de preuves définie.
Ne pas déduire l'envoi actif à partir des clés publiées
Sous RFC 6376 §3.6.2.1 et RFC 6376 §6, une clé DKIM publiée constitue un élément de vérification. Cela ne montre pas qu'un service de production détient la clé privée correspondante, a la signature activée ou utilise cette combinaison d et s. Sans message ou configuration de fournisseur, un outil ne peut pas non plus supposer qu'un sélecteur deviné représente chaque clé utilisée.
Sous RFC 7208 §4.1, SPF L'évaluation DNS peut décrire la politique associée à une identité d'enveloppe sélectionnée et les dépendances qu'elle voit actuellement. Il ne peut pas identifier tous les services légitimes ni prouver l'identité de la source et de l'enveloppe qu'un destinataire a vue lors d'une transaction antérieure.
Utiliser le guide de sélection DKIM et la procédure pas à pas de la chaîne d'identité pour obtenir les identités réelles des messages avant de faire correspondre DNS à un expéditeur.
Considérez le reporting comme un autre chemin complet
Une adresse rua dans une politique valide est une demande de rapport. Sous RFC 9990 §4, DNS peut aider à établir l'autorisation requise pour une destination externe, mais il ne peut pas prouver que les messages arrivent, que les pièces jointes compressées survivent au filtrage, qu'un analyseur les accepte ou que quelqu'un étudie les résultats.
Pour un déploiement réel, vérifiez la collecte séparément et conservez les informations du journaliste et de la période avec les observations. La structure et la livraison du rapport sont décrites dans RFC 9990 §3.1 et RFC 9990 §3.5. Un rapport d'un destinataire participant constitue une preuve utile de cette source de données, et non une preuve de la couverture complète du courrier envoyé. Le guide de reporting-collecte trace ce chemin opérationnel.
Transformez le chèque en décision de service
Supposons qu'un vérificateur trouve une politique surveillée valide tandis qu'une application de reçu utilise un domaine de signature de fournisseur sans rapport. Les résultats DNS peuvent être corrects et les messages de l'application peuvent toujours manquer de chemin aligné. La correction de la configuration réelle du service nécessite une enquête sur les messages reçus ou les itinéraires, et non une autre publication de politique identique.
À l'inverse, une correction nouvellement publiée peut être visible avec autorité avant que le cache négatif d'un autre résolveur n'expire sous RFC 2308 §5. Conservez à la fois les observations et les horodatages. Ne continuez pas à modifier un enregistrement correct simplement pour forcer un accord immédiat entre les vues mises en cache.
Le transfert utile associe le rapport DNS au service exact, aux identités des messages, au propriétaire de l'expéditeur et au test suivant. Gardez visibles les faits observés, les hypothèses de mise en œuvre et les questions de message non résolues. Cela transforme le résultat d’un vérificateur en une étape de diagnostic reproductible au lieu d’une affirmation d’assurance non étayée.
Rendre la prochaine décision explicite
Un outil pourrait véritablement enregistrer « la politique trouvée au nom interrogé ; aucun message fourni ». Conservez la signature DKIM active, le succès du flux de travail aligné et la réception des rapports en tant que résultats en attente distincts. Pour les modifications sensibles au cache, RFC 8767 §4 permet l'utilisation de réponses périmées après expiration, donc une durée de vie n'est pas une garantie de convergence globale. Cet article décrit les preuves à collecter, et non les vérifications exécutées pour un domaine actif.