L'approbation répond à une question différente
Une organisation peut autoriser un fournisseur à envoyer des newsletters, des reçus ou des avis opérationnels. Cette décision commerciale établit une relation prévue ; cela ne prouve pas que chaque message revendiquant l'identité du fournisseur provient du compte approuvé ou que sa configuration d'authentification est correcte. Une étiquette de tableau de bord telle que expéditeur connu doit donc être traitée comme un contexte d'inventaire et non comme un remplacement de preuves techniques.
Commencez par le produit, le compte et l’itinéraire exacts approuvés par le propriétaire. Un seul fournisseur peut envoyer via des domaines par défaut, des domaines personnalisés, une infrastructure déléguée et plusieurs flux de travail distincts. La ligne du rapport étudiée doit être mappée sur l'un de ces itinéraires avec un niveau de confiance explicite. Une plage IP ou un nom de marque familier ne suffit pas à lui seul à rendre le mappage définitif. DMARC évalue l'authentification alignée, et non une liste d'autorisation commerciale. RFC 9989 , section 4.4
Lisez les identités avant de décider ce qui a échoué
DMARC utilise le RFC5322 domaine comme référence pour alignement avec succès SPF ou DKIM authentification. Une transmission SPF brute sur le domaine d'enveloppe d'un fournisseur ne s'aligne pas nécessairement sur le domaine visible De. De même, un valide Signature DKIM peut utiliser un domaine de signature qui n'est pas aligné. Expliquez le succès brut du protocole et l'alignement DMARC dans des champs séparés plutôt que d'étiqueter l'ensemble du message authentifié sans qualification.
Une passe DMARC peut être prise en charge par un mécanisme de passe aligné ; il n'est pas nécessaire que tous les contrôles d'authentification observés soient réussis. À l’inverse, un expéditeur peut être légitime et néanmoins échouer DMARC car sa configuration ou sa gestion intermédiaire empêche une authentification alignée. L'examen doit identifier ce que l'on sait sur SPF , DKIM et l'alignement individuellement avant de recommander un changement DNS ou côté fournisseur. RFC 9989 , sections 4.4 et 5
Traitez les rapports comme des observations avec des limites
Rapports agrégés fournir des observations groupées, pas nécessairement les messages originaux complets ou tous les faits nécessaires pour reconstruire une transaction. Préservez l'organisation de reporting, l'identifiant du rapport, l'intervalle de reporting, les informations sur la politique, l'adresse source, le nombre, les résultats évalués et les domaines d'authentification disponibles. Ne remplissez pas les champs absents avec des hypothèses tirées d'un rapport distinct ou d'un écran de configuration actuel.
RFC 9990 avertit explicitement que les données globales du rapport peuvent être falsifiées. Un rapport ne doit donc pas être traité comme une preuve auto-authentifiée de la relation commerciale qu’il semble décrire. Conservez la provenance de l’ingestion et corroborez les décisions qui en découlent avec des preuves d’itinéraire ou de message autorisé si nécessaire. Un nombre important peut justifier une enquête, mais il ne prouve pas en soi une activité malveillante, des comptes compromis ou un impact financier particulier. RFC 9990 , sections 3.1 et 8.2
Classer l'échec sans effondrer l'incertitude
Utiliser un ensemble de classification pratique : itinéraire approuvé confirmé avec un problème de configuration ; itinéraire probablement approuvé en attente de corroboration ; comportement lié aux intermédiaires nécessitant des preuves de message ; source inconnue ; et des preuves de déclaration insuffisantes ou peu fiables. Il s’agit de catégories de flux de travail proposées, et non de nouveaux résultats du protocole DMARC . Préservez les résultats sous-jacents basés sur les normes à leurs côtés.
Pour un itinéraire confirmé, identifiez le propriétaire de la configuration responsable et l'incompatibilité d'identité exacte ou le problème de signature étayé par des preuves. Pour un itinéraire incertain, rassemblez uniquement les détails de propriété ou de message manquants nécessaires pour le distinguer. Pour une source inconnue, évitez d'ajouter une autorisation simplement parce qu'elle apparaît dans un rapport. Une modification d'inclusion ou de domaine de signature peut autoriser plus que prévu si la relation de compte n'a pas été établie.
N'utilisez pas une classification indéfiniment. Une migration de fournisseur, un changement de produit ou une suppression de compte peuvent rendre obsolète la cartographie d'hier. Enregistrez qui a approuvé l’itinéraire, quand la cartographie a été vérifiée pour la dernière fois et quelles preuves déclencheraient une réévaluation. Il s'agit d'une proposition d'inventaire et d'examen, et non d'une affirmation selon laquelle un système de classification automatisé existe ou a été exécuté.
Feuille de travail du rapport à la décision
Créez une feuille de calcul qui préserve les champs source d'origine et sépare l'interprétation de l'action. La première section doit identifier l'artefact du rapport, l'intervalle, la ligne, le nombre et la provenance de l'ingestion. Le second doit enregistrer l'itinéraire de l'expéditeur revendiqué, le propriétaire de l'entreprise, la portée du produit pris en charge et la confiance dans le mappage. Le troisième doit distinguer SPF brut, DKIM brut, les résultats alignés et l'évaluation DMARC qui en résulte.
Ajoutez une section de décision contenant l'action proposée, la justification, le propriétaire et les preuves encore requises. Les actions possibles incluent demander au fournisseur approuvé de confirmer sa configuration actuelle de domaine personnalisé, obtenir un échantillon de message reçu expurgé via un processus autorisé ou laisser la source non classifiée en attendant des preuves supplémentaires. La rédaction d'un plan d'action n'autorise pas les changements de contact externe ou DNS de production.
L'acceptation nécessite qu'un réviseur suive la chaîne depuis les champs du rapport jusqu'à la classification et l'action suivante sans s'appuyer sur un saut non documenté. Si les données ne permettent pas de distinguer un compte approuvé d'un autre compte utilisant une infrastructure partagée, dites-le. Si la preuve du message original n'est pas disponible, gardez les explications au niveau de la signature provisoires plutôt que d'inventer une version brisée. sélecteur ou un corps altéré.
Diagnostic fictif : reçus approuvés, enveloppe non alignée
Une entreprise fictive a approuvé un service de réception. Une ligne globale fictive signale une réussite SPF pour le domaine d'enveloppe du fournisseur, un échec DKIM et un échec DMARC pour le domaine From de l'entreprise. Supposons que le propriétaire de l'entreprise confirme que cet itinéraire de produit spécifique est prévu, mais qu'aucun message original n'a été obtenu. Il s’agit d’hypothèses illustratives, et non d’un rapport retenu ou d’un véritable diagnostic fournisseur.
L'interprétation retenue est que le succès brut SPF n'a pas établi une authentification alignée pour le domaine d'entreprise affiché, tandis que le résultat DKIM rapporté n'a pas non plus fourni de chemin aligné de passage. L'action suivante consiste à confirmer la configuration de domaine personnalisé et de signature réellement prise en charge par le produit et à obtenir un échantillon expurgé autorisé si nécessaire. Le rapport à lui seul ne justifie pas l’invention d’un sélecteur ou l’ajout d’une inclusion SPF générique au domaine visible From.
Si des preuves ultérieures montrent que la ligne appartenait à un autre locataire sur une infrastructure partagée, le mappage doit changer. L'approbation par l'organisation de son propre compte fournisseur n'autoriserait pas cet autre trafic. Cette possibilité est la raison pour laquelle la feuille de travail enregistre la confiance et la portée du compte au lieu de traiter le nom d'un fournisseur comme une preuve permanente de légitimité.
Preuves manquantes et statut de libération
Aucun rapport, compte, message ou résultat DNS réel n'a été inspecté pour cet exemple fonctionnel. Le catalogue nécessite une procédure pas à pas expurgée du rapport à la décision contenant les champs sources, l'incertitude de classification et l'action suivante. Ces preuves originales restent ouvertes et la visite guidée fictive n'est pas considérée comme une exigence opérationnelle terminée.
Les six portes de libération restent ouvertes. L'examen humain doit vérifier la terminologie de l'identité, l'applicabilité de la source et la portée de la décision proposée avant qu'un changement ne soit approuvé. Une route d'authentification corrigée ne garantirait toujours pas le placement dans la boîte de réception ni ne prouverait qu'une demande professionnelle est sûre. Séparez la délivrabilité, le risque de contenu et la vérification commerciale des résultats d’authentification restreints.