Les rapports DMARC montrent une partie du trafic observé par les destinataires participants : sources, authentification, alignement et traitement. Ils aident à rechercher usurpations et erreurs de prestataires, et à évaluer une politique restrictive, sans garantir à eux seuls qu'elle soit sûre.
Publier un enregistrement et diriger rua= vers une boîte ne suffit pas. Sans analyse du XML, les problèmes restent inexpliqués. Revoyez les bases avec la messagerie professionnelle pour petites entreprises et la messagerie avec son domaine. Comparez ensuite les rapports à votre inventaire : ils ne couvrent pas nécessairement tous les expéditeurs ni tout le trafic.
Collectez les rapports, identifiez les systèmes et corrigez l'alignement. Examinez les transferts : si DKIM réussit avec alignement, DMARC peut passer, mais cela ne dispense pas de vérifier la route. Durcissez la politique avec des tests, pas seulement un taux favorable.
Que sont les rapports DMARC ?
Les destinataires participants envoient des retours après avoir évalué des messages déclarant votre domaine comme expéditeur. Authentification, alignement, IP source et décisions sont utiles pour la sécurité et la délivrabilité, avec une couverture partielle.
Deux catégories principales existent.
Les rapports agrégés sont généralement demandés avec rua et arrivent en XML. Ils regroupent le trafic par destinataire, IP, résultats et disposition. Ils aident à rechercher si Google Workspace, Microsoft 365, SendGrid, Mailchimp, une application ou un autre serveur envoie avec votre domaine, sans identifier automatiquement le responsable de chaque IP.
Les rapports d'échec, demandés avec ruf, peuvent détailler des messages selon les déclencheurs configurés et l'implémentation, pas nécessairement uniquement des échecs DMARC. Le support est limité et la confidentialité restreint leur contenu. Utilisez-les comme complément, pas comme seule base.
Les rapports aident à répondre :
- Quelles sources observées envoient avec mon domaine ?
- SPF ou DKIM réussit-il avec alignement ?
- Quel trafic observé est mis en quarantaine ou rejeté ?
- Que risquent d'affecter
p=quarantineoup=reject?
Comment fonctionnent les rapports DMARC ?
Vous publiez un TXT sous _dmarc.yourdomain.com avec la politique et les destinations des rapports. Les destinataires participants peuvent envoyer leurs données. Une destination externe peut demander une autorisation DNS du domaine recevant les rapports : vérifiez-la.
Cet exemple utilise la surveillance avec un alignement strict facultatif :
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s; pct=100"Il demande la surveillance et des rapports agrégés à dmarc@example.com. Les réglages adkim=s et aspf=s exigent une correspondance exacte des domaines. Facultatifs, ils peuvent affecter des expéditeurs fonctionnant avec l'alignement souple entre sous-domaines du même domaine organisationnel ; ce n'est pas un choix universel.
Champs importants :
v=DMARC1: version obligatoire.p=: traitement demandé pour les échecs DMARC.rua=: destination des rapports agrégés.ruf=: destination des rapports d'échec.pct=: pourcentage demandé d'application aux messages en échec, pas uniformément respecté.adkimetaspf: modes d'alignement DKIM et SPF.
La RFC 7489 définit le format et la logique. Les rapports arrivent donc souvent sous forme de XML compressé, pas comme un tableau directement lisible.
Contenu des rapports agrégés
Ils résument le trafic observé par organisation, IP, volume, authentification et disposition. Distinguez les résultats SPF et DKIM bruts des résultats évalués pour la politique, qui intègrent l'alignement.
On y trouve généralement :
- Le destinataire informant, comme Google ou Microsoft.
- La période couverte.
- L'IP source.
- Le nombre de messages observés.
- Le résultat SPF.
- Le résultat DKIM.
- L'alignement SPF sur le From visible.
- L'alignement DKIM sur le From visible.
- La disposition DMARC : none, quarantine ou reject.
Un échec SPF ne révèle pas toujours une mauvaise configuration : le transfert change l'IP. Si DKIM conserve les données signées, réussit et est aligné, DMARC peut passer.
Destinataire : gmail.com
IP source : 198.51.100.24
Nombre : 842
From de l'en-tête : example.com
SPF : fail
DKIM : pass
DMARC : pass
Disposition : none
Ce résultat est compatible avec un transfert préservant DKIM. Vérifiez route et alignement ; une authentification valide ne prouve pas que le contenu soit sûr ou légitime.
Destinataire : outlook.com
IP source : 203.0.113.77
Nombre : 314
From de l'en-tête : example.com
SPF : fail
DKIM : fail
DMARC : fail
Disposition : quarantine
Enquêtez : expéditeur légitime mal configuré, nouveau prestataire, modification par un intermédiaire ou usurpation sont possibles. Le rapport ne permet pas de choisir automatiquement la cause.
Rapports agrégés ou rapports d'échec
Les agrégés donnent une vision large mais partielle des sources et destinataires participants. Les rapports d'échec détaillent certains messages lorsqu'ils sont disponibles. Aucun ne remplace inventaire, tests et vérification des flux critiques rares.
| Type | Demande | Données | Usage principal | Situation en 2025-2026 |
|---|---|---|---|---|
| Agrégé | rua=mailto:... | Résumés XML, souvent quotidiens, par source, authentification et disposition | Inventaire observé, alignement et évaluation de politiques | La base de données courante de nombreuses équipes |
| Échec / forensique | ruf=mailto:... | Détails de messages, souvent partiels ou expurgés | Analyser des échecs ou abus précis | Support irrégulier ; beaucoup de grands destinataires en envoient peu ou aucun |
Un prestataire d'analyse devrait expliquer cette différence et vous permettre d'agir sur les résultats, pas seulement afficher des graphiques.
Lire les rapports efficacement
Commencez par les sources à fort volume, rapprochez-les des systèmes connus et corrigez les échecs légitimes. Ne négligez pas les petits volumes s'ils correspondent à des processus critiques ou rares.
Procédure pratique :
- Examiner les sources aux volumes observés les plus élevés.
- Identifier le système : Google Workspace, Microsoft 365, marketing, application, support ou source inconnue.
- Vérifier que SPF ou DKIM réussit avec alignement sur le From visible.
- Corriger les échecs légitimes avant de modifier la politique.
- Enquêter sur les sources inconnues avant de les qualifier d'abus : transferts et relais partagés sont possibles.
Le volume aide à prioriser, mais une facture occasionnelle ou un message de récupération peut être essentiel. Tenez compte de l'importance de chaque flux.
| Résultat observé | Explication possible | Action |
|---|---|---|
| SPF pass, DKIM pass, DMARC pass | Authentification valide et alignée | Documenter la source ; cela ne prouve pas un contenu sûr |
| SPF fail, DKIM pass, DMARC pass | Transfert ou différence de route SPF | Vérifier DKIM aligné et sa conservation |
| SPF pass, DKIM fail, DMARC pass | SPF aligné permet de passer malgré DKIM | Rechercher et corriger le problème DKIM |
| SPF fail, DKIM fail, DMARC fail | Abus, configuration ou modification du parcours | Examiner origine et message |
| IP inconnue avec du volume | Service non inventorié, relais, transfert ou abus | Identifier avant d'envisager un blocage |
Les corrections peuvent consister à :
- Ajouter l'autorisation SPF adéquate d'un expéditeur légitime.
- Activer et vérifier DKIM chez le prestataire.
- Configurer un return-path personnalisé pour faciliter l'alignement SPF.
- Utiliser un sous-domaine pour séparer un service si nécessaire.
- Revoir les transferts et préserver les signatures sans dépendre uniquement de SPF.
Ces requêtes aident à vérifier la publication :
dig TXT _dmarc.example.com +short
dig TXT example.com +short
dig TXT selector1._domainkey.example.com +shortEn cas d'erreurs DNS, consultez les enregistrements DNS requis et le guide des messages classés comme indésirables de TrekMail, sans attribuer tous les problèmes au XML.
Problèmes que les rapports peuvent révéler
Les rapports aident à détecter authentification incomplète, défaut d'alignement, modifications de transferts et politiques sans suivi. Comparez toujours à la configuration réelle.
Un nouveau service peut envoyer avec votre domaine sans SPF ou DKIM correctement configuré. Une IP inconnue est une piste, pas une preuve d'usurpation.
SPF peut aussi réussir pour le domaine d'enveloppe sans être aligné sur From. Sans DKIM valide et aligné, DMARC échoue. Cela arrive avec marketing ou support sans domaine de retour personnalisé.
Dépendre seulement de SPF complique les transferts. Si DKIM manque ou devient invalide, l'authentification alignée peut disparaître. Consultez la configuration et réparation du transfert pour les routes indirectes.
Publier p=none et accumuler les rapports sans les lire ne corrige rien et ne demande pas de blocage.
Passer trop tôt à p=reject peut toucher des messages légitimes. Vérifiez expéditeurs habituels et exceptionnels avant les restrictions.
Le rôle de TrekMail
Les rapports sont utiles si vous pouvez appliquer les corrections. TrekMail peut coordonner domaines et contrôles DNS selon l'offre, mais les services externes restent à vérifier.
Un environnement dispersé demande de gérer plusieurs hébergeurs, SMTP séparés et rapports dans une boîte partagée, tout en maintenant l'inventaire des nouveaux expéditeurs.
Un parcours coordonné peut réunir hébergement multidomaine, configuration SPF/DKIM/DMARC, contrôles DNS, SMTP propre ou géré, boîtes, transferts et migration selon les fonctions disponibles. L'hébergement de messagerie multidomaine décrit ce modèle.
TrekMail propose domaines personnalisés, boîtes IMAP, catch-all, transferts et migration IMAP compatible selon l'offre, avec API dans les offres concernées. Pour Nano, consultez le SMTP personnalisé. Les offres payantes concernées peuvent utiliser le SMTP géré ; Starter est annoncé à partir de $3.50 par mois. Nano est proposé gratuitement sans carte, et les offres payantes peuvent inclure un essai de 14 jours avec carte requise. Vérifiez les conditions actuelles.
Les rapports ne corrigent rien automatiquement : ils donnent des pistes. Coordonner configuration et tests peut faciliter les interventions.
Quand passer de p=none à quarantine ou reject ?
Les rapports montrent l'authentification alignée du trafic observé, sans garantir que tous les expéditeurs soient prêts. Complétez l'inventaire et testez les processus critiques avant d'envisager quarantine et reject.
Ces enregistrements correspondent à des étapes alternatives : publiez uniquement celui qui convient, pas tous ensemble.
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=25"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100"Le pourcentage demande une couverture des messages en échec, pas uniformément appliquée. Examinez plusieurs cycles et les processus rares, confirmez l'authentification alignée et vérifiez la conservation de DKIM par les transferts si vous en dépendez.
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. Consultez la FAQ des consignes pour les expéditeurs Gmail.
Conclusion : intégrer les rapports à l'exploitation
Les rapports montrent des sources et résultats observés, utiles pour décider des investigations et corrections. Intégrez-les aux revues périodiques avec inventaire et tests, plutôt que les laisser dans une boîte ignorée.
Avec beaucoup de domaines et prestataires, coordonner les outils peut aider. Selon l'offre, TrekMail propose hébergement multidomaine, stockage mutualisé, migration IMAP, SMTP propre ou géré et configuration d'authentification. Examinez l'offre gratuite ou les tarifs TrekMail selon vos besoins, sans supposer qu'une plateforme garantit une politique sûre.
