Aucun rapport DMARC reçu : les causes et le remède

v=DMARC1; p=none; rua=mailto:dmarc@exemple.fr

3. L'enregistrement est sur le mauvais nom d'hôte

Un enregistrement DMARC doit être publié sur _dmarc.exemple.fr, pas sur la racine exemple.fr. C'est une confusion fréquente : on colle la valeur v=DMARC1; … dans un enregistrement TXT à la racine, et les destinataires ne la trouvent jamais, car ils cherchent spécifiquement sur le sous-nom _dmarc. L'hôte de l'enregistrement TXT mérite donc une vérification : s'il est à la racine, il faut le republier sur _dmarc.

4. L'enregistrement a une erreur de syntaxe

Un enregistrement invalide peut être ignoré en bloc. Les fautes qui cassent la lecture : v=DMARC1 mal orthographié ou pas en première position, deux enregistrements DMARC distincts sur _dmarc (il ne doit y en avoir qu'un), des points-virgules manquants, ou des guillemets parasites ajoutés à l'intérieur de la valeur. Un seul de ces défauts et le destinataire considère qu'il n'y a pas de politique DMARC exploitable — donc pas de rapport.

5. La destination externe n'est pas autorisée

Voici le piège le plus subtil, et une cause silencieuse très répandue. Quand la balise rua pointe vers une adresse d'un domaine différent de celui qui publie la politique (par exemple un service d'analyse), ce domaine récepteur doit publier un enregistrement d'autorisation, faute de quoi les destinataires refusent d'envoyer les rapports.

Concrètement, pour que exemple.fr envoie ses rapports à dmarc@prestataire.com, le domaine prestataire.com doit publier :

exemple.fr._report._dmarc.prestataire.com  IN TXT  "v=DMARC1"

Si cet enregistrement manque, rien n'arrivera via cette adresse externe, même avec une syntaxe rua parfaite. Le mécanisme complet est détaillé dans configurer l'adresse rua. Le remède le plus simple pour tester : pointer temporairement rua vers une adresse du domaine lui-même, qui ne requiert aucune autorisation. Si les rapports arrivent alors, la cause est isolée.

6. Le domaine reçoit trop peu de courrier

Un rapport agrégé n'est envoyé que par un destinataire qui a reçu du courrier prétendant venir du domaine. Si celui-ci émet très peu — ou si personne n'en usurpe encore le nom — il n'y a tout simplement pas grand-chose à rapporter. Les petits domaines à faible volume reçoivent naturellement moins de rapports, et parfois seulement de quelques grands fournisseurs. Ce n'est pas un bug : c'est le reflet du trafic réel. Un email de test envoyé depuis le domaine vers une adresse Gmail ou Outlook fait normalement apparaître un rapport de ce fournisseur le lendemain. C'est d'ailleurs le meilleur test isolé : il génère à coup sûr du trafic observable chez un fournisseur qui, lui, envoie fiablement des rapports — si rien n'arrive après ce test, le problème est dans la configuration, pas dans le volume.

7. Les rapports arrivent… mais en indésirable

Ironie fréquente : les rapports arrivent bien, mais la messagerie les classe en spam. Les fichiers XML compressés envoyés par des serveurs automatiques ressemblent, pour un filtre anti-spam, à du courrier suspect. Avant de conclure au silence, le dossier indésirable de l'adresse rua mérite un coup d'œil. Les y trouver, c'est pouvoir créer une règle qui les achemine vers un dossier dédié — et récupérer d'un coup tout l'historique qu'on croyait perdu.

8. Tous les destinataires n'envoient pas de rapports

Enfin, l'envoi de rapports agrégés n'est pas universel. La grande majorité des gros fournisseurs (Gmail, Yahoo, Outlook, La Poste, et beaucoup d'autres) en envoient, mais certains petits serveurs de messagerie n'en émettent pas du tout. Aucun domaine ne reçoit donc de rapport de chaque destinataire de son courrier — seulement de ceux qui participent. C'est normal, et la couverture des grands acteurs suffit largement à avoir une vision fiable du trafic.

Prévention : une adresse rua faite pour durer

Beaucoup de silences de rapports naissent le jour où l'adresse est choisie. Pointer rua vers la boîte personnelle de quelqu'un fonctionne — jusqu'au départ de cette personne, à la désactivation du compte, et aux rapports qui rebondissent dans le vide sans que personne ne s'en aperçoive. Une boîte qui se remplit en silence produit le même symptôme : les destinataires tentent de livrer, le message est refusé, et côté domaine ça ressemble simplement à du silence. Mieux vaut une adresse de service dédiée, avec un accès délégué à plusieurs personnes, exclue des règles de nettoyage automatique agressives, et avec assez de marge de quota pour un flux régulier de pièces jointes. C'est une petite décision au moment de la mise en place qui élimine toute une famille de pannes futures — celles qui se révèlent des mois plus tard, précisément quand l'historique devient le plus nécessaire.

Pourquoi il faut régler ce silence, et vite

On pourrait croire qu'un domaine sans rapports « fonctionne quand même » — après tout, la politique est publiée. C'est une illusion dangereuse. Sans rapports, le pilotage se fait à l'aveugle : rien n'indique qu'une source légitime échoue à l'alignement, ni qu'un attaquant teste déjà le nom. Pire, le durcissement ne peut plus se faire en sécurité, car la décision de passer en quarantine puis reject repose entièrement sur ce que montrent les rapports. Un domaine bloqué en p=none sans reporting cumule le pire des deux mondes : aucune protection, et aucune visibilité pour en gagner.

C'est pourquoi le silence des rapports n'est pas un détail cosmétique à traiter « quand on aura le temps » : c'est un blocage sur le chemin critique vers l'application. Le diagnostic ci-dessus mérite d'être fait dès les premiers jours suivant la publication, pas des mois plus tard quand on se demande pourquoi le projet DMARC n'avance pas.

Un cas particulier : les rapports qui s'arrêtent soudainement

Le scénario diffère quand des rapports arrivaient et ont cessé. Là, les causes « débutant » (mauvais hôte, rua absente) sont exclues, puisque ça marchait. C'est plutôt un changement récent qu'il faut chercher :

• Un enregistrement DMARC réécrit par erreur lors d'une migration DNS ou d'un changement d'outil, qui a supprimé ou déformé la balise rua.
• Une adresse rua qui n'existe plus — la boîte a été supprimée, ou la redirection vers le service d'analyse a été rompue.
• Une autorisation externe expirée ou retirée côté prestataire, dans le cas d'une destination externe.
• Un filtre anti-spam devenu plus agressif, qui s'est mis à capturer les rapports jusque-là visibles.

La comparaison entre l'enregistrement actuel et celui qui fonctionnait tranche vite : la cause d'un arrêt brutal est presque toujours un changement daté, donc retrouvable.

La méthode de diagnostic, en résumé

Face à un silence des rapports, les causes se déroulent dans cet ordre :

1. Patienter 48 h — les rapports sont quotidiens.
2. Vérifier la présence et la syntaxe de rua (mailto:, pas ruf).
3. Contrôler le nom d'hôte — sur _dmarc, pas à la racine.
4. Valider la syntaxe globale — un seul enregistrement, v=DMARC1 en tête.
5. Tester avec une adresse du domaine lui-même pour éliminer le piège de l'autorisation externe.
6. Envoyer un email de test vers Gmail/Outlook pour générer du trafic à rapporter.
7. Regarder le dossier spam.

Neuf fois sur dix, le coupable est dans les cinq premiers points — et le plus souvent, c'est soit l'impatience, soit l'autorisation externe manquante. Cet ordre n'est pas arbitraire : il place en tête les causes les plus fréquentes et les moins coûteuses à écarter, pour éviter de perdre une heure sur un cas rare avant d'avoir éliminé l'évident.

Pour trancher rapidement entre « la configuration est cassée » et « il faut juste attendre », un passage du domaine dans l'analyseur DMARC gratuit suffit : il dit immédiatement si l'enregistrement est valide, si rua est correctement formé et lisible par les destinataires, et donc si le problème vient de la configuration ou simplement du délai. C'est le moyen le plus rapide de savoir de quel côté chercher.