Lire et comprendre vos rapports DMARC : guide pratique

Vous avez publié un enregistrement DMARC avec un tag rua=. Les premiers fichiers XML arrivent dans votre boîte mail : des pièces jointes ZIP avec des noms cryptiques. Vous ouvrez le fichier, découvrez du XML brut, et vous demandez quoi en faire.

Ce guide vous explique comment lire ces rapports, quelles informations en extraire, et comment agir sur ce que vous trouvez. Vous y trouverez des exemples de XML annoté, les outils qui automatisent le décodage, les scénarios les plus fréquents avec leur résolution, et le plan pour passer DMARC en reject sans bloquer vos propres emails.

Prérequis. Ce guide suppose que DMARC est déjà publié sur votre domaine. Si ce n’est pas encore le cas, commencez par configurer SPF, DKIM et DMARC puis revenez ici.

Ce que sont les rapports DMARC et pourquoi les lire

Quand un serveur de messagerie reçoit un email prétendant venir de votre domaine, il effectue trois vérifications : SPF, DKIM et DMARC (leur rôle est expliqué dans notre guide configurer SPF, DKIM et DMARC). Que l’email soit légitime ou non, ce serveur collecte ces résultats et vous les envoie sous forme de rapport agrégé, à condition que votre enregistrement DMARC contienne un tag rua=.

Ces rapports sont la seule façon de savoir précisément ce qui se passe avec votre domaine :

Quels services envoient des emails pour votre compte
Lesquels passent ou échouent l’authentification
Depuis quelles adresses IP
En quel volume

Sans ce retour d’information, vous gérez votre infrastructure email à l’aveugle. Vous ne savez pas si un prestataire envoie des campagnes avec votre domaine mal configuré, ni si des acteurs malveillants tentent de se faire passer pour vous. Les rapports DMARC sont le tableau de bord de votre authentification email.

Qui envoie des rapports ? Tous les fournisseurs de messagerie qui traitent des emails de votre domaine et qui implémentent DMARC. Google, Microsoft, Yahoo, Apple Mail, Orange, Free, SFR, et une centaine d’autres. Chacun envoie un rapport par jour, couvrant les 24 heures précédentes.

La spécification de référence est la RFC 7489, qui définit le format exact des rapports et le comportement attendu des fournisseurs.

Rapports agrégés (RUA) vs rapports forensic (RUF)

DMARC prévoit deux types de rapports, activés par deux tags distincts dans votre enregistrement.

Rapports agrégés (tag rua=)

C’est le type de rapport que vous recevrez dans 99 % des cas. Un fichier XML, compressé en ZIP ou GZ, envoyé une fois par jour par chaque fournisseur.

Ce qu’il contient :

L’identité du fournisseur qui envoie le rapport
La période couverte (timestamps début et fin)
Votre politique DMARC publiée
Une liste d’entrées, une par IP source, avec pour chacune : l’IP, le nombre d’emails, les résultats SPF et DKIM, la disposition appliquée

Ce qu’il ne contient pas : aucun contenu d’email, aucune adresse de destinataire, aucun objet. Les rapports RUA sont agrégés et anonymisés par conception.

Activation :

_dmarc.votredomaine.fr  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@votredomaine.fr"

Rapports forensic (tag ruf=)

Les rapports forensic sont envoyés à chaque échec d’authentification individuel. Contrairement aux rapports agrégés, ils peuvent contenir des éléments du message original : en-têtes, et parfois des extraits du corps.

Pourquoi vous n’en recevrez probablement pas : Pour des raisons de confidentialité et de volume, Google et Microsoft ont arrêté d’envoyer des rapports forensic. Yahoo et quelques fournisseurs de moindre taille les envoient encore. En pratique, les rapports RUA agrégés fournissent la grande majorité des informations nécessaires à la gestion de votre infrastructure DMARC.

Si vous activez ruf= quand même :

v=DMARC1; p=none; rua=mailto:dmarc@votredomaine.fr; ruf=mailto:dmarc-fail@votredomaine.fr; fo=1

Le paramètre fo=1 déclenche un rapport forensic à chaque email qui échoue SPF ou DKIM (pas seulement les deux). fo=0 (défaut) ne rapporte que les doubles échecs.

Recommandation pratique : concentrez-vous sur les rapports RUA. Ils contiennent tout ce dont vous avez besoin pour gérer votre infrastructure DMARC.

Lire la structure XML d’un rapport agrégé

Un rapport agrégé est un fichier XML avec une structure standardisée définie par la RFC 7489. Voici un exemple complet annoté.

Structure générale

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>

  <!-- Métadonnées du rapport -->
  <report_metadata>
    <org_name>Google Inc.</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>12345678901234567890</report_id>
    <date_range>
      <begin>1744761600</begin>  <!-- timestamp Unix début de période -->
      <end>1744847999</end>      <!-- timestamp Unix fin de période -->
    </date_range>
  </report_metadata>

  <!-- Votre politique publiée, telle que lue par le fournisseur -->
  <policy_published>
    <domain>votredomaine.fr</domain>
    <adkim>r</adkim>   <!-- alignement DKIM : r=relaxé, s=strict -->
    <aspf>r</aspf>     <!-- alignement SPF : r=relaxé, s=strict -->
    <p>none</p>        <!-- votre politique actuelle -->
    <sp>none</sp>      <!-- politique pour les sous-domaines -->
    <pct>100</pct>     <!-- pourcentage du trafic soumis à la politique -->
  </policy_published>

  <!-- Un enregistrement par IP source -->
  <record>
    <row>
      <source_ip>209.85.220.41</source_ip>
      <count>147</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>votredomaine.fr</header_from>
      <envelope_from>mail.votredomaine.fr</envelope_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>votredomaine.fr</domain>
        <result>pass</result>
        <selector>google</selector>
      </dkim>
      <spf>
        <domain>mail.votredomaine.fr</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>

</feedback>

Les champs à lire en priorité

<org_name> : le fournisseur qui envoie le rapport. Google, Microsoft (noreply-dmarc@microsoft.com), Yahoo, Apple, Orange. Chaque rapport ne couvre que le trafic reçu par ce fournisseur.

<source_ip> : l’adresse IP du serveur qui a envoyé les emails. C’est la première information à analyser. Reconnaissez-vous cette IP ? Appartient-elle à Google Workspace, Microsoft 365, Brevo, votre serveur applicatif ?

<count> : le nombre d’emails envoyés depuis cette IP pendant la période. Un volume de 1 ou 2 peut être un scanner. Un volume de 500 sur une IP inconnue mérite investigation immédiate.

<policy_evaluated> : le verdict DMARC pour cette source. Les trois sous-champs :

Champ	Valeur possible	Signification
`<disposition>`	none, quarantine, reject	Action appliquée par le serveur destinataire
`<dkim>`	pass, fail	L’alignement DKIM a-t-il réussi ?
`<spf>`	pass, fail	L’alignement SPF a-t-il réussi ?

Règle de lecture : DMARC passe si au moins l’un des deux (dkim ou spf) est en pass. Un double fail avec disposition=none signifie que l’email a quand même été livré (politique non-bloquante). Avec disposition=reject, il a été refusé.

<auth_results> : le détail brut des vérifications. La différence avec <policy_evaluated> est importante : auth_results montre si SPF et DKIM ont techniquement réussi, tandis que policy_evaluated montre si l’alignement a réussi. SPF peut passer techniquement (l’IP est dans le SPF du domaine de retour) mais échouer l’alignement DMARC si ce domaine ne correspond pas au From visible.

<header_from> : le domaine dans le champ From visible par le destinataire. C’est le domaine que DMARC protège.

Identifier une IP inconnue

Pour chaque <source_ip> que vous ne reconnaissez pas, deux étapes :

Cherchez le propriétaire du bloc IP sur ipinfo.io ou en effectuant une recherche WHOIS. Les grands fournisseurs se reconnaissent à leur système autonome : AS15169 pour Google, AS8075 pour Microsoft.
Croisez avec le <envelope_from> ou <selector> dans <auth_results>. Le sélecteur DKIM google ou s1 vous donne souvent une indication sur l’expéditeur réel.

Outils gratuits pour visualiser les rapports

Les fichiers XML bruts sont lisibles mais fastidieux à analyser à la main dès que vous recevez une dizaine de rapports par jour. Ces quatre outils décodent et présentent vos données DMARC sans frais.

Postmark DMARC

dmarc.postmarkapp.com est le plus simple à mettre en place. Vous indiquez votre adresse rua= lors de la configuration, et Postmark vous envoie un résumé hebdomadaire par email avec les sources d’envoi, les volumes, et les taux de succès. Aucune interface web à surveiller quotidiennement.

Points forts : zéro friction, tableau récapitulatif par email. Limite : la granularité quotidienne n’est pas accessible sans compte payant.

dmarcian

Sur dmarcian.com, l’interface cartographie les sources d’envoi avec une vue géographique et classe automatiquement les IPs par type (messagerie principale, services tiers, sources inconnues).

Points forts : visualisation détaillée, vue agrégée sur plusieurs domaines. Limite : l’offre gratuite est limitée à un faible volume de rapports par mois.

EasyDMARC

easydmarc.com propose un tableau de bord, alertes, et outils de diagnostic complémentaires (vérificateur SPF, DKIM, blacklist). L’offre gratuite couvre un seul domaine avec un historique limité.

Points forts : tableau de bord complet, alertes en cas de nouvelle source détectée. Limite : fonctionnalités avancées réservées aux abonnements payants.

Google Postmaster Tools

postmaster.google.com est l’outil de Google pour les expéditeurs. Il affiche les statistiques de délivrabilité de votre domaine sur Gmail : taux de spam, réputation IP, volumes. Complémentaire aux rapports DMARC pour comprendre comment Gmail traite vos emails.

Points forts : données directement depuis Google, gratuit, sans configuration DNS supplémentaire. Limite : couvre uniquement Gmail, ne remplace pas un vrai analyseur DMARC.

Analyser un rapport ponctuel

Pour décoder un rapport XML à la main sans configurer un outil permanent, MXToolbox DMARC Report Analyzer accepte un fichier XML en entrée et affiche une vue tabulaire. Pratique pour le diagnostic d’un rapport spécifique.

Scénarios courants et leur résolution

Scénario 1 : un expéditeur légitime échoue l’authentification

Ce que vous voyez dans les rapports :

<source_ip>185.41.28.110</source_ip>
<count>312</count>
<policy_evaluated>
  <disposition>none</disposition>
  <dkim>fail</dkim>
  <spf>fail</spf>
</policy_evaluated>

Vous reconnaissez l’IP : c’est Brevo (ex-Sendinblue), votre outil de newsletter.

Diagnostic : DKIM n’est pas activé sur votre compte Brevo pour ce domaine. SPF échoue parce que le domaine de retour (bounce domain) de Brevo n’est pas aligné avec votre domaine principal.

Résolution :

Connectez-vous à Brevo → Paramètres → Expéditeurs & IP → Domaines
Ajoutez votre domaine, publiez l’enregistrement DKIM fourni dans votre DNS
Vérifiez dans Brevo que le domaine est validé
Attendez 48 heures, confirmez dans les prochains rapports que dkim=pass apparaît pour ces IPs

Pourquoi c’est urgent : tant que ce service échoue, passer en p=reject bloquerait vos propres newsletters.

Scénario 2 : des tentatives de spoofing

Ce que vous voyez dans les rapports :

<source_ip>45.33.89.142</source_ip>
<count>1847</count>
<policy_evaluated>
  <disposition>none</disposition>
  <dkim>fail</dkim>
  <spf>fail</spf>
</policy_evaluated>
<identifiers>
  <header_from>votredomaine.fr</header_from>
</identifiers>

Vous ne reconnaissez pas cette IP. WHOIS indique un hébergeur VPS à l’étranger. Vous n’avez aucun service chez cet hébergeur.

Diagnostic : quelqu’un utilise votre domaine dans le champ From pour envoyer des emails sans y être autorisé. C’est une tentative de spoofing. Avec p=none, ces 1 847 emails ont été délivrés aux destinataires.

Résolution : rien à corriger côté configuration. C’est exactement ce que DMARC doit bloquer. La correction est de passer en politique active. Avec p=reject, ces emails auraient été refusés avant d’atteindre les boîtes. La procédure est détaillée plus bas, dans la section passer DMARC en reject.

Scénario 3 : un service d’envoi oublié

Ce que vous voyez dans les rapports :

<source_ip>54.240.11.34</source_ip>
<count>42</count>
<policy_evaluated>
  <disposition>none</disposition>
  <dkim>fail</dkim>
  <spf>pass</spf>
</policy_evaluated>
<auth_results>
  <spf>
    <domain>amazonses.com</domain>
    <result>pass</result>
  </spf>
</auth_results>

L’IP appartient à Amazon SES. SPF passe (Amazon SES est autorisé sur un domaine de retour), mais DKIM échoue l’alignement et la disposition est none.

Diagnostic : une application de votre infrastructure utilise Amazon SES pour envoyer des emails (notifications automatiques, alertes, emails transactionnels) et vous ne le saviez pas (ou vous l’aviez oublié). L’alignement DKIM échoue parce que la clé DKIM n’est pas configurée avec votre domaine dans cette application.

Résolution :

Identifiez quelle application utilise Amazon SES avec ce compte (demandez à l’équipe dev)
Dans la console AWS SES → Verified identities → ajoutez votre domaine et publiez les enregistrements DKIM fournis
Vérifiez que l’application signe les emails avec votre domaine (et non amazonaws.com)

Cause fréquente : les développeurs configurent des relais SMTP pour des applications internes sans toujours coordonner avec l’équipe IT. Notifications de monitoring, alertes d’erreur, exports automatiques : tous peuvent apparaître dans vos rapports DMARC comme des sources inattendues.

Scénario 4 : les transferts d’emails

Ce que vous voyez dans les rapports :

<source_ip>217.182.116.51</source_ip>
<count>8</count>
<policy_evaluated>
  <disposition>none</disposition>
  <dkim>pass</dkim>
  <spf>fail</spf>
</policy_evaluated>

L’IP appartient à OVH. SPF échoue, DKIM passe. La disposition est none.

Diagnostic : des emails envoyés par vos utilisateurs sont transférés (forwarded) via un serveur OVH vers une boîte externe. Le transfert change l’IP expéditrice, ce qui casse SPF. DKIM reste intacte car la signature est attachée au message. DMARC passe grâce à DKIM.

Ce qu’il faut faire : rien, c’est le fonctionnement normal. DKIM est là précisément pour gérer ce cas. Si vous voyez des transferts avec double échec (dkim et spf à fail), c’est que le serveur intermédiaire modifie le contenu du message et invalide la signature DKIM. Dans ce cas, le serveur de transfert devrait implémenter ARC (Authenticated Received Chain), qui préserve l’authentification à travers les transferts : voir la section ARC de notre guide SPF, DKIM et DMARC.

Agir sur les résultats des rapports

Les rapports DMARC n’ont de valeur que si vous en tirez des actions concrètes. Voici comment structurer ce travail.

Établir une routine d’analyse

Pour la phase initiale (première configuration ou préparation d’une migration vers reject), analysez vos rapports chaque semaine pendant au moins un mois. Vous cherchez à :

Constituer l’inventaire complet de vos sources d’envoi. Chaque IP qui apparaît avec un volume significatif et un domaine header_from qui est le vôtre correspond à un service qui envoie des emails pour votre compte. Documentez-les tous.
Classer chaque source : légitime bien configurée, légitime mal configurée, ou frauduleuse/inconnue.
Prioriser les corrections par volume. Un service qui envoie 500 emails par jour avec un alignement fail est plus urgent à corriger qu’un service qui envoie 2 alertes par semaine.

Une fois en p=reject et vos sources stabilisées, une revue mensuelle suffit pour détecter l’apparition d’un nouveau service ou d’une nouvelle campagne de spoofing.

Préparer la migration vers une politique active

Les rapports DMARC sont la condition préalable à tout durcissement de politique. Avant de passer de p=none à p=quarantine, vous devez avoir résolu chaque ligne de vos rapports avec dkim=fail et spf=fail provenant d’IPs légitimes.

Un tableau de suivi simple suffit :

IP / Service	Volume/jour	DKIM	SPF	Alignement	Action
209.85.x.x (Google WS)	250	pass	fail	pass DMARC	RAS
185.41.x.x (Brevo)	85	fail	fail	fail	Configurer DKIM Brevo
54.240.x.x (SES)	42	fail	pass	fail	Identifier l’app, configurer DKIM
45.33.x.x (inconnu)	1847	fail	fail	fail	Spoofing, attendre p=reject

Ce tableau est votre liste de tâches avant de durcir la politique : chaque ligne en échec est un point de blocage pour la migration. Une fois ces corrections faites, suivez le plan de la section suivante.

Surveiller les nouvelles sources

Même avec une politique active et des rapports stables, continuez à surveiller l’apparition de nouvelles IPs sources. Deux signaux d’alerte :

Un nouveau service interne apparaît avec un alignement fail : une application déployée sans coordination avec l’équipe IT. À corriger avant qu’il soit bloqué.
Un volume de spoofing augmente fortement : votre domaine est ciblé par une campagne. Avec p=reject, ces emails sont refusés ; l’information reste utile pour anticiper d’autres vecteurs d’attaque.

Si vous utilisez un outil comme dmarcian ou EasyDMARC, activez les alertes pour toute nouvelle source d’envoi non vue auparavant. Vous recevrez un email dès qu’une IP inconnue envoie des emails avec votre domaine.

Passer DMARC en reject

Un enregistrement en p=none ne protège rien : il demande aux serveurs d’observer et de rapporter, sans écarter un seul email. Un attaquant qui écrit depuis contact@votredomaine.fr voit ses messages délivrés. La politique reject est la seule qui bloque réellement l’usurpation de votre domaine. Beaucoup de domaines restent pourtant en none, par peur de couper un flux légitime. La méthode qui suit lève cette crainte : on monte par paliers, en lisant les rapports à chaque étape, avec une marche arrière prête.

Les prérequis

Un seul enregistrement SPF, qui couvre tous vos services, se termine par -all et reste sous la limite de 10 résolutions DNS.
DKIM actif sur chaque service d’envoi, avec une signature à votre domaine (d=votredomaine.fr).
Un enregistrement DMARC en p=none avec une adresse rua= qui fonctionne, et au moins quatre semaines de rapports. Testez cette adresse : si la boîte a été supprimée, les rapports partent dans le vide.
Un TTL court (300 secondes) sur l’enregistrement DMARC pendant la migration, pour qu’une marche arrière prenne effet en quelques minutes. Remontez-le une fois la situation stable.

Notre test de sécurité email vérifie ces points en une fois.

Le calendrier, palier par palier

Semaines	Enregistrement	À vérifier avant le palier suivant
1 à 4	`v=DMARC1; p=none; rua=mailto:dmarc@votredomaine.fr; fo=1`	Toutes les sources légitimes identifiées et alignées en SPF ou DKIM
5 et 6	`p=quarantine; pct=25`	Aucun email légitime en spam, aucune nouvelle source en échec
7 et 8	`p=quarantine; pct=50`	Même contrôle, sur un volume plus large
9 et suivantes	`p=quarantine; pct=100`	Deux à quatre semaines sans faux positif
Ensuite	`v=DMARC1; p=reject; rua=mailto:dmarc@votredomaine.fr; fo=1`	Surveillance des nouvelles sources

Le tag pct= limite la politique à une part des emails en échec : à pct=25, un quart part en spam, le reste est traité comme en none. Ne sautez pas la quarantaine : un service oublié verrait ses emails refusés sans avertissement. Redescendez d’un palier dès qu’un volume d’emails légitimes attendus n’arrive plus, qu’une source inconnue à fort volume apparaît ou qu’une équipe signale un problème de délivrabilité. Comptez huit à douze semaines pour une migration prudente.

Les flux souvent oubliés

La première cause de blocage après un passage en reject est un service d’envoi absent de l’inventaire. Interrogez explicitement :

les RH et la paie (Lucca, Payfit, notifications du SIRH), souvent gérés hors de la DSI ;
les développeurs : applications qui envoient via Amazon SES, SendGrid ou un SMTP direct, alertes de supervision (Nagios, Zabbix, Grafana), scripts planifiés ;
le marketing et le support : Mailchimp (Account → Domains), HubSpot (Paramètres → Email → Authentification email), Zendesk ou Freshdesk ;
votre hébergeur : l’ancienne formule MX Plan d’OVH ne propose pas DKIM, il faut migrer vers la nouvelle formule ou passer par un relais SMTP qui signe.

Pour un serveur applicatif, deux options : un signataire DKIM sur le serveur (OpenDKIM sous Linux) ou un relais SMTP qui signe avec votre domaine. Les listes de diffusion, elles, modifient les messages (préfixe dans l’objet, pied de page) et cassent DKIM : si elles font partie de vos flux légitimes, leur gestionnaire doit mettre en place ARC.

Les sous-domaines

Sans tag sp=, les sous-domaines héritent de la politique du domaine principal (RFC 7489, section 6.3). Écrivez-le quand même : v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@votredomaine.fr. Un sous-domaine dont les services d’envoi ne sont pas encore corrigés (newsletter.votredomaine.fr) peut publier son propre enregistrement DMARC, qui prime sur celui du domaine parent.

Revenir en arrière si des emails légitimes sont bloqués

Deux options, selon l’urgence :

Repasser en quarantaine (p=quarantine; pct=100) : les emails en échec arrivent en spam au lieu d’être refusés, le destinataire peut les retrouver et vous avez le temps du diagnostic.
Suspendre la politique sans la retirer : v=DMARC1; p=reject; pct=0; rua=mailto:dmarc@votredomaine.fr l’applique à 0 % des emails, ce qui revient à p=none.

Cherchez ensuite, dans les rapports reçus depuis le changement, la source en double échec dont le volume correspond à l’incident et dont vous reconnaissez l’IP. Corrigez son alignement, vérifiez le pass dans les rapports suivants, puis reprenez la montée depuis la quarantaine. Si un partenaire ne reçoit plus vos emails, demandez-lui de regarder son dossier spam ou ses journaux SMTP : un rejet DMARC y laisse en général une ligne du type 550 5.7.1 ... rejected due to DMARC policy.

Ce que DMARC ne bloque pas

L’analyse des rapports et la politique reject protègent contre l’usurpation exacte de votre domaine. Elles ne couvrent pas les domaines sosies (votre-domaine-fr.com), les comptes compromis qui envoient depuis votre messagerie légitime, ni le phishing qui n’utilise pas votre domaine du tout. Ces emails-là arrivent dans les boîtes de vos salariés : la simulation de phishing les entraîne à les reconnaître, et le signalement avec analyse IA leur donne un réflexe simple quand ils ont un doute.

Questions fréquentes

À quelle fréquence les rapports DMARC sont-ils envoyés ?

Par défaut, les rapports agrégés (rua) sont envoyés une fois par jour, généralement en début de journée UTC. Vous pouvez spécifier un intervalle différent avec le tag ri= (reporting interval, en secondes), mais la grande majorité des fournisseurs ignorent ce tag et envoient quotidiennement de toute façon. Google, Microsoft et Yahoo envoient systématiquement un rapport par jour tant que votre domaine reçoit du trafic.

Quelle est la différence entre un rapport RUA et un rapport RUF ?

Le rapport RUA (aggregate) est un résumé quotidien par source d’envoi : il indique le nombre d’emails, l’IP, et les résultats SPF/DKIM agrégés. Le rapport RUF (forensic ou failure) est déclenché par chaque email individuel qui échoue, et peut contenir des éléments du message original (objet, en-têtes). Pour des raisons de confidentialité, la plupart des fournisseurs (Google, Microsoft) n’envoient plus de rapports RUF. Yahoo et quelques autres les envoient encore. En pratique, la quasi-totalité de votre données DMARC viendra des rapports RUA.

Je ne reçois aucun rapport DMARC : que faire ?

Vérifiez d’abord que votre enregistrement DMARC contient bien un tag rua= avec une adresse email valide. Ensuite, testez que cette adresse reçoit bien les messages (envoyez-vous un email de test). Si votre adresse rua= est sur un domaine différent de celui que vous protégez, vous devez publier un enregistrement d’autorisation sur ce domaine tiers : par exemple, si vous recevez les rapports de mondomaine.fr sur une adresse @mon-prestataire.com, publiez mondomaine.fr._report._dmarc.mon-prestataire.com TXT “v=DMARC1”. Sans cet enregistrement, la plupart des fournisseurs refusent d’envoyer les rapports.

Un rapport affiche des IPs inconnues avec dkim=fail et spf=fail : est-ce grave ?

C’est exactement ce que DMARC doit tracer, sans être forcément grave. Ces lignes représentent des serveurs qui ont envoyé des emails avec votre domaine dans le From sans y être autorisés : soit des tentatives de spoofing, soit des scanners automatiques qui testent les domaines. Si votre politique est p=none, ces emails ont été délivrés. Si vous êtes en p=quarantine ou p=reject, ils ont été bloqués. L’enjeu est de passer à une politique active pour que ces lignes se traduisent en blocages réels plutôt qu’en observations.

Combien de temps faut-il analyser les rapports avant de durcir la politique ?

Quatre semaines minimum en p=none avant de passer à quarantine. Ce délai permet de couvrir les cycles d’envoi complets : campagnes marketing mensuelles, factures, bulletins de paie, alertes de monitoring hebdomadaires. Un service qui n’envoie qu’une fois par mois peut ne pas apparaître dans une semaine de rapports. Après correction de toutes les sources légitimes en échec, montez progressivement : quarantine à 25 %, puis 50 %, puis 100 %, puis reject. Chaque palier mérite deux semaines d’observation.

Les rapports DMARC contiennent-ils des données personnelles ?

Les rapports RUA (agrégés) ne contiennent pas de données personnelles : ils listent des IPs, des volumes, et des résultats d’authentification. Les rapports RUF (forensic) peuvent contenir des en-têtes et parfois des extraits de corps d’email. C’est la raison pour laquelle Google et Microsoft ont arrêté d’envoyer des RUF. Si vous activez le tag ruf= et recevez des rapports forensic, traitez-les comme des données sensibles et ne les transmettez pas à un service tiers sans vérifier ses engagements de confidentialité.

Mon outil d’envoi d’emails n’apparaît pas dans les rapports DMARC. Pourquoi ?

Deux raisons possibles. Première raison : ce service n’a pas encore envoyé d’emails depuis que vous avez activé le reporting. Attendez un cycle d’envoi complet. Deuxième raison : le service envoie les emails depuis un domaine différent de celui que vous surveillez. Par exemple, il utilise un domaine de rebond (bounce domain) différent ou une adresse From sur un sous-domaine. Vérifiez l’adresse From réelle utilisée par ce service dans les en-têtes d’un email envoyé.

Puis-je confier l’adresse rua= à un prestataire ?

Oui. Des outils comme dmarcian ou EasyDMARC vous fournissent une adresse rua= à placer dans votre enregistrement DMARC : les rapports leur arrivent directement et s’affichent dans leur interface. C’est la configuration la plus confortable pour ne pas gérer une boîte remplie de fichiers XML. Les rapports agrégés ne contiennent pas de données personnelles ; ne transmettez pas de rapports forensic (ruf=) sans vérifier les engagements de confidentialité du prestataire.

Des emails légitimes sont bloqués après le passage en reject : que faire ?

Repassez immédiatement en p=quarantine, ou ajoutez pct=0 à votre enregistrement pour suspendre la politique sans la retirer. Cherchez ensuite dans les rapports la source légitime en échec d’alignement, corrigez son SPF ou activez DKIM, vérifiez le pass dans les rapports suivants, puis remontez la politique par paliers. Un TTL de 300 secondes sur l’enregistrement DMARC pendant la migration rend cette marche arrière quasi immédiate.

Thomas Ferreira (CISSP, GCFA, GCIH, GCFE), ingénieur sécurité chez nophi.sh. Ce guide s’appuie sur la RFC 7489, les recommandations de l’ANSSI et la documentation de Google et de Microsoft.