DMARC RUA : configurer et lire les rapports agrégés

DMARC RUA indique dans votre enregistrement DMARC les destinations demandées pour les rapports agrégés. Sans ce champ, la politique peut exister, mais vous perdez une source d'information sur l'authentification et l'alignement. Les rapports restent partiels et ne prouvent pas à eux seuls l'identité des sources ou une usurpation. Pour les bases, commencez par la messagerie professionnelle pour petites entreprises.

Un CRM mal configuré, une extension WordPress oubliée ou un transfert affectant SPF peuvent compliquer le diagnostic. RUA apporte des données pour les examiner, sans expliquer à lui seul toutes les décisions de filtrage de Gmail.

Ce guide explique RUA, sa publication, le contenu XML et la manière de prioriser les corrections.

Qu'est-ce que DMARC RUA ?

RUA désigne le champ de destination des rapports agrégés d'authentification. Ils résument SPF, DKIM, alignement, IP source et disposition pour une période, souvent quotidienne, sur le trafic des destinataires participants.

Dans DMARC, rua=mailto:... demande l'envoi des rapports agrégés à cette destination. Selon la RFC 7489, rua définit où envoyer des données d'authentification, d'alignement, de domaines, de volume et de politique appliquée.

Observer le trafic aide à évaluer p=none, p=quarantine ou p=reject. RUA fournit des indices, sans démontrer que tous les expéditeurs légitimes sont prêts pour une politique restrictive.

Ce que montrent réellement les rapports RUA

Ce sont des synthèses agrégées, pas des copies de messages. Elles montrent sources observées, authentification SPF/DKIM et alignement DMARC. Distinguez les résultats bruts des résultats évalués pour la politique, qui incorporent l'alignement.

Vous ne recevez pas les corps des messages, mais des données pour rechercher erreurs de prestataires, défauts d'alignement et abus possibles. Complétez avec inventaire et tests.

Commencez par RUA et envisagez ruf pour un besoin précis. Les rapports forensiques ont un support irrégulier et soulèvent davantage de questions de confidentialité.

Exemple : votre domaine envoie via Google Workspace, une application de facturation et le support. RUA peut montrer des sources observées de ces services, sans garantir qu'ils apparaissent tous. Un défaut d'alignement demande une enquête ; une IP dans un autre pays ne prouve pas une usurpation.

Publier RUA

Ajoutez un TXT sous _dmarc.yourdomain.com avec une destination valide rua=mailto:. Commencez par la surveillance si l'inventaire des expéditeurs reste incomplet.

Cet exemple utilise l'alignement strict facultatif, qui peut affecter des sous-domaines légitimes et n'est pas le meilleur choix initial pour tous :

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s"

Cette alternative minimale utilise l'alignement souple par défaut. Publiez un seul enregistrement, pas les deux :

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

Utilisez une boîte dédiée ou un service d'analyse. Évitez de mélanger les pièces jointes XML compressées aux demandes ordinaires du support.

Pour TrekMail, consultez les Enregistrements DNS requis. Les contrôles disponibles de SPF, DKIM et DMARC facilitent la vérification, sans garantir la détection de tous les problèmes ou expéditeurs externes.

Vérifier RUA

Interrogez directement le DNS, puis vérifiez la réception des rapports. Une configuration incorrecte peut empêcher les participants d'obtenir une destination valide ; une boîte vide peut aussi avoir d'autres causes.

Utilisez dig ou nslookup :

dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com

La réponse devrait montrer votre TXT DMARC. Selon la RFC 7489, voici un autre exemple valide, pas un enregistrement à ajouter aux précédents :

"v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com"

Les rapports sont souvent quotidiens, mais fréquence et participation varient. Leur absence ne prouve pas l'absence de trafic ni, à elle seule, une erreur DNS.

Lire un rapport RUA

Examinez source, SPF, DKIM, alignement et disposition. Une authentification valide doit être alignée pour contribuer à DMARC ; elle ne démontre pas à elle seule que le message soit sûr ou légitime.

Une séquence utile :

1. Examiner IP et DNS inverse, puis comparer aux prestataires ; le PTR ne prouve ni identité ni légitimité.
2. Évaluer volume et importance : une source avec 2 messages peut être critique, même si une autre en envoie 20,000.
3. Contrôler authentification et alignement SPF/DKIM. Un résultat valide non aligné peut ne pas servir à DMARC.
4. Examiner la disposition : none ne prouve ni remise ni surveillance ; quarantine ne désigne pas un dossier fixe ; reject ne garantit pas le blocage.
5. Rechercher si la source est connue, mal configurée, intermédiaire ou abusive.

Google demande SPF ou DKIM pour les expéditeurs ordinaires vers Gmail personnel ; pour les expéditeurs en masse, les deux et DMARC avec l'alignement applicable sur le From: visible. RUA aide à repérer les problèmes observés, sans garantir la boîte de réception.

Trois situations à examiner

Les rapports peuvent révéler expéditeurs légitimes non authentifiés, transferts et usurpations possibles, mais aussi relais partagés ou autres routes. Enquêtez avant de classer ou bloquer.

1. Expéditeur légitime mal configuré

Un service peut utiliser votre domaine sans SPF ou DKIM valides et alignés. Un seul résultat valide et aligné suffit à DMARC. Corrigez l'expéditeur et testez avant de changer la politique.

Dans TrekMail, suivez le chemin d'envoi réel. Avec un service externe, consultez Votre propre SMTP. Avec l'envoi inclus dans l'offre, consultez Managed TrekMail SMTP et vérifiez signature et alignement disponibles.

2. SPF échoue après transfert

Cela peut arriver parce que le serveur de transfert se connecte. Ce n'est pas une preuve de message malveillant. Si DKIM conserve les données signées selon sa canonicalisation, réussit et est aligné, DMARC réussit. Vérifiez la route plutôt que d'ignorer automatiquement tous les échecs SPF.

Consultez le transfert de messages et transférer la messagerie d'un domaine vers Gmail. Distinguer l'échec SPF du résultat DMARC évite des changements inutiles.

3. Source inconnue ou usurpation possible

Une IP ou un prestataire inconnu demande une enquête : service oublié, relais partagé ou transfert sont possibles. Ne l'autorisez pas dans SPF et ne le bloquez pas sans l'identifier. Évaluez les restrictions après vérification des sources légitimes.

Utiliser un service tiers pour RUA ?

Il peut faciliter l'analyse, mais vous devez comprendre sa configuration DNS et son traitement des données. Les destinations externes demandent l'autorisation correspondante pour être acceptées par les générateurs participants.

Selon la RFC 7489, lorsque la destination rua est extérieure au domaine organisationnel, le domaine recevant les rapports doit publier l'autorisation sous un nom tel que :

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

Sans cette confirmation, certains générateurs ignorent le destinataire externe. Suivez les instructions exactes de l'analyseur et vérifiez l'autorisation dans le DNS de destination.

Quand passer de p=none à quarantine ou reject ?

Utilisez les données avec inventaire et tests. Enquêtez sur les échecs avant les restrictions ; des rapports favorables ne prouvent pas la couverture de tous les flux légitimes.

Une démarche indicative :

1. Publier RUA avec p=none.
2. Observer les rapports pendant 1 à 2 semaines comme repère initial, puis prolonger pour les flux rares.
3. Corriger l'authentification et l'alignement de chaque expéditeur pour qu'au moins SPF ou DKIM réussisse avec alignement.
4. Envisager p=quarantine après résolution des échecs légitimes et analyse des inconnus.
5. Envisager p=reject après avoir testé aussi les processus critiques et transferts.

Sans observation et tests, un client pourrait signaler un expéditeur oublié avant vos rapports. Préparez la réponse aux incidents pendant la transition.

Exploitation dispersée ou parcours coordonné

Examiner le XML séparément pour chaque domaine demande de la coordination. Un DNS cohérent et un panneau de domaines, boîtes, migration et envoi peuvent faciliter les corrections selon les fonctions disponibles.

TrekMail ne remplace pas un analyseur DMARC. Il peut coordonner domaines, boîtes IMAP, catch-all, transferts, migration IMAP et SMTP propre ou inclus selon l'offre. Vérifiez les fonctions nécessaires pour corriger les problèmes observés.

Les offres sont annoncées dès $3.50 par mois. Nano est proposé gratuitement sans carte. Les offres payantes peuvent inclure un essai de 14 jours avec carte requise ; confirmez les conditions actuelles.

Conclusion : RUA apporte une visibilité partielle

RUA crée un canal utile pour examiner authentification, transferts et usurpations possibles. Complétez ces retours avec d'autres preuves pour évaluer la préparation de votre domaine aux restrictions.

Avec un domaine, cinquante ou cinq cents, fondez les décisions sur des tests. Revoyez périodiquement les rapports, actualisez l'inventaire et corrigez les expéditeurs avant la politique.

Pour coordonner l'infrastructure, TrekMail propose hébergement multidomaine, stockage mutualisé, création de boîtes par invitation et migration IMAP selon l'offre. Consultez les conditions sur trekmail.net et choisissez selon vos besoins d'exploitation.