Sous RFC 9989 §4.7, a DMARC politique de p=none n'exprime aucune préférence de gestion du propriétaire de domaine pour les échecs DMARC . Lorsque les rapports sont configurés et examinés, cela crée une opportunité de savoir quels services utilisent le domaine, où les messages légitimes échouent et quel impact un changement de politique pourrait avoir.
La surveillance devient utile grâce à l'enquête. Les rapports doivent parvenir à un système de collecte, les sources ont besoin de propriétaires et les échecs non résolus ont besoin de décisions. Le temps écoulé ou un pourcentage de réussite élevé ne peuvent pas établir que chaque service important a été couvert.
Rendre la collecte de reporting observable
Pour un domaine commençant un déploiement surveillé, une politique illustrative est la suivante :
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.comL'exemple suppose le prévu _dmarc publication et une adresse de collection fonctionnelle du même domaine. Si le domaine dispose déjà d'une politique approuvée plus stricte, ne l'affaiblissez pas simplement pour suivre un exemple. Utiliser le flux de travail d'enregistrement pour vérifier la configuration réelle.
Suivant RFC 9990 §4 pour une autorisation externe et RFC 9989 §5.3.8 pour le reporting du destinataire, vérifiez la destination du reporting, toute autorisation de destination externe requise, la livraison du courrier et l'analyse. Conservez l’identité du journaliste, la période et l’historique de configuration pertinent. La réception de rapports d'un fournisseur démontre un cheminement de travail pour cette observation ; cela ne prouve pas une couverture universelle.
Classer les services et préserver l’incertitude
Pour chaque modèle source significatif, étudiez l'application, le compte ou l'itinéraire spécifique au client, le domaine visible depuis, l'identité de l'enveloppe, l'identité de signature et le propriétaire.
Utilisez des catégories de travail claires :
- Catégorie : Service approuvé avec le chemin aligné attendu ; Action suivante : Conserver la propriété et surveiller les modifications
- Catégorie : Service approuvé ayant échoué à l'authentification ou alignement; Action suivante : Corriger et tester la configuration prise en charge
- Catégorie : Voie indirecte légitime ; Action suivante : Analyser les renvois, les modifications et la gestion des destinataires
- Catégorie : Source inconnue ; Action suivante : Préserver l’incertitude et enquêter
- Catégorie : Utilisation non autorisée confirmée ; Action suivante : enregistrer les preuves à l’appui et la réponse
Le nom d’un fournisseur de cloud, ASN ou le pays ne suffisent pas pour approuver un expéditeur. De même, une ligne défaillante ne suffit pas à déclarer chaque message associé comme malveillant.
Exemple concret : une fenêtre silencieuse manque la paie
Prenons un exemple d'organisation qui examine dix jours de courrier des employés et de marketing. Les rapports semblent sains. Aucun service de paie mensuelle n'a été envoyé pendant cette période et sa configuration de signature n'a pas été testée.
La conclusion correcte est que les cours d’eau observés semblaient sains au cours de ces dix jours. Ce n’est pas que l’ensemble du domaine soit prêt pour une politique plus restrictive.
L’équipe peut enquêter et tester directement le parcours de paie, identifier tout autre service périodique et élargir ses preuves. Les fenêtres d'observation doivent refléter les cycles économiques réels et les considérations d'interopérabilité pertinentes, plutôt qu'un nombre universel choisi dans un tableau de bord.
Choisissez une politique adaptée au domaine
La décision est plus large qu’un objectif de taux de réussite. Exigez une couverture des services critiques, des propriétaires responsables, une population de courrier indirect évaluée, des pannes à fort impact résolues et un processus de récupération.
RFC 9989 §7.4 met explicitement en garde contre p=reject pour le courrier électronique à usage général et traite des domaines dont les utilisateurs participent à des listes de diffusion Internet. Ses orientations en matière d'interopérabilité comprennent des étapes spécifiques d'observation et de comparaison pour ces domaines. Ne remplacez pas ces conseils par une promesse générique selon laquelle chaque domaine surveillé devrait éventuellement être rejeté.
Un domaine d'envoi transactionnel étroitement contrôlé et un domaine utilisé pour la correspondance de l'état-major peuvent avoir des contraintes de fonctionnement différentes. Séparez les flux d’identité là où cela répond à un véritable objectif de gouvernance, tout en vérifiant la configuration résultante et les messages réels.
Définir les preuves pour la prochaine décision
Un examen de l’application de la loi devrait répondre à ces questions avec des preuves :
- Les services légitimes importants sont-ils identifiés, détenus et testés ?
- Chaque service concerné dispose-t-il d'un chemin aligné pris en charge ?
- Les flux périodiques et de faible volume ont-ils été pris en compte ?
- Les listes de diffusion, les transferts et autres itinéraires indirects sont-ils compris ?
- La couverture des rapports est-elle décrite sans la traiter comme tous les e-mails envoyés ?
- Les exceptions sont-elles limitées, détenues et planifiées pour examen ?
- L’équipe peut-elle approuver, vérifier et récupérer du changement proposé ?
La décision peut être d'améliorer un expéditeur, de modifier la séparation des domaines, de poursuivre la surveillance ou d'appliquer une politique adaptée à l'utilisation documentée du domaine. Conservez le raisonnement avec l'enregistrement des modifications.
Attribuer des propriétaires aux résultats
Demandez ce que l’équipe espère apprendre et qui agira en fonction des résultats. Quels services envoyer pour l'entreprise ? Quels messages critiques échouent ? Quels expéditeurs apparents restent non identifiés ? Quelles preuves détermineront la prochaine étape ?
Incluez le travail hors de la vue immédiate de l’équipe informatique. Une notification mensuelle de paie ou un avis de renouvellement annuel peut être important tout en contribuant très peu au total global du message.
Évitez un compte à rebours automatique vers une politique plus forte. Une semaine avec peu d'échecs visibles peut signifier un envoi sain, des rapports incomplets ou un service qui n'a pas encore envoyé. Payez pour un inventaire maintenu et des résultats clôturés, pas simplement pour les jours écoulés.
Poursuivre la surveillance après un changement de politique
Les nouveaux logiciels, les changements de fournisseurs, la rotation des clés et les modifications DNS peuvent créer de nouvelles lacunes. Continuez à enquêter sur les nouveaux expéditeurs et les échecs légitimes après tout changement de politique.
Expliquer le risque résiduel aux chefs d'entreprise : les séquestres conservent leurs propres choix de traitement sous RFC 9989 §5.4, et l'authentification de domaine n'empêche pas tout message similaire, compromission de compte ou demande frauduleuse. Pour l’interprétation des preuves, utilisez la procédure pas à pas du rapport global. Pour un échec de passe brute, utilisez le guide d'alignement.
Les plats pratiques à emporter
Le résultat de la surveillance devrait être un inventaire des expéditeurs détenus, des itinéraires critiques vérifiés et une décision politique motivée. Continuez à surveiller à mesure que l'environnement évolue afin qu'un changement ultérieur d'application, de clé ou de passerelle ne rouvre pas discrètement les mêmes lacunes.
Enregistrer la décision et ses limites
Pour la fenêtre fictive de dix jours, laissez la paie mensuelle comme non testée plutôt que de la marquer comme saine. Ajoutez son propriétaire, le prochain flux de travail représentatif et les preuves nécessaires pour combler l'écart. Si la collecte fonctionne mais que la demande n'a jamais été envoyée, une analyse plus approfondie des mêmes rapports ne pourra pas établir son authentification. Aucun rapport ni test de paie n'a été collecté pour cette illustration.