Une demande de route publiée ne produit pas un recensement complet de chaque destination. Un destinataire peut ne pas participer au reporting, ne pas avoir d'observations pertinentes ou rencontrer un problème de génération ou de livraison. Traitez un journaliste absent comme une question d’enquête, et non comme une preuve de zéro courrier ou de zéro abus.
Définir la population de récepteurs attendue
Commencez par envoyer des journaux et des destinations vérifiées pour l’intervalle en cours d’examen. Regroupez-les par infrastructure de réception réelle lorsque cela est connu ; un domaine de destinataire et une identité de générateur de rapport n'ont pas besoin d'avoir une relation un-à-un. L’hébergement de messagerie et les passerelles externalisés peuvent rendre trompeuse une liste de journalistes basée sur une marque.
Enregistrez ce qui répond à chaque attente : un rapport antérieur, une documentation propriétaire actuelle, une livraison surveillée ou un journal de l'expéditeur. Gardez les hypothèses séparées. N'inventez pas le calendrier ou la capacité de reporting d'un fournisseur à partir du comportement d'un autre fournisseur.
Éliminer les défauts de demande et de recouvrement
Références : RFC 9990 §4, RFC 9990 §3.5.
Vérifiez la politique applicable et la destination rua, puis l'autorisation externe requise. Vérifiez la réception des journaux de boîtes aux lettres, la quarantaine et les échecs de l'analyseur. Si un rapport parvenait au collecteur mais n'était pas affiché, le destinataire faisait un rapport ; l'écart appartient au processus de collecte.
Un nouveau message contrôlé envoyé à une boîte aux lettres de test consentante peut établir qu'un chemin particulier a reçu du courrier. Ses résultats d'authentification fiables aident à diagnostiquer le message, mais ils ne prouvent pas qu'un rapport global sera généré ou arrivera à une heure garantie.
Classer honnêtement l’incertitude
Références : RFC 9990 §3.1, RFC 9989 §5.3.8.
Utilisez des statuts distincts tels que rapport précédent mais en retard, demande invalide, livraison rejetée, échec de l'analyseur et participation non confirmée. Cela empêche différentes équipes de traiter chaque entrée manquante comme la même panne. RFC 9990 décrit un feedback quotidien ou plus fréquent, mais la couverture pratique dépend toujours des systèmes participants réels et du succès de la collecte.
Cas illustratif : les rapports arrivent des destinataires A et B, tandis que les journaux des expéditeurs affichent également le courrier accepté à C. Aucun rapport de C n'est présent. Sans autre preuve, classer C comme non observé dans les rapports globaux. N'attribuez pas un taux d'échec nul à C et ne déduisez pas la mise en œuvre de sa politique à partir des rapports de A.
Prendre des décisions avec les preuves disponibles
Donnez la priorité à la couverture manquante pour les flux critiques, les modifications récentes de l'infrastructure et les récepteurs qui contribuaient auparavant de manière fiable. Utilisez les journaux des expéditeurs, les échantillons de messages autorisés et les diagnostics de livraison pour compléter les rapports. Ne modifiez pas à plusieurs reprises un enregistrement valide simplement pour faire apparaître un journaliste non confirmé.
Publiez à la fois les résultats observés et les limites de la couverture. Si l'absence du séquestre affecte matériellement une décision d'exécution, obtenez de meilleures preuves de cette voie ou documentez l'incertitude restante et le propriétaire de la décision. Le résultat devrait être une cartographie des preuves défendables plutôt qu’une promesse selon laquelle chaque fournisseur de messagerie est représenté.
Tenir à jour le registre des journalistes attendus
Pour chaque destinataire important, enregistrez la raison pour laquelle la participation est attendue, le dernier intervalle observé, le comportement d'arrivée historique et la qualité actuelle des preuves. Séparez un changement de fournisseur vérifié d’une estimation locale basée sur un fichier manquant. Examinez le registre après les migrations d'expéditeurs ou les modifications d'hébergement de destinataires, car l'infrastructure de reporting pertinente peut changer sans changement de l'adresse e-mail du client. Une attente qui ne peut être justifiée doit être qualifiée de non confirmée. Cela donne au prochain analyste un point de départ concret au lieu d’une alerte récurrente et inexpliquée.
Poursuivre l'enquête
Utilisez le procédure pas à pas du rapport agrégé pour interpréter les champs sous-jacents et les guide de diagnostic d'alignement lorsqu'une passe d'authentification brute ne satisfait pas DMARC.
Preuve synthétique exécutée
Ce qui suit est un appareil synthétique hors ligne réexécuté localement, et non une observation DNS , SMTP ou client en direct. Son entrée XML a été analysée avec la bibliothèque standard de Python et les assertions ont vérifié les champs et les calculs résultants. Les étapes DNS et de messagerie simulées sont des entrées de test fournies, et non une preuve qu'un véritable destinataire a effectué ces opérations. La validation complète du schéma et l'authentification de la source de production sont en dehors de ce petit dispositif ; des preuves réelles restent en attente.
La requête fournie est _dmarc.brand.example TXT "v=DMARC1; p=none; rua=mailto:aggregate@collector.example,mailto:archive@archive.example". Ces exemples de domaines réservés sont supposés être des domaines organisationnels distincts dans le luminaire. Les deux réponses d'autorisation synthétique sont brand.example._report._dmarc.collector.example TXT "v=DMARC1" et brand.example._report._dmarc.archive.example TXT "v=DMARC1". Le modèle local correspond à la fois aux noms de propriétaires d'autorisation fournis et à leurs valeurs de version sous RFC 9990 §4. Il n'exécute pas les requêtes DNS ni l'algorithme d'autorisation complet. Une implémentation de production doit effectuer la procédure complète de découverte et d’autorisation plutôt que d’assumer ces limites de domaine.
Le rapport retenu a l'ID R1, le domaine de stratégie brand.example , date_range commençant 1772409600 et fin 1772496000, source IP 192.0.2.10 et compte 100. Son évaluation est alignée DKIM le résultat est réussi et aligné SPF est un échec. Le résultat brut SPF est réussi pour vendor.example , illustrant pourquoi le succès brut n'est pas un succès aligné. Ces champs sont analysés à partir de XML plutôt que déduits d'un tableau de bord.
Le receiver.example de contrôle positif a un reçu accepté simulé et un décompte analysé de 100. Le deuxième récepteur synthétique, unobserved.example , a 20 soumissions d'expéditeur fournies mais aucun reçu ni aucun décompte analysé. L'assertion préserve ce nombre comme nul plutôt que zéro. Le contrôle positif de demande d'analyseur complété montre que le collecteur du modèle peut traiter un rapport ; cela n'établit pas que le destinataire disparu a participé ou tenté la livraison. Une enquête en direct doit obtenir sa propre boîte aux lettres et les preuves de son fournisseur avant de modifier cette classification.
Conserver le résultat dans la portée testée
La démonstration locale fournie vérifie uniquement son petit analyseur synthétique, les entrées de scène fournies et les calculs. Aucune véritable autorisation DNS , livraison SMTP , migration de collecteur, participation du fournisseur ou comportement de la base de données de production n'a été testée. Les entrées originales restent archivées et toute comparaison en direct nécessite ses propres preuves protégées et une approbation responsable.