ri= dans DMARC : fréquence des rapports et ce que ça change

ri=86400   → rapports quotidiens (défaut, recommandé)
ri=3600    → rapports toutes les heures (si le FAI le supporte)
ri=604800  → rapports hebdomadaires

_dmarc.exemple.fr.  IN TXT
  "v=DMARC1; p=quarantine; rua=mailto:dmarc@exemple.fr; ri=86400"

Pourquoi 86400 (24h) est la valeur à retenir

Pour la quasi-totalité des contextes, ri=86400 est la valeur à utiliser — ou simplement omettre ri=, ce qui revient au même (la valeur par défaut est 86400). Voici pourquoi :

• C'est la cadence que les FAI appliquent réellement.
• Un rapport quotidien donne un volume d'information gérable : les tendances de la journée ressortent, une nouvelle source ou un pic anormal se détecte en 24h maximum.
• Un rapport plus fréquent n'apporte pas plus d'information utile — juste plus de bruit si jamais certains acteurs le respectent.
• Un rapport hebdomadaire (ri=604800) retarde trop la détection d'un problème.

Sur un domaine critique où un incident de sécurité dans les 24 premières heures pourrait avoir un impact majeur, la bonne réponse est une surveillance en temps réel via un outil DMARC, pas une tentative de modifier ri= — c'est plus efficace.

Le délai entre l'envoi et la réception des rapports

Un point souvent mal compris : le rapport qui arrive à 8h du matin couvre la période de la veille, pas de la journée courante. Il y a toujours un décalage entre le moment où les messages ont été évalués et le moment où le rapport parvient au domaine. En pratique :

• La période de rapport couvre généralement 00h00→23h59 UTC.
• Le rapport est généré et envoyé dans les premières heures suivantes (souvent entre 3h et 9h UTC).
• Il est remis quelques minutes à quelques heures plus tard selon le routage email.

Concrètement : ce qui s'est passé hier se lit dans le rapport du lendemain matin. Pour les incidents du jour même, il faut attendre le rapport du lendemain. C'est pourquoi une plateforme DMARC avec une vue continue est plus utile qu'une surveillance manuelle des rapports.

Une boîte dédiée pour recevoir les rapports

Point pratique souvent négligé : la boîte qui reçoit tout ça. Avec une cadence quotidienne et plusieurs FAI qui envoient chacun leur fichier, l'adresse rua= accumule vite plusieurs pièces jointes compressées par jour — du XML en .zip ou .gz, illisible à l'œil nu. Pointer rua= vers une boîte personnelle est une erreur : les rapports noieraient les vrais messages, et un filtre un peu zélé finirait par les classer en indésirable, voire les supprimer. Mieux vaut une adresse dédiée à cet usage, sans quota trop serré. Avec une plateforme DMARC, c'est elle qui expose l'adresse de collecte et la question disparaît. En traitement manuel, il faut prévoir une règle de tri automatique et une purge régulière : une boîte pleine rejette les rapports entrants, et la visibilité disparaît sans que personne s'en aperçoive.

Et si aucun rapport n'arrive ?

Si rien n'arrive après quelques jours, les contrôles à mener dans l'ordre :

1. L'enregistrement DMARC est-il publié ? (dig TXT _dmarc.exemple.fr doit le retourner).
2. L'adresse rua= est-elle correcte ? Une faute de frappe, une boîte inexistante ou un domaine incorrect suffit à tout perdre.
3. Si rua= pointe vers un domaine externe (par exemple une plateforme DMARC), ce domaine doit avoir un enregistrement DNS d'autorisation (_dmarc.domaine-externe.fr TXT "v=DMARC1").
4. Le domaine envoie-t-il du courrier ? Un domaine qui n'envoie rien ne génère pas de rapport — normal.
5. Les rapports ne sont-ils pas en spam ? La boîte indésirable de l'adresse destinataire mérite un coup d'œil.

ri= dans DMARCbis (RFC 9989)

Dans la nouvelle version de DMARC (DMARCbis), le paramètre ri= reste présent et garde le même sens. Les changements majeurs de DMARCbis concernent d'autres balises (pct supprimé, np et t ajoutés) — pas ri=. En cas de migration vers DMARCbis (voir migrer vers ce nouveau standard), la valeur ri= en place reste valide sans modification.

Questions fréquentes

Dois-je inclure ri= dans mon enregistrement ? Non, c'est optionnel. La valeur par défaut est 86400, ce qui convient à la plupart des cas. Par souci d'explicite, ri=86400 peut être ajouté ; sinon, l'omission suffit.

Puis-je demander des rapports toutes les heures ? Techniquement oui (ri=3600), mais la quasi-totalité des FAI l'ignorent et envoient quand même quotidiennement. Une fréquence inférieure à 24h ne se pilote pas depuis l'enregistrement.

ri= s'applique-t-il aussi aux RUF ? Non. ri= concerne les rapports agrégés (RUA). Les rapports forensiques (RUF) sont déclenchés par événement (un message qui échoue), pas par intervalle.

Que se passe-t-il si je reçois des rapports de plusieurs FAI à des horaires différents ? C'est normal — chaque FAI génère et envoie son rapport à son propre horaire. Le rapport Gmail peut arriver à 6h et le rapport Microsoft à 14h, tous deux pour la même période. Les outils DMARC les agrègent automatiquement.

Un rapport peut-il couvrir une période différente de 24h ? Oui, notamment au démarrage : un enregistrement DMARC publié à 15h peut donner un premier rapport ne couvrant que les 9 heures restantes de la journée. Les rapports suivants reviennent à 24h.

Comment les rapports couvrent-ils plusieurs fuseaux horaires ? Les rapports utilisent des timestamps Unix (UTC) pour les date_range. C'est le FAI qui décide de la période couverte, généralement 00h00→23h59 UTC. Quand l'activité se concentre dans un fuseau différent (UTC+2, UTC-8…), les rapports peuvent couper une journée de travail en deux périodes de rapport. C'est un détail qui compte au moment d'analyser un incident sur une journée précise.

Les rapports DMARC ont-ils une durée de validité ? Non, ils n'expirent pas — mais leur valeur diminue avec le temps. Un rapport de six mois n'est utile que pour comparer l'évolution d'une configuration, pas pour le diagnostic de la situation actuelle. Le diagnostic courant se joue sur les 30 derniers jours ; l'historique long sert aux tendances.

Ce qu'il faut réellement surveiller (et à quelle fréquence)

La vraie question n'est pas « à quelle fréquence les rapports arrivent-ils ? » mais « à quelle fréquence sont-ils lus ? ». Et là, la bonne réponse dépend de la phase de déploiement DMARC.

En phase d'observation (politique p=none) : une lecture hebdomadaire des rapports. Aucun risque d'interruption, les changements sont lents (identifier et corriger ses sources prend du temps), et une revue par semaine suffit à suivre les progrès. En phase de transition (p=quarantine) : lecture quotidienne pendant les premières semaines, ou alertes configurées. C'est là qu'un flux légitime peut être bloqué involontairement — et il faut le détecter vite. Une fois la quarantaine stabilisée depuis quelques semaines, le rythme hebdomadaire reprend. En phase stable (p=reject) : une revue mensuelle est souvent suffisante, complétée par des alertes automatiques pour les anomalies (nouvelle IP inconnue, pic d'échecs soudain). Le monitoring devient de la maintenance, pas de l'investigation.

Le ri= ne change rien à cette logique — les rapports arrivent quotidiennement dans tous les cas. C'est la cadence de lecture et d'analyse qui compte, pas celle de réception.

Rapports et audit de sécurité

Pour les organisations soumises à des audits (ISO 27001, NIS2, secteur bancaire…), les rapports DMARC constituent une preuve de monitoring. Conserver un historique des rapports — même partiel — permet de montrer lors d'un audit que la politique DMARC est surveillée et que les anomalies sont détectées et traitées. C'est le même raisonnement que pour les logs de pare-feu : leur valeur n'est pas dans la lecture quotidienne, mais dans la capacité à prouver qu'une surveillance existe et qu'elle déclenche des réactions. Une plateforme DMARC qui conserve l'historique des rapports et journalise les alertes remplit ce rôle sans qu'il faille archiver des centaines de XML. Quand cette dimension audit est imposée, deux points à vérifier sur l'outil retenu : un historique long (au moins 90 jours) et des exports pour les besoins de conformité.

Thomas surveille la fréquence

La vraie valeur n'est pas dans la fréquence des rapports, mais dans ce qu'on en fait. Thomas, le RSSI virtuel, surveille les rapports en continu, alerte dès que quelque chose d'inhabituel apparaît — une nouvelle IP, un pic d'échecs, une source qui cesse de passer — et dit quoi faire, pas juste quoi regarder.

Analyser un domaine gratuitement ou créer un compte pour une surveillance DMARC sans interruption.