Déboguer les échecs DMARC : guide pratique

Résumé : La majorité des échecs DMARC sont dus à des problèmes d'alignement. SPF ou DKIM peuvent réussir, mais le domaine authentifié ne correspond pas à celui du champ From. Corrigez l'alignement en configurant les expéditeurs tiers pour utiliser votre domaine dans le Return-Path et la signature DKIM, validez la syntaxe DNS, et utilisez ARC pour la gestion du transfert. Commencez avec p=none, surveillez les rapports chaque semaine, et ne passez à l'application stricte qu'après avoir atteint un taux de réussite supérieur à 95 %.

Points clés à retenir

• Alignement ≠ authentification : SPF et DKIM peuvent réussir alors que DMARC échoue si le domaine authentifié ne correspond pas au domaine From
• Un seul alignement suffit : DMARC passe si SPF ou DKIM est aligné. Les deux ne sont pas nécessaires.
• Les expéditeurs tiers sont souvent responsables : Les plateformes marketing, CRM et outils de support envoient souvent avec leur propre domaine, rompant l'alignement
• Utilisez l'alignement relaxé (par défaut) sauf besoins de sécurité stricts. Celui-ci autorise l'alignement des sous-domaines avec le domaine parent.
• Démarrez avec p=none : Collectez des rapports pendant au moins deux semaines avant de passer en quarantaine ou rejet
• Atteignez plus de 95 % de réussite sur au moins un mois avant l'application du p=reject
• Analysez les rapports agrégés chaque semaine : Une baisse soudaine signale un changement
• ARC préserve l'authentification lors des transferts : Cela ne remplace pas SPF/DKIM mais aide lors du transfert de mails
• SPF a une limite de 10 requêtes DNS : La dépasser entraîne des échecs intermittents. Aplatissez les includes en IP si nécessaire.

Les échecs d'authentification DMARC bloquent des e-mails légitimes, portent atteinte à la réputation de l'expéditeur, et créent des failles de sécurité exploitées par des attaquants. Une seule entrée DNS mal alignée peut envoyer des centaines de messages critiques en spam. Lorsque SPF et DKIM réussissent mais que DMARC échoue, les équipes informatiques passent des heures à analyser des rapports XML, dépanner le DNS et coordonner avec les prestataires pour identifier la cause d'origine.

La bonne nouvelle : la plupart des échecs DMARC proviennent de quelques erreurs de configuration faciles à corriger. Problèmes d'alignement, erreurs de syntaxe DNS et soucis avec des expéditeurs tiers représentent la majorité des échecs. Savoir comment déboguer chaque type d'échec permet de transformer un vague « DMARC ne fonctionne pas » en actions concrètes et efficaces.

Les équipes sécurité gérant l'authentification mails ont besoin de méthodes systématiques de débogage qui repèrent rapidement les causes, qu'elles proviennent du DNS interne, de plateformes marketing tierces ou de la configuration du transfert de mails. Ce guide détaille les étapes pratiques pour un débogage efficace et une délivrabilité fiable.

• Qu’est-ce qu’un échec DMARC ?
• Corrections de l’alignement SPF et DKIM
• Lecture des rapports DMARC
• Correction des erreurs sur les enregistrements DNS
• Gestion du transfert et des expéditeurs tiers
• Mise en œuvre de ARC pour de meilleurs résultats
• Réduire les échecs DMARC : bonnes pratiques
• Suivi et amélioration continue
• FAQ sur le débogage des échecs DMARC

Les échecs DMARC surviennent lorsque les e-mails échouent à la vérification d'alignement, même si l’authentification SPF ou DKIM réussit individuellement. Le protocole DMARC exige que soit SPF, soit DKIM soit aligné avec le domaine du champ From. L’alignement signifie que le domaine authentifié correspond au domaine de l’expéditeur visible par l’utilisateur.

Scénario d’erreur d’alignement courant :

Des newsletters marketing arrivent en spam alors que SPF est validé pour mailserver.vendor.com et que DKIM est signé correctement. L’en-tête From affiche marketing@company.com, mais l’authentification se fait sur des domaines vendor.com — générant un échec d’alignement.

Correction : Configurez votre plateforme marketing pour utiliser company.com à la fois dans le Return-Path et dans le paramètre d= de la signature DKIM. Une fois l’alignement réalisé, DMARC est validé et la délivrabilité redevient normale.

Un e-mail envoyé par marketing@company.com et authentifié par mailserver.vendor.com échoue à DMARC car les domaines ne sont pas alignés. Le contrôle SPF peut être validé pour le domaine du fournisseur, mais DMARC exige l'alignement avec company.com.

Les échecs d’authentification apparaissent dans les rapports agrégés comme échecs d’alignement SPF, échecs d’alignement DKIM, ou les deux. Les serveurs de réception envoient ces rapports XML chaque jour à l'adresse renseignée dans votre enregistrement DMARC.

Les échecs d’alignement SPF proviennent d'un Return-Path associé à un autre domaine. Lorsque des e-mails sont envoyés par des services tiers, le Return-Path utilise souvent le domaine du fournisseur au lieu du vôtre. Le guide SPF et DKIM explique comment ces protocoles authentifient l'identité de l'expéditeur.

Les rapports agrégés DMARC arrivent sous forme de fichiers XML compressés joints à des mails quotidiens [4]. Chaque rapport regroupe les résultats d’authentification par source d’envoi et affiche les volumes validés ou non pour l’alignement SPF et DKIM.

L’adresse IP source identifie chaque système d’envoi. Recoupez les IPs avec vos serveurs de mails internes, plateformes marketing tierces et applications SaaS. Les IPs inconnues doivent être vérifiées pour déterminer si elles correspondent à un service légitime ou à un expéditeur non autorisé.

Voici à quoi ressemble une ligne dans un rapport agrégé :

<record>
  <row>
    <source_ip>192.0.2.10</source_ip>
    <count>438</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>company.com</header_from>
  </identifiers>
  <auth_results>
    <dkim><domain>company.com</domain><result>pass</result></dkim>
    <spf><domain>mail.vendor.com</domain><result>pass</result></spf>
  </auth_results>
</record>

Comment la lire : 438 messages proviennent d’une IP. DKIM a authentifié pour company.com et est aligné avec le champ From, donc DMARC passe grâce à DKIM. SPF a authentifié pour mail.vendor.com mais n’est pas aligné avec company.com ; le résultat SPF dans policy_evaluated affiche donc fail. Le message passe malgré tout DMARC car un seul mode doit être aligné. Mal lire cette ligne, voir un « fail » SPF et penser que tout le message a échoué est la plus commune des erreurs lors des premiers rapports DMARC.

Lorsque SPF et DKIM échouent, examinez chaque problème d’alignement. Un échec SPF pointe un souci Return-Path ; un échec DKIM indique un problème de signature ou d’enregistrement.

Priorisez le débogage : d’abord les échecs les plus fréquents, ensuite les IPs inconnues, puis les volumes faibles.

Base de la syntaxe DNS :

Les enregistrements SPF doivent commencer par v=spf1 et se terminer par -all ou ~all. L’attribut -all interdit les expéditeurs non autorisés, alors que ~all les autorise avec avertissement. Utilisez des outils de vérification DMARC pour valider la syntaxe avant publication.

Commandes de validation DNS :

• DMARC : dig _dmarc.votredomaine.com TXT
• SPF : dig votredomaine.com TXT
• DKIM : dig selector._domainkey.votredomaine.com TXT
• Propagation : nslookup -type=TXT _dmarc.votredomaine.com 8.8.8.8
• Vérification de syntaxe : redsift.com/tools/investigate

Astuce : la plupart des échecs SPF sont dus à la limite de requêtes ou à un mauvais sélecteur. Priorisez l’analyse sur ces points pour une résolution plus rapide.

Le transfert d’e-mails casse l’authentification SPF car les messages transférés viennent de serveurs intermédiaires non listés dans les enregistrements SPF. Quand user@company.com renvoie ses mails à personal@gmail.com, Gmail ne voit que l’IP du serveur intermédiaire et pas celle de l’expéditeur d’origine.

Comment le transfert casse l’authentification :

Avant transfert : IP d’envoi originale : 192.0.2.1 (autorisée SPF) → Return-Path : sender@company.com → From : sender@company.com → SPF OK ✓ → DMARC OK ✓

Après transfert via un mail perso : IP du serveur de transfert : 203.0.113.5 (NON en SPF) → Return-Path : sender@company.com (inchangé) → From : sender@company.com → SPF KO ✗ → DMARC KO ✗

SPF échoue car l’expéditeur enveloppe (Return-Path) référence toujours le domaine initial alors que l’IP a changé pour celle du serveur de transfert. Les signatures DKIM survivent parfois au transfert si le message est resté inchangé.

Configuration des expéditeurs tiers :

• Utilisez un sous-domaine dédié type news.votredomaine.com plutôt que votredomaine.com
• Publiez des SPF pour tous vos sous-domaines : rien n’est hérité du domaine parent
• Configurez un Return-Path personnalisé : préserve l’alignement SPF même si l’infra est gérée par le prestataire
• Mettez à jour lors des changements de prestataire : les fournisseurs ajoutent parfois des serveurs sans notification

Authenticated Received Chain (ARC) préserve les résultats d’authentification lors des transferts de mails et des modifications par des listes de diffusion. Quand un message passe par des intermédiaires, ARC crée une chaîne d’authentification que les serveurs destinataires peuvent vérifier [1].

Chaque intermédiaire ajoute ses propres en-têtes ARC, construisant ainsi une chaîne d’authentification vérifiable.

Options de mise en œuvre :

• Google Workspace / Microsoft 365 – En-têtes ARC automatiques (aucune configuration requise)
• Postfix / Sendmail – Hébergement autonome via les modules OpenARC
• OnDMARC – Plateforme commerciale avec validation ARC

Important : ARC ne remplace pas SPF ou DKIM. Il les complète en préservant les résultats de l’authentification lorsque le transfert d’e-mail romprait autrement l’alignement DMARC. Les serveurs destinataires qui prennent en charge ARC peuvent valider la chaîne et faire confiance aux messages qui ont initialement passé l’authentification.

Documentez toutes les sources d’envoi autorisées avant de mettre en place des politiques DMARC. Renseignez-vous auprès des collaborateurs sur les outils d’envoi d’e-mails qu’ils utilisent. Les sources shadow IT courantes incluent les plateformes support (Zendesk), les outils marketing (HubSpot, Mailchimp), les CRM (SalesForce) et les plateformes d’enquête.

Auto-évaluation : votre configuration DMARC est-elle à risque ?

1. Exécution de p=quarantine/p=reject sans au moins 2 semaines en p=none
2. Taux de réussite de l’authentification inférieur à 95 % pour les expéditeurs légitimes
3. Services tiers qui envoient sans configuration SPF/DKIM
4. Pas de processus hebdomadaire de révision des rapports agrégés
5. Enregistrements DNS non audités depuis plus de 6 mois
6. Les membres de l’équipe peuvent ajouter des outils d’e-mail sans l’approbation de l’informatique

Si vous avez coché 3 points ou plus : corrigez ces failles avant de passer à des politiques d’application strictes.

Commencez par p=none et collectez les rapports pendant deux semaines. Analysez-les pour identifier toutes les sources d’envois et l’état de l’authentification. Passez ensuite à p=quarantine à 25 % à l’aide de l’attribut pct=, puis augmentez progressivement jusqu’à pct=100 avant d’appliquer p=reject.

Le guide d’application DMARC détaille les étapes de progression des politiques. Passez à p=reject uniquement après avoir atteint un taux de réussite de l’authentification supérieur à 95 % pendant au moins un mois.

DMARC nécessite une gestion continue, et non une simple configuration ponctuelle. Les fournisseurs tiers changent leur infrastructure d’envoi, de nouvelles applications envoient des e-mails sans approbation informatique, et les enregistrements DNS peuvent expirer lors du renouvellement de domaines.

Suivez le taux de réussite de l’authentification par source d’envoi. Si une plateforme marketing passe soudainement de 99 % à 85 %, cela nécessite une enquête immédiate.

Les rapports agrégés révèlent les tentatives de spoofing via des IP non autorisées. Les rapports médico-légaux (ruf=) fournissent des exemples de messages pour le débogage mais contiennent le contenu des e-mails—à utiliser temporairement seulement lors du débogage actif.

OnDMARC envoie des alertes en temps réel lors d’une baisse du taux d’authentification, identifie automatiquement les nouvelles sources d’envoi, et suit la conformité des politiques sur plusieurs domaines.

[1] Wikipedia contributors. « Authenticated Received Chain. » Wikipedia, The Free Encyclopedia. https://en.wikipedia.org/wiki/Authenticated_Received_Chain

[2] InfraForge. « Why DMARC Fails When SPF and DKIM Pass. » InfraForge AI Blog. https://www.infraforge.ai/blog/why-dmarc-fails-when-spf-and-dkim-pass

[3] Kitterman, S. « RFC 7208 - Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1. » Internet Engineering Task Force (IETF). Avril 2014. https://datatracker.ietf.org/doc/html/rfc7208

[4] Kucherawy, M. et Zwicky, E. « RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC). » Internet Engineering Task Force (IETF). Mars 2015. https://datatracker.ietf.org/doc/html/rfc7489