Comment enquêter sur un rapport XML agrégé DMARC
Lisez les comptes de source et les résultats alignés, comparez-les avec un inventaire d'expéditeur, et évitez de confondre l'échec du DMARC avec une attaque confirmée.
Définir la question et la fenêtre de rapport
Commencez par une question précise : est-ce qu'un expéditeur connu échoue à l'alignement ou a-t-il une source inconnue dans les rapports sélectionnés? Écrivez l'organisation déclarante, le domaine politique et la plage de dates avant de combiner les fichiers. Un rapport global résume les observations d'un destinataire; il ne s'agit pas d'un registre complet de chaque message envoyé par votre organisation. Les récepteurs manquants et les comptes rendus des lacunes sont importants. Gardez le rapport original à côté de vos notes afin qu'un examinateur ultérieur puisse inspecter les mêmes preuves. Un nombre élevé sans fenêtre de déclaration définie est difficile à comparer avec un changement dans votre activité d'envoi.
Ouvrez le XML que le lecteur prend en charge
Le lecteur de rapports agrégés DMARC accepte un document XML complet ou des fichiers XML UTF-8 sélectionnés. Extraire d'abord les archives compressées : les contenus ZIP et GZIP ne sont pas analysés directement. L'interface actuelle supporte jusqu'à vingt fichiers, cinq mégaoctets au total et vingt mille enregistrements. L'entrée de fichier remplace le XML collé. Examiner les fichiers sélectionnés avant de lancer l'analyse. Le traitement reste dans votre navigateur, mais cela n'établit pas l'authenticité du rapport. Utilisez les rapports reçus par le biais de votre flux de travail normal et conservez leur provenance plutôt que de traiter un fichier XML téléchargé arbitraire comme faisant autorité.
Alignement distinct d'une passe d'authentification brute
DMARC relie l'authentification SPF ou DKIM réussie au domaine visible De l'alignement à l'alignement. Un passage brut pour un autre domaine peut coexister avec une défaillance d'alignement. Le lecteur compte les résultats policy_evaluated au lieu de remplacer les valeurs brutes auth_results. Ce choix est important dans l'enquête sur la transmission ou les services qui signent avec un domaine différent. Comparer les identifiants pertinents avant d'interpréter une contradiction apparente. Le RFC 9989 décrit le modèle d'authentification et d'alignement; le RFC 9990 définit les rapports agrégés. Ni un passage brut ni une politique publiée ne suffisent, en soi, à expliquer le résultat de chaque message.
Travail à travers le rapport de démonstration fictif
L'exemple intégré contient trois enregistrements : 120 messages avec des cartes SPF alignées et DKIM, 30 avec des cartes DKIM alignées et SPF en panne, et 10 avec les deux échecs. L'ajout des chiffres fournis donne 160 messages. Les deux premiers groupes contribuent 150 passes DMARC parce que l'un ou l'autre mécanisme aligné est suffisant; dix échouent. La part de défaillance de ce montage est de 10 divisé par 160, ou 6.25%. Ce sont des calculs à partir de XML délibérément fictif, et non des observations sur un vrai domaine ou un vrai fournisseur. Utilisez l'exemple pour savoir quels champs conduisent les totaux avant d'importer vos propres rapports.
| Alignement DKIM | SPF des pays alignés | Messages | Résumé du DMARC |
|---|---|---|---|
| Passer | Passer | 120 | Passer |
| Passer | Échec | 30 | Passer |
| Échec | Échec | 10 | Échec |
| Total général | Soit le mécanisme aligné passe | 160 | 150 laissez-passer; 93.75% |
Rapport fictif. La disposition du receveur et le résultat d'alignement sont des champs distincts.
Utilisez cet exemple Ouvre le lecteur de rapport DMARC avec ces entrées.
Garder la disposition distincte de l'authentification
Un rapport fournit également la disposition du destinataire. Le lecteur accepte le passage du RFC 9990, aucun héritage, quarantaine et rejet; il s'agit d'un lecteur structurel plutôt que de validation complète du schéma XML. Ne présumez pas que le nombre de quarantaines doit être égal à tous les échecs du DMARC. Les choix politiques et la manipulation des récepteurs peuvent rendre ces totaux différents. Dans l'exemple fictif, les dix messages défaillants ont une disposition de quarantaine; cette relation appartient au fixture fourni et n'est pas une règle universelle. Lisez l'information de niveau record avant d'augmenter une différence inexpliquée. Les champs d'alignement entraînent des totaux d'authentification, indépendamment de l'action rapportée par le récepteur.
Comparez une source avec votre inventaire d'envoi
Pour une source inconnue, comparez l'adresse source, le domaine visible et la période d'observation avec vos services connus et les changements récents. Une nouvelle plate-forme de facturation ou l'intégration migrée de bulletins peut expliquer le trafic qui était absent de l'ancien inventaire. La transmission ou une utilisation non autorisée sont d'autres possibilités. Le lecteur n'attribue pas une adresse IP à un fournisseur ou ne classe pas une source comme malveillante. Gardez ces jugements séparés jusqu'à ce que vous ayez des preuves. Enregistrez une étape pratique, comme la vérification du domaine de signature configuré par le fournisseur, plutôt que de supprimer ou de bloquer automatiquement chaque ligne qui échoue à l'alignement.
Évitez de compter les mêmes observations deux fois
Conservez les identités et les périodes de déclaration dans votre dossier de travail. Le lecteur rejette les identités dupliquées à l'intérieur d'une seule soumission, mais différents identifiants de rapports comportant des périodes de chevauchement peuvent encore décrire le chevauchement du trafic. Combiner ces fichiers peut gonfler une tendance apparente. Comparer la couverture du récepteur similaire et les intervalles lors de la mesure de l'amélioration après un changement de configuration. Rappelez-vous également que la table affichée peut être limitée pendant que le téléchargement conserve plus de lignes. Enquêter sur l'exportation complète au besoin. Un pourcentage changeant peut refléter une sélection modifiée de rapports ainsi qu'une configuration d'envoi modifiée.
Vérifier un véritable message avant de changer de politique
Utilisez le vérificateur des dossiers DMARC pour inspecter la politique actuellement publiée, puis obtenir un message représentatif du service légitime touché. Lire les en-têtes avec l'analyseur d'en-tête et comparer les identités avec le rapport. Le DNS actuel peut différer de la politique observée lors d'un intervalle de rapports antérieur. Gardez cette différence de temps explicite. Une fois la cause comprise, examinez la configuration du service et votre processus de modification des politiques. Un rapport est une piste diagnostique, pas une promesse de livraison ou un commandement de passer immédiatement à une politique plus stricte. Conserver les preuves et vérifier les observations subséquentes.