Avant de renforcer votre politique DMARC, recensez les systèmes qui envoient du courrier légitime avec votre domaine. Les rapports peuvent révéler un expéditeur dont l'authentification doit être corrigée avant qu'une application stricte ne bloque ses messages.
Quel rapport utiliser ?
Utilisez les rapports agrégés pour comparer les sources d'envoi et les résultats d'authentification sur une période de rapport. L'adresse rua de votre enregistrement DMARC demande ces résumés XML aux récepteurs participants.
L'adresse ruf demande des rapports d'échec individuels, parfois appelés rapports forensiques. Ils utilisent un format de rapport d'échec d'authentification et peuvent contenir des en-têtes ou du contenu de message. Les récepteurs peuvent les expurger ou les omettre, car ce contenu peut exposer des informations personnelles. Les règles de rapport de la RFC 7489 décrivent les deux types de rapports.
Les rapports agrégés couvrent le trafic observé par chaque récepteur déclarant. L'absence d'un rapport ne prouve pas qu'aucun message n'a utilisé votre domaine. L'explication de l'enregistrement DMARC indique où définir les adresses de rapport.
Que contient un rapport agrégé ?
Un rapport agrégé identifie l'organisation déclarante, la période de rapport et la politique publiée, suivis d'enregistrements regroupant les messages partageant des caractéristiques communes. Une même IP source peut apparaître dans plusieurs enregistrements lorsque leurs résultats d'authentification ou d'autres champs de regroupement diffèrent.
Cet extrait illustratif conserve les champs nécessaires pour comparer une source avec ses résultats d'authentification :
<report_metadata>
<org_name>google.com</org_name>
<date_range><begin>1718323200</begin><end>1718409600</end></date_range>
</report_metadata>
<policy_published>
<domain>example.com</domain>
<p>none</p>
</policy_published>
<record>
<row>
<source_ip>203.0.113.10</source_ip>
<count>42</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers><header_from>example.com</header_from></identifiers>
<auth_results>
<dkim><domain>example.com</domain><result>pass</result></dkim>
<spf><domain>example.com</domain><result>pass</result></spf>
</auth_results>
</record>Cet enregistrement représente 42 messages provenant de 203.0.113.10 utilisant example.com dans l'adresse From visible. Les deux méthodes d'authentification ont réussi et sont alignées. Le récepteur n'a appliqué aucune mesure DMARC à ces messages ; cela n'établit pas leur placement en boîte de réception.
Quels champs signalent un problème d'authentification ?
Comparez policy_evaluated avec auth_results pour distinguer un échec d'authentification d'un échec d'alignement de domaine.
| Champ | Ce qu'il faut vérifier |
|---|---|
source_ip | Identifiez le serveur d'envoi et le service qui en est responsable. |
count | Comptez les messages représentés par cet enregistrement, pas par le rapport entier. |
header_from | Confirmez le domaine affiché au destinataire. |
disposition | Vérifiez si le récepteur a appliqué none, quarantine ou reject. |
dkim et spf dans policy_evaluated | Vérifiez si chaque méthode a réussi et est alignée pour DMARC. |
auth_results | Comparez les résultats d'authentification bruts et les domaines qu'ils ont authentifiés. |
Par exemple, SPF peut réussir sous auth_results mais échouer sous policy_evaluated lorsque son domaine authentifié ne s'aligne pas avec le domaine From. Un passage aligné de DKIM peut tout de même faire réussir ce message sous DMARC. Comment fonctionne DMARC explique cette relation.
Que faire avec chaque source d'envoi ?
Associez chaque source à un service que vous autorisez avant de modifier la politique. Les résultats d'authentification seuls ne vous indiquent pas si votre organisation avait l'intention de confier l'envoi à ce service.
- Pour un expéditeur connu qui réussit et s'aligne, confirmez que son volume déclaré correspond au trafic attendu.
- Pour un expéditeur connu qui échoue, corrigez son authentification ou son alignement et vérifiez les rapports suivants pour le résultat.
- Pour un expéditeur inconnu qui réussit, identifiez qui l'a configuré et s'il doit conserver son autorisation.
- Pour un expéditeur inconnu qui échoue, déterminez s'il s'agit d'un service légitime mal configuré ou d'une utilisation non autorisée de votre domaine.
Résolvez les échecs légitimes avant de passer de la surveillance à la quarantaine ou au rejet, car ces messages seraient sinon candidats à l'application de la politique. Corriger les échecs DMARC couvre les causes courantes.
Comment inspecter les rapports pour un domaine d'envoi Bird ?
Vous pouvez acheminer les rapports agrégés vers votre propre boîte de réception via l'adresse rua de votre enregistrement DMARC. Utilisez l'analyseur de rapports DMARC pour inspecter le XML, ou ouvrez un rapport dans un éditeur de texte.
La vérification DNS de Bird contrôle votre politique publiée ; les rapports des récepteurs décrivent les résultats d'authentification des messages. Ce sont des vérifications distinctes. Le guide d'authentification couvre la politique et les enregistrements DNS à publier.