Un rapport décrit d’abord une observation
Un message dont l’objet contient « Report domain » n’est pas automatiquement une alerte. Un fournisseur de messagerie destinataire y résume les messages observés avec votre domaine expéditeur pendant une période donnée. Tout peut fonctionner normalement. Ce rapport ne confirme ni une intrusion dans un compte ni l’échec de remise d’un message précis.
Les rapports agrégés sont demandés via la destination rua de l’enregistrement DMARC. Les données se trouvent dans une pièce jointe XML, souvent compressée. Un corps de message vide ne rend donc pas le rapport inutile. Le nom d’expéditeur affiché ne prouve pas non plus son authenticité : traitez les rapports dans un circuit d’analyse maîtrisé. [1] [3]
Vérifier la période avant de compter
Commencez par report_metadata : qui produit le rapport, quel est son report_id et quelle période UTC couvre date_range ? Vérifiez ensuite le domaine dans policy_published. La date d’arrivée du courriel ne remplace pas la période observée. Le compteur count représente des messages regroupés selon une combinaison de résultats, pas des clients, des personnes ou des incidents de sécurité.
Définissez une règle de comptage reproductible. Comparez l’émetteur du rapport, le domaine, l’identifiant, la période et le contenu. Une retransmission identique ne doit pas augmenter le total. En cas de chevauchement partiel, les données ne permettent pas toujours de soustraire exactement la partie commune. Signalez cette limite au lieu de présenter un total artificiellement précis. [1]
SPF peut réussir sans que DMARC réussisse
auth_results contient les résultats individuels de SPF et DKIM. policy_evaluated indique leur évaluation pour DMARC, avec l’alignement des domaines. Comparez ces informations à header_from, le domaine du champ expéditeur visible. Un résultat technique positif pour le domaine d’un prestataire ne suffit pas si le lien requis avec votre domaine expéditeur manque.
DMARC réussit lorsqu’au moins un des mécanismes SPF ou DKIM réussit et s’aligne sur le domaine From visible. SPF peut donc échouer alors que DMARC réussit grâce à une signature DKIM valide et alignée. Plusieurs signatures DKIM peuvent présenter des résultats différents. Cherchez la preuve réussie et alignée, plutôt que de retenir un « fail » isolé comme verdict global. [1] [2]
Délimiter le rapport
Identifier l’émetteur du rapport, le domaine, la période et l’identifiant ; écarter les doublons.
Identifier le circuit
Comparer la source, SPF/DKIM et l’alignement à l’inventaire des services autorisés.
Expliquer l’écart
Corriger un envoi légitime en échec, examiner une source inconnue ou consigner l’observation.
Une décision avec ses preuves
Consigner le responsable, le circuit vérifié et la prochaine date de contrôle. Vérifier la remise séparément.
Parcours explicatif sans données réelles de messages ou de clients. Le résultat DMARC et la preuve de remise sont deux éléments distincts.
Interpréter les combinaisons courantes
Le tableau porte sur les valeurs SPF et DKIM de policy_evaluated, pas sur les valeurs brutes d’auth_results. Il aide à les interpréter. Il ne prouve ni l’autorisation d’un service précis ni la fiabilité du contenu du message. [1] [2]
Faites défiler le tableau horizontalement.
| Résultat signalé | Interprétation | Étape suivante |
|---|---|---|
| SPF pass, DKIM pass | Les deux mécanismes réussissent l’évaluation DMARC. | Rattacher la source à un service d’envoi autorisé. |
| SPF fail, DKIM pass | DMARC réussit grâce à DKIM. | Examiner séparément l’écart SPF et un éventuel transfert. |
| SPF pass, DKIM fail | DMARC réussit grâce à SPF. | Examiner DKIM ; SPF seul résiste moins bien aux transferts. |
| SPF fail, DKIM fail | Aucun mécanisme authentifié et aligné ne réussit. | Distinguer mauvaise configuration légitime, transfert et usage non autorisé. |
| Résultat absent ou illisible | Ce relevé ne permet pas de conclure. | Vérifier le format et le traitement ; ne pas compter zéro échec. |
Une IP inconnue exige une attribution
Le nom d’un fournisseur ou le pays d’un centre de données n’identifie pas la personne à l’origine d’un envoi. Une infrastructure partagée peut transporter les messages de nombreux clients. Comparez la source à vos services réellement autorisés : messagerie, formulaire du site, facturation, support et newsletter nécessitent chacun une entrée distincte dans l’inventaire.
Les domaines, sélecteurs DKIM, journaux d’envoi et un message reçu dans des conditions maîtrisées aident à établir le circuit. N’ajoutez pas une IP inconnue à SPF pour faire disparaître un avertissement. Confirmez d’abord son autorisation. Pour un service légitime défaillant, nommez un responsable de correction et définissez la preuve attendue au contrôle suivant. Un essai réussi depuis le webmail ne valide pas le formulaire du site. [2] [4]
« none » ne signifie pas « dans la boîte de réception »
disposition décrit le traitement signalé dans le cadre de l’évaluation DMARC. La valeur none ne prouve pas la remise ; quarantine n’indique pas de manière fiable le dossier final d’un message particulier. Le destinataire peut appliquer d’autres règles. Même un résultat DMARC positif ne garantit ni le placement en boîte de réception ni un contenu fiable. Pour retrouver un courriel précis, examinez journaux d’envoi, notifications d’échec et, si disponible, original reçu.
Les rapports reflètent uniquement la visibilité des systèmes qui les produisent sur la période indiquée. Un rapport manquant ou une lacune ne prouve ni l’absence d’envoi ni l’absence d’abus. Consignez cette lacune. Pour suivre une tendance, comparez des périodes de même durée, issues des mêmes émetteurs de rapports, et vérifiez les changements de couverture. [1] [4]
Transformer le constat en action attribuée
Intervenez lorsqu’un circuit autorisé important pour l’activité échoue à DMARC ou lorsque ses résultats changent sans explication. Les sources inconnues récurrentes doivent être attribuées. La mesure découle des preuves ; elle ne consiste pas automatiquement à renforcer ou à assouplir la politique DNS. Avant de la modifier, recensez et validez les circuits légitimes et corrigez leurs défauts d’authentification connus. [2]
- Vérifier l’émetteur du rapport, le domaine, la période UTC et les doublons.
- Distinguer résultats bruts SPF/DKIM et alignement DMARC.
- Rattacher la source inattendue à un service et à un responsable.
- Examiner un message de test autorisé, ses en-têtes et les journaux pertinents.
- Définir correction, créneau de changement et procédure de retour arrière.
- Contrôler séparément l’authentification et la remise après modification.