A DMARC La demande de changement doit permettre à une autre personne de déterminer exactement ce qui va changer, quels services pourraient être affectés et comment le succès sera démontré. Une capture d'écran montrant la politique souhaitée ne suffit pas. Préservez la ligne de base et le RRset proposé, puis connectez-les aux flux commerciaux approuvés et à une décision de reprise.
Capturez la ligne de base avec précision
Enregistrez le compte ou le locataire du fournisseur DNS , la zone, le nom du propriétaire, le type d'enregistrement, la valeur complète et la durée de vie. Incluez l’heure et la source de l’observation. Capturez la découverte des politiques DMARC actuelles pour les domaines d'auteur concernés, ainsi que les expéditeurs approuvés et toutes les exceptions non résolues. Préservez les identifiants d’authentification plutôt que de réduire un test à une couleur de tableau de bord.
DMARC peut passer par un succès aligné SPF ou DKIM résultat. Le domaine From visible d’un message et ses identifiants authentifiés comptent donc plus qu’une déclaration générique transmise par SPF . RFC 9989. Pour la publication de domaines p=reject, RFC 9989 les sections 7.4 et 8 exigent séparément des signatures DKIM valides et interdisent de s'appuyer uniquement sur SPF ; le succès au niveau du message ne dispense pas de ce devoir de déploiement. Une passe d'authentification ne certifie pas la demande commerciale et ne garantit pas le placement dans la boîte de réception.
Décrire la différence souhaitée
Indiquez les RRsets exacts avant et après et les noms concernés. Expliquez pourquoi le changement est nécessaire maintenant, quels services ont été testés et quelles preuves restent incomplètes. Conservez les modifications DNS non liées en dehors de la demande afin qu'un approbateur n'approuve pas accidentellement une opération plus large. Identifiez le responsable de la mise en œuvre technique, l’approbateur commercial et le contact d’escalade.
Si les destinations de reporting ou les services délégués changent, évaluez séparément le flux d’informations et la dépendance. Conserver la configuration de réception des rapports nécessaire au suivi prévu. Rapports agrégés sont des observations de récepteur avec des limites de couverture, elles ne peuvent donc pas être le seul signal d'acceptation pour un flux légitime urgent. RFC 9990.
Rédiger des critères d'acceptation observables
Utilisez des critères qui peuvent échouer : le RRset faisant autorité est égal à la valeur approuvée ; les messages critiques représentatifs utilisent les identités prévues et s'authentifient comme prévu ; le destinataire de l'entreprise confirme le résultat attendu ; et la réception des rapports se poursuit. Enregistrez les temps d’observation et distinguez les tests immédiatement disponibles des examens ultérieurs des rapports. Un rapport qui n’est pas encore arrivé ne constitue pas un test réussi.
Définissez les déclencheurs de récupération avant la mise en œuvre. Si un flux critique échoue et que le diagnostic le relie à la modification approuvée, invoquez le plan de récupération approuvé. Préserver l’ancien état et expliquer ses limites. La restauration d'une stratégie n'annule pas instantanément DNS mis en cache ni ne rappelle les messages déjà rejetés. Planifiez l’observation au-delà de la fenêtre de maintenance nominale.
Tester si une requête peut réellement se clôturer
Supposons qu'une demande hypothétique modifie uniquement la politique d'un domaine de paie de p=none à p=quarantine tout en conservant sa destination de reporting et sa durée de vie. L'examen doit toujours lier la référence complète et l'ensemble de RR proposé, le compte et le domaine cibles, l'étendue de la paie approuvée et le plan de redressement. Aucune charge utile réelle, approbation ou changement DNS n'est fourni ici.
Supposons qu’une observation autorisée après modification corresponde à l’état DNS approuvé et qu’un message de paie représentatif s’authentifie comme prévu, mais que le destinataire professionnel n’a pas confirmé la réception et que le rapport global suivant n’est pas encore disponible. Enregistrez les contrôles de configuration et d’authentification séparément des résultats en attente. Attribuer le suivi des reçus au propriétaire de la paie et l'examen des admissions différées au propriétaire déclarant ; ne clôturez pas tous les critères d’acceptation sur la base d’un enregistrement correspondant. Il s’agit de découvertes hypothétiques et non de contrôles exécutés.
Le workflow de changement ci-dessus est une recommandation opérationnelle et non une exigence protocolaire. Les contrôles NIST SP 800-53 Rév. 5 CM-3 et CM-5 fournissent une base générale pour examiner, approuver et restreindre les modifications ; la liaison exacte de la charge utile, les rôles et les champs de transfert sont ici l'implémentation proposée. Catalogue de contrôle NIST.