Déboguer les échecs DMARC : un guide pratique

TL;DR : La plupart des échecs DMARC sont dus à des problèmes d'alignement. SPF ou DKIM peuvent réussir, mais le domaine authentifié ne correspond pas à l’en-tête From. Corrigez l’alignement en configurant les expéditeurs tiers pour qu’ils utilisent votre domaine dans le Return-Path et la signature DKIM, validez la syntaxe DNS, et utilisez ARC pour gérer le transfert. Commencez par p=none, surveillez les rapports chaque semaine, puis appliquez une politique stricte seulement après avoir atteint un taux de réussite supérieur à 95 %.

Points clés à retenir

• Alignement ≠ authentification : SPF et DKIM peuvent réussir tandis que DMARC échoue si le domaine authentifié ne correspond pas au domaine de l’en-tête From
• Un seul doit s’aligner : DMARC réussit si soit SPF, soit DKIM est aligné. Vous n'avez pas besoin des deux.
• Les expéditeurs tiers sont souvent responsables : Les plateformes marketing, CRM et outils de support envoient souvent avec leurs propres domaines, ce qui casse l’alignement
• Utilisez l’alignement relaxé (par défaut) sauf si vous avez des besoins de sécurité stricts. Il permet que les sous-domaines soient alignés avec les domaines parents.
• Commencez avec p=none : Collectez des rapports pendant au moins 2 semaines avant de passer à quarantine ou reject
• Atteignez 95 % de réussite pendant au moins un mois avant d’imposer p=reject
• Analysez les rapports agrégés chaque semaine : Une chute soudaine du taux de réussite indique un changement
• ARC préserve l’authentification lors des transferts : Il ne remplace pas SPF/DKIM mais aide lors des redirections d’e-mails
• SPF a une limite de 10 requêtes DNS : La dépasser provoque des échecs intermittents. Aplatissez les include en IP si besoin.

Les échecs d’authentification DMARC bloquent des e-mails légitimes, nuisent à la réputation de l’expéditeur et laissent des failles de sécurité exploitables. Un seul enregistrement DNS mal aligné peut faire atterrir des centaines de messages critiques en spam. Si SPF réussit et DKIM signe correctement, mais que DMARC échoue encore, les équipes IT doivent analyser des rapports XML, dépanner le DNS, et coordonner avec les fournisseurs pour trouver la cause.

La bonne nouvelle : la plupart des échecs DMARC sont dus à quelques problèmes de configuration faciles à corriger. Les désalignements, erreurs de syntaxe DNS et mauvaises configurations d’expéditeurs tiers expliquent la majorité des problèmes d’authentification. Savoir dépanner chaque type transforme les sujets « DMARC ne fonctionne pas » en actions concrètes.

Les équipes sécurité qui gèrent l’authentification mail doivent s’appuyer sur des méthodes systématiques pour isoler rapidement les problèmes, qu’ils proviennent des DNS internes, d’une plateforme marketing tierce, ou de la gestion des transferts d’e-mails. Ce guide couvre les étapes pratiques de débogage pour authentifier et livrer les e-mails de façon fiable.

• Qu’est-ce qu’un échec DMARC ?
• Corrections d'alignement SPF et DKIM
• Interpréter les rapports DMARC
• Corriger les erreurs d’enregistrements DNS
• Gérer le transfert et les expéditeurs tiers
• Implémenter ARC pour de meilleurs résultats
• Réduire les échecs DMARC : bonnes pratiques
• Surveillance et amélioration continues
• FAQ sur le débogage DMARC

Les échecs DMARC surviennent lorsque les e-mails ne passent pas les vérifications d’alignement, même si SPF ou DKIM réussit individuellement. DMARC exige que soit SPF, soit DKIM soit aligné avec le domaine dans l’en-tête From. L’alignement signifie que le domaine authentifié correspond au domaine visible par le destinataire.

Exemple courant de désalignement :

Des newsletters marketing arrivent en spam même si SPF réussit pour mailserver.vendor.com et que DKIM est valide. L’en-tête From affiche marketing@company.com, mais l’authentification marque vendor.com — provoquant un problème d’alignement.

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

Un email envoyé depuis marketing@company.com, authentifié par mailserver.vendor.com, échoue DMARC car les domaines ne sont pas alignés. Le contrôle SPF peut réussir pour le domaine du fournisseur, mais DMARC exige un alignement sur company.com.

Les échecs d’authentification apparaissent dans les rapports agrégés comme échec d’alignement SPF, échec d’alignement DKIM ou les deux. Les serveurs destinataires envoient ces rapports XML chaque jour à l’adresse définie dans votre enregistrement DMARC.

Les échecs SPF proviennent des différences entre le Return-Path et votre domaine. Lorsque les e-mails viennent de services tiers, le Return-Path utilise souvent le domaine du fournisseur, pas le vôtre. Le guide SPF et DKIM explique comment ces protocoles authentifient l’expéditeur.

Les rapports DMARC agrégés arrivent sous forme de fichiers XML compressés joints à des e-mails quotidiens [4]. Chaque rapport présente les résultats d’authentification par source d’envoi, avec le nombre de succès/échec pour l’alignement SPF et DKIM.

L’adresse IP source identifie chaque système d’envoi. Recoupez les IPs avec vos serveurs internes, plateformes marketing tierces, et applications SaaS connues. Les IPs inconnues nécessitent une enquête pour vérifier s’il s’agit de services légitimes ou d’expéditeurs non autorisés.

Quand SPF et DKIM échouent tous deux, analysez précisément chaque problème d’alignement. Un SPF en échec indique un souci de Return-Path ; un DKIM en échec évoque un problème de signature ou d’enregistrement absent.

Déboguez en priorité : d’abord les échecs à gros volume, puis les IPs inconnues, puis les problèmes à faible volume.

Points de base sur la syntaxe DNS :

Les enregistrements SPF commencent par v=spf1 et se terminent par -all ou ~all. Le paramètre -all bloque les non-autorisés, ~all autorise les soft fails. Utilisez les outils de vérification DMARC pour valider la syntaxe avant publication.

Commandes pour valider le 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 syntaxique : redsift.com/tools/investigate

Astuce : La plupart des échecs SPF sont dus à la limite de lookups ou un mauvais sélecteur. Dépannez ces axes en priorité pour aller plus vite.

Le transfert d’e-mails casse l’authentification SPF parce que les messages transférés viennent de serveurs intermédiaires absents des enregistrements SPF. Quand user@company.com transfère vers une adresse personnelle@gmail.com, Gmail voit l’IP du serveur de transfert, pas celle de l’expéditeur autorisé.

Comment le transfert fausse l’authentification :

Avant transfert : IP expéditeur original : 192.0.2.1 (autorisé dans SPF) → Return-Path : sender@company.com → From : sender@company.com → SPF OK ✓ → DMARC OK ✓

Après transfert par mail perso : IP serveur de transfert : 203.0.113.5 (PAS dans SPF) → Return-Path : sender@company.com (inchangé) → From : sender@company.com → SPF échoue ✗ → DMARC échoue ✗

SPF échoue car l’enveloppe Return-Path reste sur le domaine original, mais l’IP d’envoi a changé vers le serveur de transfert. La signature DKIM peut parfois survivre au transfert si le message n’est pas modifié.

Conseils de configuration pour les expéditeurs tiers :

• Utilisez des sous-domaines pour l’envoi – news.votredomaine.com au lieu de votredomaine.com
• Publiez des enregistrements SPF sur tous les sous-domaines – Les sous-domaines n’héritent pas du domaine parent
• Configurez des Return-Path personnalisés – Permet de garder l’alignement SPF tout en laissant l’infrastructure au fournisseur
• Mettez à jour lors des changements de fournisseurs – Les prestataires ajoutent des serveurs sans préavis

Authenticated Received Chain (ARC) préserve les résultats d’authentification lors du transfert d’e-mails ou de modifications par une liste de diffusion. Quand le message passe par des intermédiaires, ARC crée une chaîne de résultats qu’un serveur destinataire pourra vérifier [1].

Chaque intermédiaire ajoute ses propres en-têtes ARC, constituant 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 sur site via les modules OpenARC
• OnDMARC – Plateforme commerciale avec validation ARC

Important : ARC ne remplace pas SPF ni DKIM. Il les complète en conservant les résultats d’authentification là où le transfert altérerait autrement l’alignement DMARC. Les serveurs récepteurs compatibles ARC peuvent valider la chaîne et faire confiance aux messages qui avaient initialement réussi l’authentification.

Documentez toutes les sources d’envoi autorisées avant de mettre en place des politiques DMARC. Demandez aux employés quels outils d’envoi d’e-mails ils utilisent. Des sources shadow IT fréquentes incluent les plateformes de support (Zendesk), les outils marketing (HubSpot, Mailchimp), les CRM (SalesForce) et les plateformes de sondage.

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 à l’authentification inférieur à 95 % pour les expéditeurs légitimes
3. Services tiers envoyant sans configuration SPF/DKIM
4. Absence de revue hebdomadaire 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 emailing sans validation IT

Si vous avez coché 3 points ou plus : traitez ces lacunes avant d’appliquer des politiques restrictives.

Commencez par p=none et collectez les rapports pendant deux semaines. Analysez-les pour identifier toutes les sources d’envoi et leur statut d’authentification. Passez ensuite à p=quarantine à 25% avec l’attribut pct=, puis augmentez progressivement jusqu’à pct=100 avant d’aller vers p=reject.

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

DMARC requiert une gestion continue, pas une configuration ponctuelle. Les fournisseurs tiers modifient leur infrastructure, de nouvelles applications peuvent envoyer des e-mails sans validation IT, et les enregistrements DNS peuvent expirer lors du renouvellement de domaine.

Suivez les taux de réussite de l’authentification par source d’envoi. Une plateforme marketing passant soudainement d’un taux de réussite de 99 % à 85 % doit être immédiatement analysée.

Les rapports agrégés révèlent des tentatives d’usurpation via des IP non autorisées. Les rapports forensiques (ruf=) fournissent des exemples de messages en échec pour le débogage, mais contiennent le contenu des e-mails : à utiliser uniquement temporairement lors d’un débogage actif.

OnDMARC fournit des alertes temps réel lors d’une baisse des taux d’authentification, détecte 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