Deux parties établissent le lien hiérarchique
Publication d'une destination de reporting dans un domaine DMARC la politique exprime la demande du propriétaire du domaine. Il n’est pas nécessaire qu’une destination indépendante accepte les rapports résultants. Vérification externe de la destination empêche les destinataires d'être sélectionnés comme cibles de rapport involontaires. Le côté récepteur publie l'autorisation via DNS , tandis que le côté rapporteur vérifie cette autorisation avant d'utiliser la destination externe.
RFC 9990 applique sa procédure de vérification lorsque le Domaine organisationnel la comparaison montre une destination externe pour les rapports agrégés. Ne remplacez pas cette règle par un test simpliste indiquant que les chaînes de l'adresse d'expéditeur et de l'adresse du rapport diffèrent. Le domaine de politique découvert, l'hôte de destination et le contexte du domaine organisationnel doivent être conservés afin que la décision d'effectuer une vérification soit reproductible. RFC 9990 , section 4
Construisez le nom du propriétaire dans le bon ordre
Extrayez l’hôte de destination de l’URI de rapport. Ajoutez _report au début. _dmarc , puis ajoutez le nom de domaine à partir duquel la stratégie a été récupérée, en convertissant ce domaine en étiquette A si nécessaire. Le propriétaire DNS résultant a le formulaire Policy-domain._report. _dmarc.destination-host. Il est interrogé pour Enregistrements TXT. Si le nom construit dépasse les limites DNS , une détermination d'autorisation positive ne peut pas être effectuée.
Cette construction utilise le domaine réel à partir duquel la politique a été récupérée. Ne le réduisez pas à un parent familier simplement parce que ce parent ressemble à la marque de l'organisation. De même, la partie locale d'une adresse mailto n'est pas insérée dans le nom du propriétaire DNS . Conservez l'URI d'origine et l'hôte de destination analysé afin que les réviseurs puissent voir comment le nom construit découle des entrées. RFC 9990 , section 4
Validez la réponse plutôt que de reconnaître une chaîne familière
Les enregistrements renvoyés sont analysés sous forme de listes de valeurs de balises. La balise obligatoire v=DMARC1 doit apparaître en premier et un point-virgule final est facultatif. Les enregistrements qui échouent au test d'analyse spécifié sont supprimés. Au moins un enregistrement éligible restant établit le dispositif de reporting externe dans le cadre de la procédure. Une réponse vide, une valeur TXT sans rapport ou un enregistrement avec une mauvaise version, le placement n'établit pas l'autorisation.
La valeur de la version DMARC est sensible à la casse : DMARC1 est la valeur requise, et non une approximation en minuscules ou une version de protocole nouvellement inventée. Les règles de comparaison des noms DNS ne doivent pas être confondues avec l'exigence de casse de la valeur de version. Une révision doit conserver les octets de réponse exacts et les limites d'enregistrement au lieu de normaliser les détails avant la validation. RFC 9990 , section 4; RFC 9989 , sections 4.7 et 4.8
Respecter les comportements de dépassement et de défaillance
Un enregistrement d'autorisation peut fournir un remplacement de destination de déclaration dans le cadre de la procédure. L'URI de remplacement doit utiliser le même hôte de destination extrait au début. Cette restriction empêche une réponse d'autorisation de rediriger le processus vers une chaîne de destinataires non liés. Si la confirmation contient un remplacement avec un hôte différent, le générateur de rapport ne doit pas générer de rapport sur l'URI d'origine ou de remplacement.
Si la vérification ne confirme pas l’autorisation, l’URI externe doit être ignoré. Une erreur DNS temporaire a son propre traitement : le destinataire peut choisir d'échouer temporairement la livraison afin que le test de vérification puisse être répété ultérieurement. Conservez cette autorisation comme MAY, et non comme une garantie de nouvelle tentative universelle ou une description d'une implémentation testée. Une vérification DNS réussie ne prouve toujours pas que la boîte aux lettres de destination existe, accepte la taille du rapport ou alimente le tableau de bord client prévu. RFC 9990 , section 4
Distinguer les demandes de rapports d'agrégation et d'échec
Pour rapports agrégés, la procédure est associée à rua. Le rapport d'échec est spécifié séparément dans RFC 9991. Pour les destinations de rapport d'échec externe, ce document nécessite la même procédure de vérification externe avec ruf remplacé partout où rua apparaît. Ne considérez pas le rapport d'échec comme automatiquement activé simplement parce que des rapports agrégés circulent, ni ne copiez la gestion de la destination agrégée sans reconnaître le type de rapport distinct.
Rapports d'échec soulèvent des préoccupations supplémentaires concernant l’exposition des données, car leur contenu peut être plus détaillé que les résumés globaux. Un enregistrement d'autorisation DNS correct ne remplace pas la décision d'une organisation quant aux données qui peuvent être partagées, avec qui et dans quel but. Ce manuscrit ne fournit aucune autorisation pour demander, transmettre ou télécharger des rapports réels. Toute configuration réelle doit satisfaire aux approbations applicables en matière de confidentialité, de destinataire et de fonctionnement. RFC 9991 , sections 5 et 7
Feuille de travail de construction et d'acceptation fictive
Supposons qu'une politique fictive ait été récupérée sur blue.example.com et demande des rapports agrégés à mailto:reports@red.example.net. Le propriétaire de l'autorisation construite est blue.example.com._report._dmarc.red.example.net . Une réponse TXT hypothétique dont la valeur complète est v=DMARC1; satisfait à l’exigence de version illustrée en premier. Aucune requête DNS n'a été exécutée et cet exemple ne prétend pas que les noms ont des enregistrements publiés.
La feuille de calcul doit conserver le résultat de la recherche de stratégie, le domaine de stratégie découvert, l'URI de rapport d'origine, l'hôte de destination, la comparaison de domaine organisationnel, le propriétaire construit, le type de requête, l'horodatage, les enregistrements exacts renvoyés et le résultat de l'analyse. Ajoutez un champ distinct pour tout remplacement et confirmez sa restriction d'hôte. Un réviseur devrait être capable de reconstruire le nom sans s'appuyer sur une capture d'écran du fournisseur ou sur l'affichage abrégé d'un éditeur DNS .
Utilisez une deuxième section d'acceptation pour la collecte : compte prévu, boîte aux lettres de destination, type de rapport autorisé et propriétaire du pipeline. Ces champs décrivent un flux de travail de vérification planifié, et non une preuve d'ingestion terminée. Gardez le résultat de la relation DNS distinct de la réception, de l'analyse, de l'attribution du locataire et de la présentation du tableau de bord. Une vérification d'autorisation peut réussir alors qu'une autre partie du chemin de collecte reste non résolue.
Publication et mise en œuvre en attente
Le catalogue nécessite la construction de la recherche d'autorisation exacte à partir des domaines source et de destination et la vérification de sa réponse. Ce projet fournit uniquement une construction fictive. Une réponse réelle, la transcription originale de la requête et la mise en œuvre du domaine de réception restent ouvertes. Aucun enregistrement DNS n'a été publié, aucune boîte aux lettres n'a été consultée et aucun rapport n'a été transmis.
Avant la publication en tant que procédure opérationnelle pas à pas, obtenez des preuves autorisées de la relation de production exacte et demandez à un réviseur qualifié de confirmer le contexte de découverte des politiques, l'analyse des versions et la gestion des remplacements. Conservez la date source et distinguez les exigences des normes de l’intégration de comptes spécifiques au fournisseur. Les six portes de publication restent ouvertes, y compris les preuves originales, l'examen humain, l'applicabilité des sources, les itinéraires de production, l'accessibilité visuelle et la libération du propriétaire.
Une modification ultérieure du domaine de destination ou de découverte de stratégie peut modifier le propriétaire de l’autorisation requis. Traitez-le comme une nouvelle relation étendue à vérifier plutôt que de supposer qu'un ancien contrôle positif couvre chaque future adresse de déclaration. Le résultat utile est une chaîne d'autorisations vérifiable, et pas simplement une valeur TXT copiée.