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.ton-domaine.fr.  IN TXT
  "v=DMARC1; p=quarantine; rua=mailto:dmarc@ton-domaine.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 : tu vois les tendances sur la journée, tu détectes une nouvelle source ou un pic anormal 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.

Si tu gères un domaine critique où un incident de sécurité sur les 24 premières heures pourrait avoir un impact majeur, surveille l'activité en temps réel via ton outil DMARC plutôt qu'en essayant 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 que tu reçois à 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 t'arrive. 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).
• Tu le reçois quelques minutes à quelques heures plus tard selon le routage email.

Concrètement : si tu veux savoir ce qui s'est passé hier, le rapport du lendemain matin te le dira. 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 tes 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. Ne pointe pas rua= vers ta boîte personnelle : les rapports noieraient tes vrais messages, et un filtre un peu zélé finirait par les classer en indésirable, voire les supprimer. Crée plutôt une adresse dédiée à cet usage, sans quota trop serré. Si tu passes par une plateforme DMARC, c'est elle qui expose l'adresse de collecte et la question disparaît. Si tu traites les rapports à la main, prévois une règle de tri automatique et une purge régulière : une boîte pleine rejette les rapports entrants, et tu perds ta visibilité sans t'en apercevoir.

Et si je ne reçois aucun rapport ?

Si aucun rapport n'arrive après quelques jours, vérifie dans l'ordre :

1. L'enregistrement DMARC est-il publié ? (dig TXT _dmarc.ton-domaine.fr doit retourner ton enregistrement).
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 ? Vérifie la boîte spam de l'adresse destinataire.

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=. Si tu migres vers DMARCbis (voir migrer vers ce nouveau standard), ta valeur ri= 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 est la bonne valeur pour la plupart des cas. Si tu veux être explicite, ajoute ri=86400 ; sinon, omets-le.

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. Ne compte pas sur une fréquence inférieure à 24h.

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. Tu peux recevoir le rapport Gmail à 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 : si tu publies ton enregistrement DMARC à 15h, le premier rapport peut ne couvrir 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. Si ton activité est principalement 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 quand tu analyses 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. Concentre-toi sur les 30 derniers jours pour ton diagnostic courant, et garde l'historique long pour les tendances.

Ce que tu devrais réellement surveiller (et à quelle fréquence)

La vraie question n'est pas « à quelle fréquence est-ce que je reçois des rapports ? » mais « à quelle fréquence est-ce que je les lis ? ». Et là, la bonne réponse dépend de ta phase de déploiement DMARC.

En phase d'observation (politique p=none) : lis tes rapports hebdomadairement. Tu ne prends aucun risque d'interruption, les changements sont lents (identifier et corriger ses sources prend du temps), et une revue hebdomadaire suffit à suivre les progrès. En phase de transition (p=quarantine) : lis les rapports quotidiennement pendant les premières semaines, ou configure des alertes. C'est là que tu peux involontairement bloquer un flux légitime — tu veux le détecter vite. Une fois stabilisé en quarantaine depuis quelques semaines, reviens à un rythme hebdomadaire. 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 — te 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 que tu surveilles et que tu réagis. Une plateforme DMARC qui conserve l'historique des rapports et journalise les alertes remplit ce rôle sans que tu aies à archiver des centaines de XML. Si cette dimension audit t'est imposée, vérifie que l'outil que tu choisis propose un historique long (au moins 90 jours) et des exports pour les besoins de conformité.

Laisse Thomas surveiller la fréquence pour toi

La vraie valeur n'est pas dans la fréquence des rapports, mais dans ce que tu en fais. Thomas, ton RSSI virtuel, surveille les rapports à ta place, t'alerte quand quelque chose d'inhabituel apparaît — une nouvelle IP, un pic d'échecs, une source qui cesse de passer — et te dit quoi faire, pas juste quoi regarder.

Analyse ton domaine gratuitement ou crée un compte pour une surveillance DMARC sans interruption.