Comprendre le rapport DMARC et son contenu pour une sécurité e-mail optimale Link to heading

Introduction Link to heading

DMARC (Domain-based Message Authentication, Reporting, and Conformance) est un protocole d’authentification des emails qui permet aux propriétaires de domaines de protéger leur domaine contre l’usurpation d’identité et le phishing. Les rapports DMARC sont des outils essentiels pour surveiller et améliorer la sécurité de vos communications par email. Dans cet article, nous allons explorer en détail la structure et l’interprétation de ces rapports.

Les différents types de rapports DMARC Link to heading

1. Rapports agrégés (RUA) Link to heading

Les rapports agrégés sont envoyés quotidiennement et fournissent une vue d’ensemble des résultats d’authentification pour votre domaine. Ils contiennent :

Des statistiques sur le volume d’emails
Les résultats des vérifications SPF et DKIM
Les actions appliquées (none, quarantine, reject)
Les sources d’émission des emails

2. Rapports de non-conformité (RUF) Link to heading

Les rapports de non-conformité sont envoyés en temps réel lorsqu’un email échoue à l’authentification. Ils contiennent :

Les en-têtes complets de l’email
Les détails de l’échec d’authentification
Les informations sur l’expéditeur et le destinataire

Structure d’un rapport DMARC Link to heading

Un rapport DMARC typique est au format XML et contient les sections suivantes :

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
  <report_metadata>
    <org_name>Google</org_name>
    <email>[email protected]</email>
    <date_range>
      <begin>1234567890</begin>
      <end>1234567890</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <p>reject</p>
    <sp>reject</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <source_ip>192.0.2.1</source_ip>
    <count>1</count>
    <policy_evaluated>
      <disposition>reject</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </record>
</feedback>

Détail complet des champs DMARC Link to heading

1. Métadonnées du rapport (report_metadata) Link to heading

<report_metadata>
  <org_name>Nom de l'organisation émettrice</org_name>
  <email>Adresse email de contact</email>
  <extra_contact_info>Informations supplémentaires (optionnel)</extra_contact_info>
  <report_id>Identifiant unique du rapport</report_id>
  <date_range>
    <begin>Timestamp de début (Unix)</begin>
    <end>Timestamp de fin (Unix)</end>
  </date_range>
  <error>Messages d'erreur éventuels (optionnel)</error>
</report_metadata>

2. Politique publiée (policy_published) Link to heading

<policy_published>
  <domain>Domaine concerné</domain>
  <p>Politique pour le domaine (none, quarantine, reject)</p>
  <sp>Politique pour les sous-domaines (none, quarantine, reject)</sp>
  <pct>Pourcentage d'emails concernés (0-100)</pct>
  <fo>Options de reporting (0,1,d,s)</fo>
</policy_published>

Explications des options de politique :

none : Aucune action spécifique
quarantine : Mise en quarantaine de l’email
reject : Rejet complet de l’email

Options de reporting (fo) :

0 : Générer un rapport si tous les mécanismes échouent
1 : Générer un rapport si n’importe quel mécanisme échoue
d : Générer un rapport si DKIM échoue
s : Générer un rapport si SPF échoue

3. Enregistrements (record) Link to heading

<record>
  <source_ip>Adresse IP source</source_ip>
  <count>Nombre d'emails</count>
  <disposition>Résultat de l'évaluation (none, quarantine, reject)</disposition>
  <dkim>Résultat DKIM (pass, fail)</dkim>
  <spf>Résultat SPF (pass, fail)</spf>
  <reason>
    <type>Type de raison (forwarded, sampled_out, trusted_forwarder, mailing_list, local_policy, other)</type>
    <comment>Commentaire explicatif (optionnel)</comment>
  </reason>
  <envelope_to>Destinataire SMTP (optionnel)</envelope_to>
  <header_from>Adresse From dans l'en-tête</header_from>
  <auth_results>
    <dkim>
      <domain>Domaine signé</domain>
      <result>Résultat (pass, fail, neutral, policy, none, temperror, permerror)</result>
      <selector>Sélecteur DKIM utilisé</selector>
    </dkim>
    <spf>
      <domain>Domaine vérifié</domain>
      <result>Résultat (pass, fail, neutral, softfail, none, temperror, permerror)</result>
      <scope>Portée (helo, mfrom)</scope>
    </spf>
  </auth_results>
</record>

4. Résultats d’authentification détaillés Link to heading

Résultats DKIM possibles : Link to heading

pass : Signature valide
fail : Signature invalide
neutral : Résultat neutre
policy : Échec de la politique
none : Pas de signature
temperror : Erreur temporaire
permerror : Erreur permanente

Résultats SPF possibles : Link to heading

pass : IP autorisée
fail : IP non autorisée
neutral : Résultat neutre
softfail : Échec léger
none : Pas de record SPF
temperror : Erreur temporaire
permerror : Erreur permanente

5. Types de raisons (reason) Link to heading

Les types de raisons expliquent pourquoi un email a été traité d’une certaine manière :

forwarded : Email transféré
sampled_out : Non inclus dans le pourcentage
trusted_forwarder : Transmis par un forwarder de confiance
mailing_list : Provenant d’une liste de diffusion
local_policy : Décision basée sur une politique locale
other : Autre raison

6. Exemple complet d’un rapport Link to heading

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
  <report_metadata>
    <org_name>Google</org_name>
    <email>[email protected]</email>
    <extra_contact_info>https://support.google.com/mail/contact/bulk_send_new</extra_contact_info>
    <report_id>20240517.0001</report_id>
    <date_range>
      <begin>1715961600</begin>
      <end>1716048000</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <p>reject</p>
    <sp>reject</sp>
    <pct>100</pct>
    <fo>1</fo>
  </policy_published>
  <record>
    <source_ip>192.0.2.1</source_ip>
    <count>42</count>
    <disposition>reject</disposition>
    <dkim>fail</dkim>
    <spf>fail</spf>
    <reason>
      <type>local_policy</type>
      <comment>SPF et DKIM ont échoué</comment>
    </reason>
    <envelope_to>[email protected]</envelope_to>
    <header_from>[email protected]</header_from>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <result>fail</result>
        <selector>default</selector>
      </dkim>
      <spf>
        <domain>example.com</domain>
        <result>fail</result>
        <scope>mfrom</scope>
      </spf>
    </auth_results>
  </record>
</feedback>

Comment interpréter les rapports Link to heading

1. Analyse des métadonnées Link to heading

Période couverte Link to heading

Vérifier les timestamps begin et end pour s’assurer que le rapport couvre la période attendue
Les timestamps sont en format Unix (secondes depuis le 1er janvier 1970)
Un rapport typique couvre une période de 24 heures

Source du rapport Link to heading

Identifier l’organisation émettrice (org_name)
Noter l’adresse de contact (email) pour les questions
Vérifier les informations supplémentaires (extra_contact_info) si présentes

2. Analyse de la politique Link to heading

Configuration actuelle Link to heading

Vérifier le domaine concerné (domain)
Examiner les modes d’alignement :
- adkim : r (relaxed) ou s (strict) pour DKIM
- aspf : r (relaxed) ou s (strict) pour SPF
Analyser les politiques en place :
- p : politique principale (none/quarantine/reject)
- sp : politique pour les sous-domaines
- pct : pourcentage d’emails concernés

Options de reporting Link to heading

Vérifier la configuration fo :
- 0 : Rapports uniquement si tous les mécanismes échouent
- 1 : Rapports si n’importe quel mécanisme échoue
- d : Rapports spécifiques aux échecs DKIM
- s : Rapports spécifiques aux échecs SPF

3. Analyse des enregistrements Link to heading

Volume et sources Link to heading

Examiner le count pour chaque source_ip
Identifier les pics anormaux de volume
Détecter les sources inattendues ou suspectes

Résultats d’authentification Link to heading

Pour chaque enregistrement, analyser :

Résultats DKIM (auth_results/dkim) :
- pass : Signature valide
- fail : Signature invalide
- neutral : Résultat indéterminé
- policy : Problème de politique
- temperror/permerror : Erreurs techniques
Résultats SPF (auth_results/spf) :
- pass : IP autorisée
- fail : IP non autorisée
- neutral/softfail : Résultats intermédiaires
- temperror/permerror : Erreurs techniques
Alignement :
- Vérifier la cohérence entre header_from et les domaines authentifiés
- Analyser les problèmes d’alignement DKIM et SPF

Actions appliquées Link to heading

Examiner la disposition pour chaque enregistrement :
- none : Aucune action
- quarantine : Mise en quarantaine
- reject : Rejet de l’email

Raisons spécifiques Link to heading

Analyser le champ reason pour comprendre le contexte :

forwarded : Emails transférés
sampled_out : Non inclus dans le pourcentage
trusted_forwarder : Transmis par un forwarder de confiance
mailing_list : Provenant d’une liste de diffusion
local_policy : Décision basée sur une politique locale
other : Autres cas

4. Analyse des tendances Link to heading

Patterns d’échec Link to heading

Identifier les sources IP récurrentes avec des échecs
Détecter les patterns d’échec DKIM vs SPF
Analyser les problèmes d’alignement récurrents

Volume par source Link to heading

Tracer l’évolution du volume par source IP
Identifier les pics anormaux
Détecter les sources légitimes vs suspectes

5. Actions recommandées Link to heading

Court terme Link to heading

Pour les échecs DKIM :
- Vérifier la configuration des clés DKIM
- S’assurer que tous les serveurs d’envoi signent correctement
- Vérifier la rotation des clés
Pour les échecs SPF :
- Mettre à jour les enregistrements SPF
- Vérifier les IPs manquantes
- Optimiser les mécanismes SPF
Pour les problèmes d’alignement :
- Vérifier la cohérence des domaines d’envoi
- Ajuster les politiques d’alignement si nécessaire

Long terme Link to heading

Amélioration de la politique :
- Ajuster progressivement le pct
- Renforcer les politiques (none → quarantine → reject)
- Optimiser les modes d’alignement
Monitoring continu :
- Mettre en place des alertes sur les pics anormaux
- Suivre l’évolution des taux de réussite
- Documenter les sources légitimes
Documentation :
- Maintenir une liste des sources autorisées
- Documenter les exceptions et leurs raisons
- Tenir à jour les procédures de résolution

Bonnes pratiques pour l’analyse Link to heading

Mise en place progressive
- Commencer avec p=none
- Augmenter progressivement le pourcentage (pct)
- Passer à p=quarantine puis p=reject
Surveillance régulière
- Analyser les rapports quotidiennement
- Identifier les sources légitimes
- Détecter les tentatives d’usurpation
Optimisation continue
- Ajuster les politiques SPF et DKIM
- Mettre à jour les listes d’IP autorisées
- Corriger les problèmes d’alignement

Outils d’analyse Link to heading

Plusieurs outils peuvent vous aider à analyser les rapports DMARC :

DMARC Analyzer : Solution complète d’analyse
Dmarcian : Plateforme de gestion DMARC
Google Postmaster Tools : Outil gratuit pour les domaines Google Workspace

Cas d’études : Analyse de scénarios réels Link to heading

1. Détection d’une tentative de phishing Link to heading

Scénario Link to heading

Un attaquant tente d’envoyer des emails en se faisant passer pour votre domaine.

Signes dans le rapport DMARC Link to heading

<record>
  <source_ip>45.67.89.123</source_ip>
  <count>1500</count>
  <disposition>reject</disposition>
  <dkim>fail</dkim>
  <spf>fail</spf>
  <header_from>[email protected]</header_from>
  <auth_results>
    <dkim>
      <domain>votre-domaine.com</domain>
      <result>fail</result>
    </dkim>
    <spf>
      <domain>votre-domaine.com</domain>
      <result>fail</result>
    </spf>
  </auth_results>
</record>

Analyse Link to heading

Volume anormalement élevé (1500 emails)
IP source inconnue
Double échec (SPF et DKIM)
Même domaine dans l’en-tête From
Action : rejet systématique

Actions recommandées Link to heading

Vérification de la configuration DMARC
- Confirmer que la politique est bien en reject pour le domaine
- Vérifier que le pourcentage (pct) est à 100%
- S’assurer que les modes d’alignement sont appropriés
Surveillance et documentation
- Documenter le pattern d’attaque (volume, timing, cibles)
- Surveiller les tentatives similaires sur d’autres sous-domaines
- Maintenir un historique des tentatives d’usurpation
Communication et formation
- Alerter les utilisateurs du domaine sur les tentatives d’usurpation
- Renforcer la formation sur la détection des emails frauduleux
- Mettre à jour les procédures de signalement des emails suspects
Contact avec l’administrateur réseau source
- Identifier l’ASN (Autonomous System Number) de l’IP source
- Utiliser les bases de données WHOIS pour trouver les contacts
- Envoyer un rapport d’abus avec :
  - Les détails du rapport DMARC
  - Les horodatages des tentatives
  - Les en-têtes des emails concernés
  - La politique DMARC en place
- Suivre les procédures d’abus standard (RFC 2142)
Amélioration continue
- Revoir régulièrement les politiques DMARC
- Mettre à jour les enregistrements SPF et DKIM si nécessaire
- Partager les informations avec d’autres administrateurs de domaine

Note importante : La meilleure protection est une configuration DMARC robuste combinée à une politique de rejet stricte. Cependant, signaler les abus aux administrateurs réseau peut aider à :
Identifier et neutraliser les serveurs compromis
Améliorer la réputation de votre domaine
Contribuer à la lutte globale contre le spam et le phishing

2. Détection de forwarding non autorisé Link to heading

Scénario Link to heading

Un utilisateur a configuré un forward automatique vers une adresse externe.

Signes dans le rapport DMARC Link to heading

<record>
  <source_ip>192.168.1.100</source_ip>
  <count>1</count>
  <disposition>quarantine</disposition>
  <dkim>pass</dkim>
  <spf>fail</spf>
  <reason>
    <type>forwarded</type>
    <comment>Email forwarded to external address</comment>
  </reason>
  <header_from>[email protected]</header_from>
  <envelope_to>[email protected]</envelope_to>
</record>

Analyse Link to heading

SPF échoue car l’email est relayé
DKIM passe car la signature est préservée
Type de raison : “forwarded”
Action : quarantaine

Actions recommandées Link to heading

Vérifier la politique de forwarding
Documenter les cas légitimes
Mettre à jour la politique DMARC si nécessaire

3. Erreur de configuration SPF Link to heading

Scénario Link to heading

Un serveur d’envoi légitime n’est pas inclus dans l’enregistrement SPF.

Signes dans le rapport DMARC Link to heading

<record>
  <source_ip>10.0.0.50</source_ip>
  <count>100</count>
  <disposition>none</disposition>
  <dkim>pass</dkim>
  <spf>fail</spf>
  <reason>
    <type>local_policy</type>
    <comment>SPF record missing authorized IP</comment>
  </reason>
  <auth_results>
    <spf>
      <domain>votre-domaine.com</domain>
      <result>fail</result>
      <scope>mfrom</scope>
    </spf>
  </auth_results>
</record>

Analyse Link to heading

IP source interne connue
DKIM valide
SPF échoue systématiquement
Volume constant et attendu

Actions recommandées Link to heading

Ajouter l’IP manquante dans l’enregistrement SPF
Vérifier tous les serveurs d’envoi
Tester la nouvelle configuration

4. Erreur de configuration DKIM Link to heading

Scénario Link to heading

Problème de rotation de clés DKIM ou de sélecteur incorrect.

Signes dans le rapport DMARC Link to heading

<record>
  <source_ip>10.0.0.51</source_ip>
  <count>50</count>
  <disposition>none</disposition>
  <dkim>fail</dkim>
  <spf>pass</spf>
  <auth_results>
    <dkim>
      <domain>votre-domaine.com</domain>
      <result>fail</result>
      <selector>default</selector>
    </dkim>
  </auth_results>
</record>

Analyse Link to heading

SPF valide
DKIM échoue systématiquement
Même sélecteur utilisé
Volume constant

Actions recommandées Link to heading

Vérifier la validité des clés DKIM
Confirmer le sélecteur utilisé
Vérifier la configuration du serveur d’envoi

Sources et documentation Link to heading

Standards et RFC Link to heading

RFC 7489 - DMARC Specification
RFC 7208 - SPF Specification
RFC 6376 - DKIM Specification

Guides et tutoriels Link to heading

DMARC.org - Documentation officielle
Google Postmaster Tools - Guide d’analyse des rapports
Microsoft 365 - Protection contre le spoofing

Articles techniques Link to heading

Cloudflare Blog - Guide d’implémentation DMARC
Google Security Blog - Articles sur la sécurité email
Microsoft Security Blog - Bonnes pratiques de sécurité

Forums et communautés Link to heading

SpamAssassin - Documentation sur la détection du spam
Stack Exchange - Questions et réponses techniques
GitHub - Projets open source liés à DMARC

Conclusion Link to heading

Les rapports DMARC sont des outils puissants pour améliorer la sécurité de vos communications par email. Une analyse régulière et approfondie de ces rapports vous permettra de :

Détecter rapidement les tentatives d’usurpation
Améliorer la délivrabilité de vos emails
Renforcer la réputation de votre domaine
Protéger vos utilisateurs contre le phishing

En suivant les bonnes pratiques décrites dans cet article, vous pourrez tirer le meilleur parti de vos rapports DMARC et renforcer significativement la sécurité de vos communications par email.