Pas de rapports DMARC ? Une liste de contrôle pour trouver pourquoi

Vous avez publié un enregistrement DMARC avec une adresse rua=, attendu quelques jours, et votre boîte est vide. Aucun rapport, aucune erreur, rien qui vous dise si l'enregistrement est cassé ou si vous êtes simplement trop tôt. Les causes sont peu nombreuses et faciles à vérifier une fois que l'on connaît l'ordre à suivre. Ce guide déroule la liste de contrôle, du test le moins cher (la patience) aux plus techniques comme l'autorisation du destinataire externe, et explique à quoi ressemble chaque défaillance.

La réponse en bref#

Des rapports DMARC manquants s'expliquent presque toujours par l'une des sept causes suivantes : vous n'avez pas encore attendu 24 à 48 heures, l'enregistrement est au mauvais nom DNS, il existe plus d'un enregistrement DMARC, la valeur rua= est mal formée (elle doit commencer par mailto:), l'adresse de rapport se trouve dans un autre domaine sans autorisation, votre domaine envoie trop peu de courrier pour que les destinataires produisent un rapport, ou la boîte aux lettres filtre les pièces jointes compressées. Vérifiez-les dans cet ordre. Une recherche en direct de _dmarc.votredomaine.com règle les quatre premières en moins d'une minute. dig TXT _dmarc.votredomaine.com +short est ce qui révèle un second enregistrement, car le vérificateur gratuit SPF, DKIM et DMARC n'affiche que le premier qu'il trouve et ne contrôle pas la syntaxe de rua=. Si l'enregistrement est propre et que quelques jours se sont écoulés, regardez la boîte de destination.

Étape 1 : laissez du temps, et sachez qui envoie des rapports#

Les fournisseurs regroupent ce qu'ils ont vu sur une journée et envoient un rapport par domaine : les premiers rapports arrivent donc 24 à 48 heures après la mise en ligne de l'enregistrement, parfois plus tard. Rien n'arrivera le premier jour.

Deux autres points fixent les attentes :

• Tous les destinataires n'envoient pas de rapports. Les grands fournisseurs de messagerie le font. Beaucoup de plus petits ne le feront jamais. Vous collectez un échantillon de fournisseurs, pas un journal complet.
• Un destinataire ne fait un rapport que s'il a vu du courrier de votre part. Si votre domaine n'a rien envoyé à un fournisseur donné hier, ce fournisseur n'a rien à signaler.

Si vous avez attendu trois jours pleins, passez à l'enregistrement.

Étape 2 : confirmez que l'enregistrement est au bon endroit#

Les enregistrements DMARC vivent à un nom précis : _dmarc. devant votre domaine. Un enregistrement publié sur le domaine nu, ou sur dmarc.example.com, est ignoré. Regardez ce qui est réellement publié :

dig TXT _dmarc.example.com +short
"v=DMARC1; p=none; rua=mailto:reports@example.com"

Points à vérifier dans la réponse :

• L'enregistrement existe. Certains hébergeurs DNS veulent seulement _dmarc dans le champ hôte, pas le nom complet. Saisir le nom complet leur fait ajouter votre domaine deux fois. Les étapes propres à chaque hébergeur figurent dans des guides comme Cloudflare et GoDaddy.
• Il commence par v=DMARC1, exactement, sans rien avant.
• Il contient une balise p=. Selon la RFC 9989, un enregistrement sans p= valide mais avec un rua= valide est traité comme p=none et reçoit quand même des rapports : ce n'est donc généralement pas la cause de rapports manquants, mais publiez la balise explicitement malgré tout.
• Les balises sont séparées par des points-virgules.

N'oubliez pas le cache DNS. Si vous venez de modifier l'enregistrement, les destinataires peuvent utiliser l'ancienne copie jusqu'à l'expiration du TTL.

Étape 3 : assurez-vous qu'il n'y a qu'un seul enregistrement DMARC#

Un domaine doit publier un seul enregistrement DMARC. Si deux enregistrements TXT à _dmarc commencent tous deux par v=DMARC1, les destinataires les ignoreront généralement tous les deux, et l'envoi de rapports s'arrête. Cela arrive quand quelqu'un ajoute un nouvel enregistrement sans supprimer l'ancien, ou quand une migration DNS copie l'enregistrement en double.

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:old@example.com"
_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:new@example.com"

Supprimez-en un, gardez l'autre, et fusionnez les adresses dans une seule liste rua=. Plusieurs destinations de rapport se séparent par des virgules dans un seul enregistrement, pas en publiant d'autres enregistrements.

Étape 4 : vérifiez la syntaxe de rua#

La valeur rua= est une liste d'URI, et chacune doit commencer par mailto:. Erreurs typiques :

La dernière ligne piège beaucoup de monde. Les rapports agrégés viennent de rua. Ne définir que ruf ne vous donnera presque rien. La liste complète des balises se trouve dans comment configurer DMARC.

Étape 5 : autorisez l'envoi des rapports vers un autre domaine#

C'est la cause que l'on manque le plus souvent. Si votre adresse rua= se trouve dans un domaine différent de celui que l'enregistrement protège, les destinataires vérifient que l'autre domaine a accepté de recevoir les rapports. Sinon, n'importe qui pourrait diriger des flots de rapports vers la boîte d'une victime.

Prenons cet enregistrement pour example.com :

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:reports@thirdparty.example.net"

Comme l'adresse est en dehors de example.com, le domaine destinataire doit publier un enregistrement d'autorisation dont le nom est construit à partir de votre domaine :

example.com._report._dmarc.thirdparty.example.net.  TXT  "v=DMARC1;"

Si cet enregistrement TXT n'existe pas, les destinataires conformes abandonnent le rapport. Vous pouvez le vérifier avec :

dig TXT example.com._report._dmarc.thirdparty.example.net +short

Deux remarques pratiques :

• Si vous contrôlez les deux domaines, ajoutez simplement l'enregistrement d'autorisation à la destination. Si un fournisseur reçoit les rapports pour vous, il publie normalement cet enregistrement à votre place ou vous dit de le faire.
• Envoyer les rapports vers une boîte de votre propre domaine évite entièrement cette vérification : c'est pourquoi un simple transfert dmarc@votredomaine.com est la configuration la moins fragile.

Étape 6 : vérifiez la boîte de destination#

Si l'enregistrement est valide et l'autorisation en place, les rapports arrivent peut-être et se perdent :

• Filtrage des pièces jointes. Les rapports arrivent en pièces jointes .gz ou .zip, parfois en XML brut. Les filtres qui suppriment les pièces jointes compressées les éliminent sans rien dire. Vérifiez les spams, la quarantaine et toute règle qui supprime les archives.
• Boîte pleine. Un domaine actif peut produire des dizaines de rapports par jour. Une petite boîte partagée se remplit vite et se met à les refuser.
• Alias ou transfert qui réécrit. Un alias de groupe qui bloque les expéditeurs externes refusera les rapports des fournisseurs.

Cherchez les objets contenant « Report Domain » et le nom de votre domaine. Si vous n'en voyez aucun après avoir vérifié le filtrage, le problème est en amont.

Une boîte dédiée, ou un service qui reçoit les rapports à votre place, évite l'essentiel de ces écueils. Le XML brut dans une boîte personnelle noie aussi le signal, comme l'explique comment lire les rapports DMARC.

Si vous utilisez une adresse de rapport Qualisend#

Si votre rua= pointe vers une adresse <key>@dmarc.qualisend.com du module Rapports DMARC, les vérifications côté destination sont gérées pour vous. Qualisend publie un enregistrement d'autorisation générique : les fournisseurs enverront donc à cette adresse pour n'importe quel domaine, et vous n'ajoutez pas l'enregistrement d'autorisation de l'étape 5. Voici ce qui peut encore bloquer les données :

• Le domaine n'est pas couvert. Les rapports ne sont stockés que pour les domaines dont la couverture est activée dans votre espace de travail, ou pour un sous-domaine de l'un d'eux. Un rapport pour un domaine non couvert est accepté mais pas enregistré : le tableau de bord reste donc vide.
• L'abonnement n'est pas actif. Les rapports envoyés à une adresse dont l'espace de travail n'a pas d'abonnement DMARC actif sont refusés.
• L'adresse a été renouvelée. Après un renouvellement, l'ancienne adresse cesse d'accepter du courrier immédiatement : tout rua= qui la liste encore perdra des rapports jusqu'à la mise à jour du DNS.
• L'enregistrement ne liste pas l'adresse. Si un enregistrement DMARC existe déjà, ajoutez ,mailto:<address> à sa liste rua= et conservez la politique et les autres adresses.

Qualisend ne modifie jamais votre DNS. La modification de l'enregistrement vous revient, chez votre hébergeur DNS. La page vous indique que les premiers rapports arrivent généralement dans les 24 à 48 heures, ce qui correspond au comportement des fournisseurs.

Sous-domaines et enregistrement qui s'applique#

Si les rapports manquants concernent un sous-domaine, regardez ce qui y est réellement publié. Un sous-domaine qui a son propre enregistrement DMARC utilise celui-ci, et si cet enregistrement n'a pas de rua=, rien n'est envoyé à l'adresse du parent. Un sous-domaine sans enregistrement retombe sur l'enregistrement du domaine parent et sa politique sp=. Les rapports nomment le domaine de la politique : cherchez-les sous ce nom plutôt que sous votre domaine principal.

Il vaut la peine de passer tout le domaine dans un contrôle de santé du domaine après toute modification du DNS. Il signale un enregistrement DMARC manquant, un enregistrement sans balise de politique et une politique p=none, et affiche l'enregistrement publié pour que vous lisiez vous-même la valeur rua=. La surveillance de la santé du domaine payante vous avertit aussi quand une politique valide n'a aucun rua=. Si le problème revient après des modifications DNS, le guide de la surveillance de la santé du domaine explique comment le repérer avant que les rapports ne s'arrêtent.

Une dernière liste de contrôle#

• Attendez 48 heures après la mise en ligne de l'enregistrement.
• Lancez dig TXT _dmarc.votredomaine.com et lisez le résultat.
• Confirmez un seul enregistrement, commençant par v=DMARC1, avec un p= explicite.
• Confirmez rua=mailto: avec des virgules entre les adresses.
• Si l'adresse est dans un autre domaine, vérifiez l'enregistrement d'autorisation _report._dmarc.
• Vérifiez les spams, la quarantaine, les limites de taille et les filtres de la boîte de destination.
• Assurez-vous que le domaine a bien envoyé du courrier à des fournisseurs qui font des rapports.

Quand les rapports arrivent enfin, la tâche suivante est de les comprendre, ce que couvrent la surveillance DMARC et qui envoie avec votre domaine.

Faire arriver les rapports DMARC vous montre qui envoie avec votre domaine, mais pas si votre liste est propre. Si vous voulez ensuite contrôler la liste, l'offre gratuite de la page des tarifs vous donne 100 crédits pour la vérification complète, et le vérificateur d'e-mails gratuit traite les adresses isolées. Une authentification qui fonctionne a quand même besoin d'une liste saine pour mériter la boîte de réception.