Pourquoi une ligne de votre rapport DMARC affiche-t-elle spf=fail alors que le domaine reste protégé et que le message est quand même arrivé dans la boîte de réception ? Pour chaque source d’envoi, un rapport DMARC agrégé liste le résultat SPF. Il ajoute le résultat DKIM et la décision réellement appliquée par le serveur receveur. Un SPF en échec associé à un DKIM aligné en réussite ne casse rien : la spécification DMARC valide dès que l’un des deux mécanismes s’aligne avec le domaine visible dans l’en-tête From.
C’est exactement le genre de ligne qui inquiète à tort quand les campagnes finissent en spam et que l’outil d’emailing affiche pourtant un taux de délivrabilité tout vert. Si les bases de l’authentification email (SPF, DKIM, DMARC) ne sont pas encore claires, le protocole DMARC expliqué pose le cadre avant d’aller plus loin. Ce guide reste concentré sur un seul point : lire un rapport agrégé champ par champ et distinguer une ligne normale d’une vraie alerte.
Où arrive le rapport et sous quel format
Le rapport agrégé est envoyé à l’adresse déclarée dans la balise rua= de l’enregistrement DNS _dmarc, généralement une fois par jour et par fournisseur receveur (Google, Microsoft, Yahoo). Le détail des balises DNS qui pilotent cet envoi est couvert dans l’article sur les balises DMARCbis à corriger avant la bascule 2026, cet article-ci part du principe que le DNS est déjà en place. Chaque message arrive en pièce jointe compressée, un fichier XML dans une archive .zip ou .gz. Il faut le décompresser avant lecture ou passer par un analyseur qui le fait automatiquement.
MailerCheck distingue en 2024 les rapports agrégés des rapports forensiques : les premiers résument l’activité d’authentification sur une période donnée, les seconds détaillent un échec précis et restent rarement implémentés par les fournisseurs de messagerie (MailerCheck, 2024). Rien de sensible n’y transite. Presque tout le monitoring DMARC repose donc sur l’agrégé. C’est aussi la politique DMARC que Gmail et Yahoo exigent depuis 2024 pour les domaines qui envoient plus de 5 000 messages par jour. L’agrégé reste le principal outil pour en vérifier l’application.
La structure du XML, champ par champ
Le fichier XML s’organise en trois blocs. report_metadata identifie l’expéditeur du rapport (org_name, email, période couverte). policy_published reprend la politique DMARC publiée par votre domaine au moment de l’analyse. Le bloc record contient une ou plusieurs lignes row, chacune correspondant à une combinaison unique de source et de résultats.
Pour interpréter une ligne sans se perdre, l’ordre de lecture compte.
- Identifier la source : source_ip indique l’adresse IP qui a réellement envoyé le message, à croiser avec un reverse DNS pour savoir s’il s’agit de votre ESP, d’un relais tiers ou d’une IP inconnue.
- Regarder le volume : count donne le nombre de messages associés à cette combinaison exacte sur toute la période du rapport.
- Lire la décision appliquée : disposition (none, quarantine ou reject) dans le bloc policy_evaluated, celle effectivement prise par le serveur receveur.
- Comparer dkim et spf dans policy_evaluated : ces deux valeurs indiquent le résultat d’alignement, distinct du résultat brut du protocole.
- Vérifier auth_results pour le résultat brut de chaque mécanisme et le domaine effectivement signataire ou déclaré.
Cette distinction entre alignement (policy_evaluated) et résultat brut (auth_results) est la source de la plupart des confusions. Un SPF techniquement valide sur le domaine d’enveloppe peut afficher fail dans policy_evaluated parce que ce domaine ne correspond pas au domaine visible dans l’en-tête From. C’est précisément le mécanisme qui explique le cas suivant.
Les 4 combinaisons DKIM x SPF et leur verdict DMARC
Un rapport agrégé fait apparaître 4 configurations récurrentes. Chacune raconte une histoire différente sur ce qui s’est passé entre votre serveur d’envoi et la boîte du destinataire.
| DKIM | SPF | Résultat DMARC | Cause la plus fréquente |
|---|---|---|---|
| Pass, aligné | Pass, aligné | Pass | Envoi direct depuis l’infrastructure déclarée dans le DNS |
| Pass, aligné | Fail | Pass, via DKIM | Forwarding, liste de diffusion, transfert de boîte mail |
| Fail | Pass, aligné | Pass, via SPF | Relais qui ne signe pas le message ou signature cassée en route |
| Fail | Fail | Fail | Usurpation du domaine ou source d’envoi mal déclarée dans le DNS |
Seule la 4e ligne réclame une correction immédiate. Les 3 premières relèvent d’un fonctionnement attendu de la spécification, chacune avec sa propre lecture.
SPF en échec, DKIM en réussite : faut-il s’inquiéter ?
Non, dans la majorité des cas. Le SPF vérifie l’adresse MAIL FROM, transmise via la commande du même nom dans le dialogue SMTP juste après l’échange EHLO initial, c’est-à-dire l’adresse d’enveloppe. Le DKIM signe le contenu du message avec une clé privée liée au domaine expéditeur, une signature qui voyage avec le message quel que soit le serveur qui le relaie ensuite. Quand un destinataire transfère un mail vers une autre boîte ou quand une liste de diffusion redistribue un message à ses abonnés, le serveur relais devient la nouvelle IP d’envoi. Le SPF, qui vérifie l’IP contre l’enregistrement du domaine d’origine, échoue mécaniquement. La signature DKIM, elle, reste intacte tant que le corps et les en-têtes signés ne sont pas modifiés en route.
Spamresource documente en novembre 2025 un rejet Microsoft qui illustre bien la mécanique, dans l’autre sens : un message avec DKIM pass et DMARC pass s’est fait bloquer parce que le SPF, lui, échouait.
550 5.7.515 Access denied, sending domain doesn’t meet the required authentication level. Spf= Fail, Dkim= Pass, DMARC= Pass
Le code de statut étendu 5.7.515 signale ici une exigence propre à Microsoft, une couche ajoutée au-dessus du résultat DMARC lui-même. Depuis mai 2025, Microsoft impose aux expéditeurs en volume de passer simultanément les 3 mécanismes (SPF, DKIM, DMARC), même quand la spécification DMARC elle-même se contente d’un seul alignement réussi (spamresource.com, 2025). Le SPF fail identifié dans ce cas précis venait, selon le même article, d’un transfert vers une boîte hébergée hors des serveurs Microsoft. C’est un point à connaître avant d’expliquer à un CMO que le taux d’ouverture baisse : DMARC peut afficher pass dans votre rapport tout en laissant certains messages bloqués par une règle propre au fournisseur receveur.
Deux choses distinguent ce cas d’un vrai problème de configuration à corriger. D’abord le volume : quelques lignes isolées avec un count faible, réparties sur des IP variées, correspondent plutôt à du forwarding individuel qu’à une campagne entière. Ensuite la source : un reverse DNS sur ces source_ip pointe généralement vers un fournisseur de messagerie grand public ou un serveur de liste de diffusion, jamais vers votre propre infrastructure d’envoi. Un SPF fail répété sur vos propres IP d’envoi, hors tout forwarding identifiable, pointe vers une autre cause : la limite des 10 lookups DNS de l’enregistrement SPF, à vérifier avant de conclure trop vite à un simple transfert.
Pièges courants en lisant un rapport agrégé
Premier piège : confondre le résultat brut d’auth_results avec le résultat d’alignement de policy_evaluated. Un SPF peut réussir techniquement sur le domaine d’enveloppe tout en échouant en alignement parce que ce domaine diffère du From visible, un scénario fréquent chez les expéditeurs qui passent par un IP pool mutualisé chez un fournisseur tiers.
Deuxième piège : traiter un seul rapport comme une preuve définitive. Les grands fournisseurs (Google, Microsoft, Yahoo) envoient des rapports quotidiens. Un incident ponctuel peut apparaître sur un seul jour et disparaître le lendemain. Vérifiez count et disposition sur au moins une semaine avant de conclure.
Troisième piège : ignorer le champ org_name du bloc report_metadata. Il identifie qui a produit le rapport, utile pour repérer un fournisseur secondaire qui applique sa propre politique de filtrage en plus de la vôtre, indépendamment des feedback loops FAI auxquels vous êtes déjà abonné de votre côté.
Ce que ça change pour votre délivrabilité
Un rapport propre, avec un disposition à none ou quarantine cohérent sur les lignes non-tierces, confirme une sender reputation stable côté authentification. C’est un signal différent du monitoring post-envoi habituel : le taux d’ouverture ou le bounce rate montre l’effet côté destinataire, le rapport DMARC montre la cause côté serveur receveur, avant même que le message atteigne une boîte. Les deux se complètent sans se remplacer. Postmaster Gmail et l’équivalent Microsoft, le SNDS (Smart Network Data Services), donnent une vue similaire côté réputation d’IP, à croiser avec les mêmes source_ip repérées dans le rapport.
Une fois l’authentification confirmée propre sur plusieurs jours, la variable suivante qui pèse sur la réputation reste la propreté de la liste envoyée. Un taux de hard bounce élevé abîme la sender reputation aussi sûrement qu’un SPF mal aligné et aucune ligne de rapport DMARC ne le révèle. Passer un échantillon de la prochaine liste par une vérification avant l’envoi permet de savoir si le frein vient de l’authentification ou de la list hygiene.
Ce que le rapport agrégé ne couvre pas
Un rapport DMARC ne dit rien du contenu du message, du taux de plainte réel côté boîte de réception, ni des domaines proches (typosquattés) qui n’ont jamais publié d’enregistrement DMARC et échappent donc totalement à ce mécanisme de reporting. Passer en p=reject bloque l’usurpation directe de votre domaine, un prérequis technique pour activer BIMI ensuite. Cela reste sans effet sur un domaine visuellement proche enregistré par un tiers. Les 5 choses que DMARC ne peut pas faire détaillent ces angles morts au-delà du reporting.
Sauvegardez vos rapports sur plusieurs semaines avant d’ajuster la politique. C’est la seule façon de distinguer un signal réel d’un bruit passager. Un rapport DMARC agrégé raconte le trajet réel d’un message, ligne après ligne, jusqu’à la boîte de réception.
