En février dernier, je vous avais parlé de l’implémentation de DMARC. Dans ce second article, nous allons voir ce qui se cache derrière un rapport DMARC au travers de quelques questions. L’objectif de cette série d’articles est de vous aider – si vous n’avez pas encore franchi le cap – à mieux protéger vos noms de domaine avec DMARC !
DMARC en trois « bullet » points…
Je vais faire simple et court : « DMARC » est une norme d’authentification e-mail qui va s’appuyer sur les enregistrements SPF & DKIM. Il va permettre à tout annonceur qui l’implémente de :
- Renforcer les limitations de SPF & DKIM en appliquant une règle de sécurité en cas d’échec de SPF & DKIM sur le domaine expéditeur.
- Limiter le spam et le phishing sur toute votre infrastructure (domaine principal & sous-domaines) grâce aux rapports fournis par différents organismes.
- Rendre conforme tous les flux e-mails afin d’en améliorer la légitimité.
La seule contrainte de DMARC aujourd’hui est que tous les organismes (Fai, Webmails, Filtres Anti-Spam, etc.) ne l’interprètent pas !
Un rapport DMARC… C’est quoi ?
Tout d’abord, pour recevoir des rapports DMARC, il faudra configurer une adresse e-mail dans le tag « rua ».
v=DMARC1; p=none; rua=mailto:zc1cbjad@ag.dmarcian.eu, mailto:dmarc_agg@dmarc.250ok.net,mailto:dmarc_agg@lepatron.email;
Note : Si vous voulez recevoir l’intégralité de tous les rapports, il faudra choisir une adresse e-mail de votre domaine expéditeur (ex : dmarc-rua@badsender.com pour le nom de domaine badsender.com). Dans le cas contraire, vous devrez créer un enregistrement DMARC (v=DMARC1;) sur le domaine externe à votre domaine expéditeur.
Une fois DMARC en place, vous allez recevoir (en fonction de votre paramétrage), les résultats d’activité enregistrés sur votre domaine expéditeur. J’entends par là les résultats d’authentification de vos campagnes e-mails mais aussi des activités tierces – légitimes comme malveillantes.
Ce rapport DMARC est envoyé au format ARF (cf. en PJ). Le fichier sera zippé et contiendra le rapport au format XML.
Qui envoient ces rapports DMARC ?
Comme je vous l’ai dit précédemment, les rapports sont envoyés par tout organisme sachant interpréter DMARC et capable d’envoyer ces fameux rapports.
Voici une liste (non-exhaustive) des organismes pour lesquels nous avons reçu un rapport depuis le 1 janvier 2021 (sur 2 domaines monitorés) :
Organisme | Organisation | Format du zip |
ADP | Software | .GZ |
Belgacom | Hébergeur | .GZ |
BNP Paribas | Banque | .GZ |
BPCE | Banque | .GZ |
Caisse des Dépôts | Finance | .GZ |
Cisco | Sécurité | .GZ |
Diennea | Technologies | .ZIP |
Webmail | .ZIP | |
Groupe Casino | Distribution | .GZ |
Infomaniak | Hébergeur | .ZIP |
La Poste | Webmail | .GZ |
Social | .GZ | |
Mail.ru | Webmail | .GZ |
OC3 Network | Hébergeur | .GZ |
Panalpina | Logistique | .GZ |
Rackspace | Hébergeur | .ZIP |
Sfr | Webmail | .GZ |
Spamtitan | Sécurité | .GZ |
Strasbourg.eu | Collectivité | .GZ |
Telus | Télécommunication | .GZ |
Yahoo | Webmail | .GZ |
Zerospam | Sécurité | .GZ |
Zoho | Hébergeur | .GZ |
Comme vous voyez, le panel d’entreprise est large et ce n’est qu’une petite proportion de ce qu’il peut y avoir comme organisation renvoyant des informations liées à DMARC.
Un rapport DMARC vu de l’intérieur !!!
C’est bien beau de vous donner tout un tas d’informations sur DMARC mais j’en ai oublié l’essentiel… Qu’est-ce qu’on trouve comme information dans ces fameux rapports ???
Je vais vous décortiquer un rapport DMARC que l’on a reçu de Gmail :
Besoin d'aide ?
Lire du contenu ne fait pas tout. Le mieux, c’est d’en parler avec nous.
Structure d’un rapport
Un rapport DMARC est un fichier XML. Vous allez retrouver dans ces métadonnées toutes les informations d’authentification liées à votre domaine expéditeur (et sous-domaines s’il est placé sur le domaine racine). Ce fichier se décompose en 3 grandes sections :
- Balise « report_metadata »
- Balise « policy_published »
- Balise « record ».
La balise « record » est la plus importante puisqu’elle contiendra tous les résultats d’authentification. 1 record = 1 résultat, donc plus vous aurez de record dans votre fichier, plus vous aurez de résultats d’authentification à analyser ! Si vous êtes un gros envoyeur, je vous conseille fortement d’utiliser une solution de monitoring DMARC.
*spoil* >> Je prévois plusieurs articles courant juin sur différentes solutions… Mais chuuuut !
La balise « report_metadata »
Dans cette première section, vous retrouverez toutes les informations liées au rapport DMARC :
- <org_name> : L’organisme qui fournit le rapport DMARC.
- <email> : L’adresse e-mail qui envoie le rapport DMARC.
- <extra_contact_info> : Un lien menant vers la page d’assistance sur DMARC.
- <report_id> : L’ID du rapport DMARC.
- <date_range> : La période d’analyse du rapport. Dans notre exemple (une fois transformée), la période d’analyse est du 11/01/2021 00h00 au 11/01/2021 23h59 GMT.
La balise « policy_published »
Dans cette deuxième section, vous retrouverez toutes les informations liées à votre politique DMARC :
- <domain> : Indique le nom du domaine (ou sous-domaine) où est placé DMARC.
- <adkim> : Indique l’alignement DKIM => « r » (relaxed=souple) & « s » (strict=stricte).
- <aspf> : Indique l’alignement SPF => « r » (relaxed=souple) & « s » (strict=stricte).
- <p> : Indique la politique DMARC du domaine où « p » est paramétré => « none » (cf. aucune action), « quarantine » (cf. mise en spam), reject (cf. e-mail bloqué).
- <sp> : Indique la politique DMARC des sous-domaines du domaine où « p » est paramétré => « none » (cf. aucune action), « quarantine » (cf. mise en spam), reject (cf. e-mail bloqué).
- <pct> : Indique le pourcentage d’e-mails sur laquelle la règle DMARC doit s’appliquer.
La balise « record »
Dans cette troisième section, vous retrouverez toutes les informations liées aux résultats d’authentification. Cette section se décline en trois sous-sections :
- <source_ip> : Indique l’IP qui a été utilisée pour l’envoi de l’e-mail.
- <count> : Indique le nombre d’e-mails reçus avec cette IP.
- <disposition> : Indique la politique DMARC.
- <dkim> : Indique le résultat d’authentification pour DKIM.
- <spf> : Indique le résultat d’authentification pour SPF.
- <header_from> : Indique le domaine qui est utilisé dans l’adresse expéditrice.
- <domain> : Indique le domaine signé avec DKIM.
- <result> : Indique le résultat d’authentification DKIM.
- <selector> : Indique le sélecteur de la clé DKIM.
- <domain> : Indique le domaine signé avec SPF.
- <result> : Indique le résultat d’authentification SPF.
Note : Il est possible (comme dans l’exemple) qu’un domaine expéditeur possède plusieurs clés DKIM. Il faut savoir que toutes les clés DKIM seront alors analysées dans la sous-section <auth_results> <dkim>.
Conclusion…
Voilà, la mise en bouche est terminée. L’objectif ici était vraiment de vous montrer l’intérieur d’un rapport DMARC (chose faite) avant de vous plonger directement au coeur de DMARC, à savoir l’analyse des données.
Ainsi, nous verrons lors du prochain article comment interpréter les données des rapports DMARC ! Vous verrez, c’est super passionnant… Ou pas 😉
Besoin d’aide pour déployer DMARC ? Trouver la solution de monitoring DMARC la plus adaptée ? Monitorer vos data DMARC ? N’hésitez pas à nous solliciter…
—–
Nos derniers contenus sur DMARC :
- 16/05/2021 : Monito 2021 #05 | Monitoring DMARC Badsender.com – Avril 2021
- 09/04/2021 : Monito 2021 #04 | Monitoring DMARC Badsender.com – Mars 2021
- 05/03/2021 : Monito 2021 #03 | Monitoring DMARC Badsender.com – Février 2021
- 12/02/2021 : Tech 2021 #01 | Et si vous déployez DMARC en 2021 sur votre nom de domaine ?
- 05/02/2021 : Monito 2021 #02 | Monitoring DMARC Badsender.com – Janvier 2021
- 08/01/2021 : Monito 2021 #01 | Monitoring DMARC Badsender.com – Décembre 2020
5 réponses
Bonjour c’est très intéressant mais pourriez-vous expliquer si dans un fichier xml reçu le record pourrait indiquer qu’une personne (identifiable par son IP) a tout simplement sollicité un formulaire en ligne qui utilise la fonction MAIL (php par exemple) ou bien les paramètre SMTP de notre serveur ?
Bonjour Alex,
Les rapports DMARC contiennent uniquement des données des domaines/sous-domaines où l’enregistrement DMARC est placé, et ce peu importe le système utilisé pour envoyer les emails (client outlook, un Email Service Provider, un formulaire en ligne, etc.). Malheureusement, l’IP que vous récupéreriez est l’IP du formulaire (et non l’IP de la personne) sous réserve que votre domaine / sous-domaine soit paramétré sur le dit-formulaire. Si vous voulez récupérer l’IP de la personne, il faudrait l’enregistrer l’information au moment où il valide le formulaire.
Bien à vous,
Sébastien.
Hi,
Thanks for your informative article.
I need some help with DMARC reports. Though my SPF record lists the correct IP addresses, the under policy_evlauated is always coming as failed.
For example:
104.160.64.86
1
none
pass
fail
I’ve included ip4:104.160.64.86 in my spf record, but still the reports show it as « fail ».
Would you have any idea why this happens?
Regards,
Sunil
Hi,
**The tags disappeared in my previous message, so I am repeating it here with the tag details**
I need some help with DMARC reports. Though my SPF record lists the correct IP addresses, the under policy_evlauated is always coming as failed.
For example:
[source_ip] 34.195.253.204 [/source_ip]
[count] 1 [/count]
[policy_evaluated]
[disposition] none [/disposition]
[dkim] pass [/dkim]
[spf] fail [/spf]
[/policy_evaluated]
I’ve included ip4:104.160.64.86 in my spf record, but still the reports show it as « fail ».
Would you have any idea why this happens? I’ve done lots of searches but I could find no information on why this is happening.
Regards,
Sunil
Hello Sunil,
To respect the DMARC compliance, you need to have : A SPF record (based on your return-path domain) must be valid and aligned with your sender domain or a DKIM record (based on your domain signed d=) must be valid and aligned with your sender domain. If you don’t respect this, the DMARC policy will apply !
If your DMARC compliance is fail, you could verify if your alignments are correct.
Example : If your sender domain is badsender.com, your SPF domain – to be valid and aligned – must be badsender.com or a sub-domain of badsender.com. For DKIM, this is the same way : if your sender domain is badsender.com, your DKIM signature – to be valid and aligned – must be made in badsender.com or a sub-domain of badsender.com
The majority of DMARC compliance issues come from forgetting an IP or misaligned domains.
Cheers,
Sébastien.