Définissez d'abord la question et le destinataire
Un fournisseur peut avoir besoin de preuves pour diagnostiquer un problème de signature, un alignement mismatch or a reporting discrepancy. Il a rarement besoin de chaque rapport pour chaque domaine de l’organisation. Commencez par énoncer la question exacte, le produit et le compte concernés, le destinataire prévu et la décision que les preuves doivent permettre. This prevents a request for “the DMARC données » de devenir une divulgation inutilement large.
Confirmez que le destinataire est le contact d'assistance ou d'ingénierie autorisé pour le service concerné. Un nom d’affichage familier ou une demande transférée ne suffit pas pour établir que chaque pièce jointe doit y être envoyée. La rédaction d'un dossier est distincte de l'autorisation de le transmettre. Cet article décrit uniquement la préparation et n'autorise pas l'e-mail, le téléchargement ou le partage externe.
Gardez la portée liée à l’itinéraire et à l’intervalle concernés. Un fournisseur examinant son propre flux de réception ne devrait pas recevoir de courrier électronique, marketing ou autre trafic de fournisseur non lié simplement parce que ces observations occupent le même fichier agrégé.
Comprendre ce que le rapport peut révéler
Rapports agrégés contiennent des observations techniques et des informations politiques qui peuvent révéler des aspects de l'infrastructure et du trafic de l'expéditeur. RFC 9990 discute des considérations de confidentialité pour les destinataires et les données du rapport. Même lorsqu'un champ n'est pas un corps de message, il peut s'avérer inutile pour la tâche du fournisseur. Traitez la minimisation comme une décision champ par champ plutôt que de supposer que toutes les informations agrégées sont inoffensives.
Rapports d'échec avoir une surface d'exposition distincte et potentiellement plus détaillée sous RFC 9991. Ne les regroupez pas avec des résumés globaux sous une approbation générique pour les « rapports ». Identifiez explicitement le type de rapport, son contenu et l’objectif du destinataire. Si une question de diagnostic peut recevoir une réponse avec un résumé plus petit ou un extrait rédigé, préférez-le à un artefact brut complet. RFC 9990 , sections 7.1 et 7.2; RFC 9991 , sections 7.1 et 7.2
Créer une carte de champs de données avant la rédaction
The field map should list each candidate item, why it is needed, whether an exact value is necessary, the proposed treatment and the consequence of removing it. Les éléments potentiels incluent le domaine From pertinent, le domaine de signature, sélecteur, domaine de l'enveloppe, adresse source, intervalle de rapport, nombre et résultat de l'évaluation. Their necessity depends on the question; il n’existe pas de paquet universel qui devrait toujours être envoyé.
Certaines identités techniques exactes peuvent être nécessaires pour diagnostiquer l’alignement ou localiser une configuration spécifique au compte. Si ces valeurs ne peuvent pas être partagées dans le cadre du périmètre approuvé, expliquez la limite du diagnostic plutôt que de les remplacer par des valeurs trompeuses. D'autres identifiants peuvent être supprimés ou systématiquement pseudonymisés tout en préservant les relations. Conservez un mappage privé uniquement lorsque cela est nécessaire et autorisé, et ne l'incluez pas dans le package du fournisseur par défaut.
Supprimez les lignes et domaines non liés, les adresses de destinataires inutiles, le contenu des messages, les notes internes et les secrets. N'incluez jamais de mots de passe, de clés API, de jetons de session ou d'informations d'identification dans un artefact de support. Examinez les noms de fichiers, les métadonnées, les captures d'écran et le contenu masqué des feuilles de calcul ainsi que le texte visible ; un paragraphe rédigé ne garantit pas que la pièce jointe soit minimisée.
Préserver les relations diagnostiques
Un échantillon de preuves utile doit conserver la distinction entre les résultats bruts de l’authentification et l’alignement. If the question concerns why DMARC failed, replacing every domain with the same placeholder can erase the relationship the vendor needs to understand. Preserve whether identities are equal, related or different, and clearly label synthetic replacements so they are not mistaken for real DNS names to query.
Conservez ensemble l’intervalle de reporting, les champs de résultats pertinents et les notes de périmètre. Si seules les lignes sélectionnées sont partagées, indiquez que l'échantillon est filtré et identifiez la règle de sélection. Ne modifiez pas un résultat pour simplifier l’exemple et n’impliquez pas qu’un nombre filtré représente le trafic total de l’organisation. Si nécessaire, fournissez une explication concise de l’analyste à côté des champs retenus. RFC 9989 , section 4.4; RFC 9990 , section 3.1
Feuille de travail d'approbation et de conservation
Prepare an approval record with recipient, organization, product, purpose, exact files or fields, affected domain or route, time interval, sensitivity, transfer method and retention decision. Déterminez si le fournisseur peut conserver le matériel uniquement pour le cas, l'utiliser à d'autres fins ou le partager ultérieurement. Ne présumez pas qu’une relation de support générale autorise une réutilisation sans rapport ou un accès étendu.
La décision de conservation doit porter à la fois sur la copie du fournisseur et sur la copie de travail de l'organisation. Enregistrez la durée prévue ou le déclencheur de suppression et qui peut vérifier l'achèvement lorsque cela est important. Il s'agit d'un processus de gouvernance proposé et non d'une affirmation selon laquelle un contrat avec un fournisseur prévoit déjà des conditions spécifiques. Si les conditions disponibles ou l'accès du destinataire ne sont pas clairs, résolvez le problème avant la transmission.
L'acceptation nécessite qu'un examinateur compare le package final à la carte de terrain approuvée. La pièce jointe réelle, et pas seulement une description, doit être vérifiée pour détecter les lignes sans rapport, les données cachées et les secrets accidentels. A changed recipient, expanded dataset or new purpose should trigger renewed review rather than being treated as a harmless continuation of the same share.
Package de support fictif pour une route de signature
Imaginez un fournisseur de reçus fictif enquêtant sur un DKIM échec. Le rapport global brut de l'organisation contient également les courriers des employés et les observations sur les campagnes. Aucun rapport réel ou demande de fournisseur n'a été consulté pour cet exemple. Le package proposé contient uniquement les lignes de réception-itinéraire pertinentes, l'intervalle de déclaration limité, les relations d'identité pertinentes et une brève explication de ce qui est incertain.
Les lignes employé et campagne sont exclues car elles ne répondent pas à la question du fournisseur. Si le fournisseur a besoin d'un domaine de signature ou d'un sélecteur exact, l'organisation doit approuver ces valeurs pour ce destinataire et cet objectif. Un échantillon expurgé qui les obscurcit peut toujours être utile pour une discussion conceptuelle mais ne peut pas être présenté comme suffisant pour un diagnostic DNS en direct.
L'approbation finale enregistre également une décision de conservation spécifique au cas. Aucun colis n'est envoyé simplement parce que le brouillon est complet. Si le fournisseur demande ultérieurement des échantillons complets de messages, il s'agit d'une nouvelle demande de contenu avec un profil de confidentialité différent, surtout si elle introduit des destinataires ou des corps de message. La prochaine étape est un examen ciblé, et non une expansion automatique.
Statut des preuves et de la publication
Le catalogue nécessite une carte des champs de données et un échantillon de preuves minimal approuvé avec une décision de conservation explicite. Cet article fournit uniquement une méthode de préparation et une conception d’emballage fictive. Aucun échantillon réel n'a été approuvé, aucun destinataire résolu et aucune transmission ou suppression de fournisseur n'a été vérifiée.
Les six portes de libération restent ouvertes. Un évaluateur qualifié doit vérifier que la minimisation proposée préserve la question diagnostique tout en respectant les limites de destinataires et d'objectifs. Avant tout partage réel, obtenez l'autorisation requise pour les données réelles et la destination. Un brouillon préparé en toute sécurité constitue un progrès précieux, mais cela ne constitue pas une preuve que le fournisseur a reçu ou traité quoi que ce soit.