« Ne passe pas la vérification DMARC et a une politique DMARC de rejet » : ce que cela signifie et comment y remédier
par
Dernière mise à jour : 7 Temps de lecture : 7 min
Points clés à retenir
- Les erreurs de rejet DMARC se produisent lorsque SPF DKIM échoue à l'alignement du domaine avec l'adresse « De ».
- Une politique p=reject demande aux serveurs destinataires de bloquer complètement les e-mails non autorisés.
- Il ne suffit pas SPF passer SPF ; SPF le DKIM doivent correspondre à votre domaine d'expéditeur visible.
- Le transfert d'e-mails perturbe souvent SPF, ce qui rend l'alignement DKIM essentiel pour une livraison stable.
- La suppression de p=reject affaiblit la sécurité du domaine et augmente le risque d'usurpation d'identité.
Examinez les rapports DMARC RUA chaque semaine afin d'identifier les services mal configurés et les expéditeurs non autorisés.
Une erreur « Ne passe pas la vérification DMARC et a une politique DMARC de rejet » signifie que votre e-mail a échoué à l'authentification DMARC et que le serveur destinataire a bloqué la livraison. Ce problème se produit lorsque SPF DKIM ne parvient pas à s'aligner avec votre domaine « De » et que votre politique DMARC est définie sur p=reject. Corrigez les erreurs de rejet DMARC en corrigeant SPF , en activant la signature DKIM et en garantissant un alignement strict du domaine afin de restaurer la délivrabilité des e-mails et d'empêcher l'usurpation d'identité.
Que signifie réellement cette erreur DMARC ?
Lorsqu'un serveur destinataire traite votre e-mail, il effectue plusieurs vérifications afin de s'assurer que l'expéditeur est autorisé. Si ces vérifications échouent, le serveur consulte l'enregistrement DMARC de votre domaine pour obtenir des instructions sur la marche à suivre.
Explication de « Ne passe pas la vérification DMARC »
Une erreur DMARC se produit lorsqu'un e-mail ne respecte pas les critères DMARC. Il est faux de croire que le simple fait de passer SPF DKIM suffit. DMARC exige que le domaine indiqué dans l'en-tête « De », qui est celui que voit l'utilisateur, corresponde au domaine validé par SPF DKIM. Si les signatures techniques ne correspondent pas à l'adresse visible de l'expéditeur, DMARC échoue.
Ce qu'implique la « politique DMARC de rejet »
La balise p=reject est la politique DMARC la plus stricte. Elle indique au serveur destinataire : « Si cet e-mail ne passe pas la vérification, ne le distribuez pas. Supprimez-le entièrement. »
Comment fonctionne la vérification DMARC (aperçu rapide)
Pour être conforme à DMARC, un e-mail doit satisfaire aux critères suivants :
- Le passe technique : SPF DKIM doit être valide.
- L'alignement : le domaine utilisé dans SPF DKIM doit correspondre au domaine dans l'adresse « De ».
L'alignement est plus important qu'une simple validation. Par exemple, si vous envoyez un e-mail à partir d'un sous-domaine, mais que votre SPF n'autorise que le domaine de votre hébergeur web, la SPF pourrait être « validée » pour l'hébergeur, mais DMARC serait « rejeté » car les domaines ne sont pas alignés.
Pourquoi les e-mails échouent au test DMARC et sont rejetés
1. Échecs d'authentification
- SPF ou envoi non autorisé IP : considérez SPF une liste d'invités VIP pour votre domaine. Si vous commencez à utiliser un nouvel outil, tel qu'un CRM ou une plateforme de marketing par e-mail, mais que vous oubliez de l'ajouter à cette liste (votre SPF ), le serveur destinataire voit une IP non répertoriée tenter d'accéder au système et lui ferme la porte au nez.
- DKIM manquant ou défectueux : DKIM est en quelque sorte un sceau numérique. Si votre serveur ne « signe » pas le courrier électronique ou si la « clé » que vous avez saisie dans vos paramètres DNS est obsolète ou défectueuse, le destinataire ne peut pas vérifier que le courrier électronique provient bien de vous. Sans sceau, pas d'accès.
2. Questions d'alignement
- Incohérence du domaine DKIM : cela revient un peu à présenter une pièce d'identité dont le nom ne correspond pas à la personne qui se trouve devant vous. Si votre e-mail indique qu'il provient de votredomaine.com, mais que la signature DKIM est signée par un service aléatoire.com, DMARC va se méfier. Tout doit renvoyer à la même base.
- SPF rompu par le transfert : il s'agit du problème classique de l'« intermédiaire ». Lorsqu'un e-mail est transféré, le « Return-Path » (chemin de retour) est souvent remplacé par les informations du transféreur, ce qui rompt complètement SPF. C'est très courant, et c'est exactement pour cette raison que le DKIM est indispensable : le DKIM reste attaché à l'e-mail même lorsqu'il est transféré, tandis que SPF est SPF rompu.
Pourquoi la politique p=reject rend cette erreur critique
Les politiques DMARC fonctionnent selon une échelle d'application :
- p=none : Mode surveillance. Aucun courrier n'est bloqué.
- quarantine: les courriers suspects sont placés dans le dossier Courrier indésirable.
- p=reject : tolérance zéro. Les courriers non autorisés sont supprimés.
Lorsque vous êtes en mode p=reject, vous n'avez aucune marge d'erreur. Si vos expéditeurs tiers ne sont pas parfaitement configurés, vos communications professionnelles légitimes seront traitées comme des attaques de phishing et bloquées.
Le facteur caché : les politiques relatives aux sous-domaines (sp=)
Un détail qui prend souvent les administrateurs au dépourvu est la manière dont DMARC gère les sous-domaines (par exemple, marketing.votredomaine.com). Par défaut, si vous définissez votre domaine principal sur p=reject, chaque sous-domaine hérite automatiquement de cette commande « Block ».
Si vous disposez d'un outil plus ancien qui envoie des messages à partir d'un sous-domaine qui n'est pas encore entièrement configuré, celui-ci sera immédiatement désactivé. Pour gérer cela, vous pouvez utiliser la balise sp dans votre enregistrement DMARC :
- sp=none : maintient vos sous-domaines en « mode surveillance » même si votre domaine principal est en p=reject.
- sp=reject : indique explicitement aux serveurs de bloquer les courriers non autorisés provenant de tout sous-domaine.
Conseil de pro : si vous n'êtes pas sûr à 100 % de tous les services utilisant vos sous-domaines, commencez par p=reject; sp=none; afin de protéger votre marque principale pendant que vous auditez vos sous-marques.
Situations courantes dans lesquelles cette erreur apparaît
Gmail et Google Workspace
Google a récemment renforcé ses exigences envers les expéditeurs de messages en masse. Vous pouvez recevoir un message d'erreur indiquant : « Message rejeté car il ne respecte pas la politique DMARC de Google. »
Microsoft 365 et Outlook
Microsoft utilise fréquemment la « protection avancée contre les menaces ». Si DMARC échoue et que la politique est rejetée, les serveurs Outlook génèrent souvent un NDR 5.7.1, qui signifie « rapport de non-livraison ».
Outils tiers
De nombreuses entreprises oublient d'autoriser leurs plateformes CRM ou RH. Comme ces outils envoient des e-mails « au nom » de votre domaine, ils sont les principaux responsables des rejets DMARC.
Comment corriger « Ne passe pas la vérification DMARC »
Suivez ces étapes pour résoudre l'erreur :
- Identifiez la source : commencez par vérifier la note « retour à l'expéditeur ». Consultez le message de rebond pour trouver l'adresse IP ou le service spécifique qui a tenté d'envoyer le courrier. C'est généralement la preuve irréfutable qui vous indique exactement qui a été bloqué à l'entrée.
- Vérifiez SPF : considérez votre SPF comme la liste des « expéditeurs approuvés » de votre domaine. Vous devez vous assurer que le service que vous utilisez y figure bien. Si ce n'est pas le cas, vous devrez ajouter leur déclaration « include » à votre enregistrement DNS afin que le serveur destinataire sache qu'il a votre autorisation pour parler en votre nom.
- Corrigez la signature DKIM : vous devez vous assurer que le service « signe » réellement vos e-mails avec une clé DKIM qui renvoie à votre domaine. Si la signature numérique est manquante ou appartient à un domaine totalement différent, le destinataire la considérera comme une fausse identité.
- Assurez-vous que le domaine correspond : tout doit correspondre. Vérifiez que le domaine indiqué dans votre adresse « De » est le même que celui utilisé pour vos SPF DKIM. Si votre e-mail indique qu'il provient de company.com, mais que votre SPF random-app.net, le calcul ne sera pas valide pour DMARC.
- Consultez les rapports DMARC : utilisez un outil de surveillance DMARC pour consulter les rapports « RUA ». Ceux-ci vous indiqueront précisément quels services présentent des défaillances et pourquoi.
- Testez avant de renvoyer : utilisez un analyseur d'en-tête en ligne pour envoyer un e-mail test et vérifier le statut « DMARC Pass ».
Solutions temporaires ou solutions adéquates
Pourquoi supprimer p=reject est risqué
Vous pourriez être tenté de revenir à la politique p=none afin de « corriger » la livraison. Bien que cela mette fin aux rebonds, cela expose votre domaine à des tentatives d'usurpation par des pirates informatiques. Cela procure un faux sentiment de sécurité tout en compromettant la réputation de votre marque.
Des moyens plus sûrs pour récupérer
Au lieu de réduire la sécurité, utilisez des outils de surveillance pour identifier le trafic légitime défaillant. Vous pouvez également utiliser une balise « pourcentage » (par exemple, p=reject; pct=50) pour appliquer progressivement la politique tout en vérifiant que toutes vos sources d'envoi sont correctement alignées.
Comment PowerDMARC aide à prévenir les erreurs de rejet DMARC
Alors qu'une politique de « rejet » brute est un instrument peu précis, PowerDMARC fournit les outils de précision nécessaires pour garantir qu'elle ne touche que les mauvais acteurs.
1. Visibilité totale et renseignements sur les menaces IA : lire manuellement des rapports XML revient à essayer de déchiffrer le code Matrix. L'analyseur de rapports DMARC de PowerDMARC convertit ces fichiers complexes en un tableau de bord lisible par l'utilisateur.
2. Cartographie des menaces basée sur l'IA : notre système de renseignements sur les menaces alimenté par l'IA identifie l'emplacement géographique et la réputation des adresses IP non autorisées, ce qui vous aidera à faire la distinction entre un outil interne mal configuré et une tentative d'usurpation malveillante.
3. Gestion simplifiée des enregistrements (services hébergés) : la cause la plus courante d'échec DMARC est le « désalignement », c'est-à-dire lorsque vos enregistrements SPF DKIM ne correspondent pas à votre domaine. PowerDMARC propose des services hébergés (y compris DMARC hébergé) qui vous permettent de mettre à jour ces enregistrements directement depuis notre tableau de bord sans jamais avoir à vous connecter à votre fournisseur DNS.
Meilleures pratiques pour éviter les erreurs de rejet de la politique DMARC
Le maintien d'une politique de « rejet » nécessite une hygiène permanente. Pour vous assurer que vos e-mails légitimes ne soient pas bloqués par votre propre filet de sécurité, suivez ces bonnes pratiques du secteur :
Authentification et alignement Hygiène
- Toujours authentifier les nouveaux expéditeurs : avant que votre service marketing ou RH ne s'inscrive à un nouvel outil de messagerie électronique, assurez-vous qu'il prend en charge SPF DKIM ou SPF personnalisé. Ne laissez jamais un tiers envoyer des messages « au nom » de votre domaine sans configuration DNS appropriée.
- Préférez DKIM pour plus de résilience : SPF facilement contourné par le transfert d'e-mails. DKIM est beaucoup plus robuste, car la signature numérique reste attachée à l'en-tête de l'e-mail même lorsqu'il transite par différents serveurs.
Surveillance continue et gestion du changement
- Examens réguliers des rapports DMARC : DMARC génère des rapports XML qui détaillent qui envoie des e-mails en utilisant votre domaine. Les examiner au moins une fois par semaine vous aide à repérer les tentatives d'usurpation non autorisées ou les services légitimes qui ont soudainement cessé de s'aligner.
- Suivi des modifications de l'infrastructure de messagerie : traitez vos enregistrements DNS de messagerie comme du code. Conservez un journal de toutes les modifications apportées à vos enregistrements SPF, DKIM et DMARC. Si des problèmes de livraison surviennent après une migration de serveur ou un changement de fournisseur, vous pouvez rapidement identifier et rétablir la configuration spécifique qui a provoqué l'erreur « Policy Reject » (Rejet de politique).
Conclusion : ne laissez pas le « rejet » ruiner votre portée
L'erreur « DMARC Policy of Reject » (Politique DMARC de rejet) s'apparente un peu à votre propre agent de sécurité qui vous enfermerait accidentellement à l'extérieur du bureau. C'est certes agaçant, mais cela prouve que la serrure fonctionne réellement.
La solution n'est pas de jeter la serrure et de revenir à p=none, mais de vous assurer que vous avez les bonnes clés. En vous assurant que votre SPF et DKIM sont correctement alignés avec votre domaine, vous mettez fin aux rebonds et commencez à envoyer des e-mails en toute confiance. Surveillez vos rapports, authentifiez vos nouveaux outils avant leur mise en service, et vous n'aurez plus jamais à vous soucier de voir vos e-mails légitimes finir dans la corbeille numérique.
Commencez dès aujourd'hui votre essai gratuit de 15 jours avec nos experts pour découvrir comment nous pouvons simplifier la sécurité de votre domaine.
Foire aux questions
Pourquoi mon e-mail échoue-t-il au test DMARC mais réussit-il le test SPF?
Il s'agit généralement d'un problème d'alignement. Votre SPF » pour le domaine du serveur de messagerie, mais ce domaine ne correspond pas au domaine de votre adresse « De ».
Dois-je supprimer p=reject pour corriger la livraison ?
Non. Il s'agit d'une solution provisoire qui compromet la sécurité. Identifiez plutôt le service défaillant et autorisez-le correctement dans vos paramètres SPF.
Combien de temps faut-il pour que les corrections DMARC soient efficaces ?
Les modifications DNS peuvent prendre entre 24 et 48 heures pour se propager à l'échelle mondiale, bien que la plupart des systèmes modernes reflètent les modifications en moins d'une heure.
Le DMARC affecte-t-il les e-mails internes ou transférés ?
Oui. Le transfert perturbe souvent SPF, c'est pourquoi il est si important d'avoir une signature DKIM valide pour garantir que les e-mails transférés passent toujours la vérification DMARC.
Expert en sécurité des domaines et des courriels chez PowerDMARC
Yunes est chef d'équipe des opérations chez PowerDMARC et possède des connaissances approfondies en matière d'authentification et de sécurité des courriels. Yunes est certifié Microsoft Azure Administrator Associate et possède des certifications CompTIA A+ et bien d'autres encore.
Derniers messages de Yunes Tarada (voir tous)
