Pourquoi le protocole DMARC échoue-t-il ? Causes, solutions et comment le vérifier

Pourquoi votre domaine échoue-t-il au test DMARC ? Dans la quasi-totalité des cas, cela s'explique par l'une des deux raisons suivantes : soit SPF DKIM ne correspondent pas à votre adresse « De » visible, soit un expéditeur tiers n'a pas encore été autorisé. Ce guide aborde ces deux cas de figure et vous explique comment déterminer si les récents changements apportés par Google, Yahoo ou Microsoft à leurs politiques d'application sont la véritable cause de vos échecs DMARC, ainsi que la manière de vérifier vous-même la cause d'un échec avant de procéder à des modifications.

Pourquoi le protocole DMARC échoue-t-il ? La réponse en bref

Le DMARC échoue lorsque ni SPF le DKIM n'authentifient le message et ne correspondent au domaine « De » visible. Pour être validé, le DMARC exige que soit SPF le DKIM, passe le contrôle d'alignement du domaine. Lorsque aucun des deux n'est aligné, cela déclenche automatiquement un échec DMARC. Dans certains cas, lorsqu'un domaine est configuré uniquement avec SPF le DKIM en plus du DMARC (et non les deux), le DMARC échouera si l'alignement SPF échoue pour ce message, même si l'authentification est réussie.

Que signifie un échec DMARC ?

Un échec DMARC survient lorsqu'un e-mail ne parvient pas à passer le contrôle DMARC lui-même. Cela se produit lorsque ni SPF DKIM ne peuvent vérifier, de manière alignée, que l'e-mail a bien été envoyé depuis votre domaine. Les termes « vérifier » et « aligner » désignent ici deux opérations distinctes, et c'est en les confondant que naît la plupart des confusions.

SPF être validé alors que le DMARC peut tout de même échouer – Voici pourquoi

Imaginons que votre plateforme marketing envoie des e-mails en utilisant son propre domaine de chemin de retour, mail.esp-provider.com. SPF ce domaine et le valide ; l’adresse IP d’envoi est autorisée à envoyer au nom de mail.esp-provider.com. Mais votre adresse « De » visible est votredomaine.com. DMARC ne se contente pas de vérifier si SPF quelque part, il vérifie également si le domaine ayant passé SPF au domaine « De » visible. mail.esp-provider.com ne correspond pas à votredomaine.com. SPF donc SPF , mais DMARC échoue tout de même.

La même logique s'applique à DKIM. Un message peut comporter une signature DKIM valide et vérifiée cryptographiquement, mais si le domaine « d= » de cette signature (le domaine signataire) ne correspond pas à votre domaine « De » visible, DMARC le considère comme non aligné et la vérification échoue, même si la signature elle-même est parfaitement valide. C’est la source la plus courante de la confusion liée au fait que «SPF DKIM indiquent tous deux que le message est valide », et c’est pourquoi l’alignement, et pas seulement l’authentification, est la première chose à vérifier.

Causes courantes d'échec du DMARC

La plupart des échecs DMARC sont dus à une erreur de configuration quelque part dans votre infrastructure d'envoi plutôt qu'à une véritable attaque. Voici une explication détaillée de la manière dont les échecs SPF DKIM affectent le DMARC :

1. SPF

SPF pour quelques raisons spécifiques et bien documentées :

• Dépassement de la limite de 10 requêtes DNS : SPF à 10 requêtes DNS par vérification. Lorsqu'un domaine envoie des e-mails via plusieurs plateformes (par exemple, un CRM, un outil de marketing par e-mail et des serveurs de messagerie internes), chacune disposant de son propre mécanisme d'intégration, cette limite est rapidement atteinte. En cas de dépassement, SPF purement et simplement, souvent sans avertissement apparent jusqu'à ce que les e-mails commencent à être rejetés.
• Absence d'une règle SPF pour un service d'envoi : si vous ajoutez une nouvelle plateforme d'envoi et que vous oubliez d'ajouter sa SPF , les e-mails provenant de cette plateforme échoueront SPF .
• Plusieurs SPF sur un même domaine : le DNS n'autorise qu'un seul SPF par domaine. S'il en existe deux, la plupart des serveurs destinataires ne savent pas lequel considérer comme fiable et échouent à la vérification.
• Erreurs de syntaxe : des espaces superflus, des mécanismes mal formés ou un enregistrement mal ordonné peuvent invalider l'ensemble.

Découvrez pourquoi SPF .

2. Échec DKIM

Les échecs DKIM sont généralement dus à l'une des trois causes suivantes :

• Clés expirées ou renouvelées qui n’ont jamais été mises à jour dans le DNS : les clés DKIM ne sont pas permanentes. Si une clé est renouvelée du côté de l’expéditeur mais que la nouvelle clé publique n’est pas publiée dans le DNS, chaque signature est validée par rapport à la mauvaise clé et échoue.
• Un sélecteur manquant ou incorrect : le sélecteur indique aux serveurs destinataires quel enregistrement DNS contient la clé publique correspondant à une signature donnée. Si vous indiquez un sélecteur erroné, la vérification DKIM échoue, même si la clé elle-même est valide.
• Signatures invalidées après modification du message postérieure à la signature : DKIM signe des en-têtes spécifiques et le contenu du corps du message. Si un élément couvert par cette signature est modifié après la signature, celle-ci est invalidée.

Vous pouvez consulter notre guide sur la configuration de DKIM ainsi que notre analyse approfondie des causes d'échec de DKIM pour résoudre des cas spécifiques d'échec et d'erreurs liés à DKIM.

3. Expéditeurs tiers non autorisés (CRM, ESP, services d'assistance)

De nombreuses entreprises envoient des e-mails via des outils d'automatisation du marketing, des CRM, des logiciels d'assistance client et des services de messagerie transactionnelle. Si ces plateformes ne sont pas correctement autorisées à envoyer des e-mails au nom de votre domaine, chaque message qu'elles envoient risque de déclencher un échec DMARC.

Par exemple, Google Workspace et Microsoft 365 signent tous deux les e-mails sortants avec leur propre sélecteur DKIM par défaut, à moins que vous n’en configuriez un personnalisé. Cela signifie que les e-mails envoyés via ces services peuvent apparaître avec la mention « via provider.com » pour les destinataires. Ces messages peuvent ne pas passer le contrôle d’alignement, car le domaine de signature ne correspond pas à votre domaine « De » visible, à moins que vous n’ayez explicitement configuré une signature DKIM personnalisée pour votre propre domaine au sein de cette plateforme.

4. Transfert d'e-mails et listes de diffusion

Lorsqu'un e-mail est transféré, l'adresse IP du serveur de transfert ne figure pas dans SPF de l'expéditeur d'origine, ce qui rompt SPF . L'adresse « d'expéditeur » de l'enveloppe ou les en-têtes peuvent également être modifiés au cours du processus.

Les listes de diffusion sont similaires, mais ce n’est pas la même chose. Elles modifient souvent directement le corps ou les en-têtes du message, en ajoutant un pied de page de désabonnement ou en réécrivant l’objet, ce qui invalide la signature DKIM, même dans des situations où le simple transfert ne l’aurait pas fait. L'ARC (Authenticated Received Chain) a été spécialement conçu pour pallier ce problème en permettant aux serveurs intermédiaires d'ajouter un enregistrement vérifiable des résultats d'authentification d'origine. Cependant, il pourrait bientôt être obsolète, ses fonctionnalités devant être intégrées à la future spécification DKIM2.

5. Décalage entre les sous-domaines

Si votre politique DMARC s'applique à votredomaine.com, mais que des e-mails sont envoyés depuis mail.votredomaine.com sans alignement propre, ces e-mails risquent d'échouer aux vérifications DMARC. Les organisations qui gèrent leur messagerie sur plusieurs sous-domaines doivent mettre en place une authentification cohérente sur l'ensemble de ces sous-domaines, et pas seulement sur le domaine racine.

6. Délais de propagation DNS (pannes intermittentes)

Si un enregistrement DNS vient d’être modifié, certains serveurs destinataires peuvent encore consulter l’ancienne version mise en cache, tandis que d’autres ont déjà pris en compte la nouvelle. Ce décalage fait que le DMARC est validé pour certains destinataires et rejeté pour d’autres au même moment, ce qui peut prêter à confusion si l’on ignore que le délai de propagation en est la cause. Si vous avez récemment modifié un enregistrement SPF, DKIM ou DMARC et que les échecs semblent aléatoires plutôt que généralisés, patientez un peu (souvent jusqu’à 24 à 48 heures, selon le TTL de l’enregistrement) avant de conclure qu’il y a un autre problème.

Vérifiez la propagation de votre DNS en temps réel : https://powerdmarc.com/dns-propagation-checker/

7. Usurpation de domaine (le protocole DMARC fonctionne comme prévu)

Si quelqu’un usurpe l’identité de votre domaine pour envoyer des e-mails de hameçonnage ou de spam, ces messages échoueront naturellement au contrôle DMARC, car la source non autorisée ne satisfait pas aux vérifications SPF DKIM associées à votre domaine. C’est la seule cause de cette liste qui ne résulte pas d’une mauvaise configuration. Le protocole DMARC fonctionne exactement comme prévu, ce qui indique que votre domaine est activement pris pour cible ; il convient donc de surveiller attentivement cette situation dans vos rapports DMARC.

8. Vous rencontrez un message d'erreur ou un code d'erreur spécifique ?

Si vous êtes arrivé ici en cherchant une message d'erreur spécifique, sachez que tous les messages suivants ne sont que des erreurs DMARC ou des problèmes d'alignement formulés dans la langue propre à chaque plateforme. Les causes sous-jacentes et les solutions sont toutes abordées ci-dessus.

« Authentification DNS : échec DMARC » de Mimecast

Il s'agit de la méthode propre à Mimecast pour signaler qu'un message entrant ou sortant n'a pas satisfait à l'évaluation DMARC, généralement pour les mêmes raisons d'alignement SPF que celles décrites ci-dessus.

Erreurs de livraison SendGrid

Les erreurs liées à DMARC indiquent généralement que le domaine d'envoi propre à SendGrid, ou le domaine « De » d'un client transitant par SendGrid, n'est pas correctement configuré, souvent parce que laSPF personnalisée du domaine d'envoi n'a pas été menée à bien.

Codes SMTP de Gmail

Le code 421-4.7.26 correspond à une erreur temporaire, ce qui signifie que le message n’est pas authentifié (pas de SPF de DKIM valide) ; depuis fin 2025, Gmail transforme de plus en plus systématiquement ces erreurs en rejets permanents (code 550-5.7.26) en cas de non-conformité persistante. Un code apparenté, 550-5.7.1, signifie spécifiquement que le message a échoué au regard de la politique DMARC publiée par le domaine d'origine.

Microsoft 550 5.7.515

Il s'agit d'un rejet définitif mis en place par Microsoft à l'encontre des expéditeurs à fort volume (plus de 5 000 e-mails par jour vers des adresses Outlook, Hotmail ou Live.com) qui ne satisfont pas à ses exigences d'authentification, avec effet au 5 mai 2025.

Pourquoi le protocole DMARC a-t-il soudainement cessé de fonctionner ?

Si votre domaine respectait auparavant les règles DMARC et qu'il ne les respecte plus depuis peu, passez en revue cette liste avant de conclure à un dysfonctionnement :

• Un nouvel outil marketing, un CRM ou une plateforme d'assistance a été ajouté sans que votre configuration SPF DKIM n'ait été mise à jour.
• Un enregistrement DNS a récemment été modifié et présente désormais une erreur de syntaxe ou un SPF en double par inadvertance.
• Une clé DKIM a été renouvelée ou est arrivée à expiration sans que la nouvelle clé ait été publiée dans le DNS.
• Un sous-domaine a commencé à envoyer des e-mails sans que ses paramètres SPF, DKIM ou DMARC soient configurés.
• Google, Yahoo ou Microsoft ont renforcé les mesures de contrôle de leur côté.

Google, Yahoo et Microsoft appliquent le protocole DMARC de manière plus stricte que jamais

Les exigences de Google et Yahoo concernant les expéditeurs de masse ont été annoncées fin 2023 et sont entrées en vigueur pour les expéditeurs à fort volume en février 2024, leur application intégrale ayant suivi en avril 2024. Depuis lors, Gmail n’a cessé de durcir sa politique de conversion des reports temporaires en rejets définitifs pour les domaines qui restent non conformes, une tendance qui s’est nettement renforcée jusqu’à la fin de l’année 2025.

Microsoft a ensuite publié ses propres exigences concernant les adresses Outlook, Hotmail et Live.com. La mise en application a débuté le 5 mai 2025 : les envois en masse non conformes (plus de 5 000 e-mails par jour) sont désormais rejetés d'emblée avec le code d'erreur 550 5.7.515, au lieu d'être simplement redirigés vers le dossier spam.

Si votre domaine envoie 5 000 e-mails ou plus par jour à l'un de ces fournisseurs et que le protocole DMARC a commencé à échouer plus souvent ces derniers temps, ce durcissement des mesures pourrait bien en être la cause. La solution est la même dans les deux cas : identifiez toutes les sources d'envoi, assurez-vous que SPF DKIM sont correctement configurés, et vérifiez que votre enregistrement DMARC est correct. Pour connaître l'ensemble des exigences par fournisseur, consultez notre guide des exigences applicables aux expéditeurs d'e-mails en masse.

Comment vérifier un échec DMARC

Avant d'apporter des modifications, vérifiez ce qui se passe réellement :

1. Envoyez un message test vers Gmail, Outlook et Yahoo, puis ouvrez l'en-tête « Authentication-Results ».

Dans Gmail, ouvrez le message et sélectionnez « Afficher l'original ». Dans Outlook, utilisez « Afficher les détails du message ». Recherchez les entrées « spf, « dkim= » et « dmarc= », puis vérifiez si le domaine validé correspond à l'adresse d'expéditeur affichée.

2. Comparez l'adresse IP source à l'origine de l'échec avec vos rapports DMARC agrégés (RUA).

Ces rapports répertorient toutes les adresses IP envoyant des e-mails au nom de votre domaine et indiquent si chacune d'entre elles a réussi ou échoué le test ; c'est généralement le moyen le plus rapide de repérer une source non autorisée ou mal configurée. Si vous n'êtes pas familier avec le format XML brut, vous pouvez consulter notre guide expliquant comment lire les rapports DMARC.

3. Vérifiez le domaine à l'aide d'un outil gratuit de vérification DMARC

Vérifiez l'état actuel de vos enregistrements, car un enregistrement qui semblait correct au moment de sa publication peut, avec le temps, présenter des problèmes de syntaxe, des doublons ou des lacunes de propagation. Notre outil de vérification des enregistrements DMARC s'en charge en un seul passage.

Que se passe-t-il lorsque DMARC échoue ?

Le résultat dépend entièrement de la politique DMARC définie pour votre domaine. Cette politique indique aux serveurs de messagerie destinataires comment traiter les e-mails qui ne passent pas l'authentification, et chaque niveau entraîne des conséquences différentes.

p=none : Surveillance uniquement

Avec une politique DMARC définie sur « p=none », les e-mails qui ne respectent pas les règles DMARC sont tout de même remis, mais ils finissent souvent dans le dossier « Spam » plutôt que dans la boîte de réception. Cette politique est conçue à des fins de surveillance. Elle vous permet de collecter des rapports DMARC et d’identifier les problèmes d’authentification sans perturber votre flux de messagerie. Bien qu’il s’agisse d’un point de départ sûr, conserver la valeur « p=none » à long terme rend votre domaine vulnérable, car elle ne bloque pas activement les expéditeurs non autorisés.

quarantine: envoyé dans les spams

Dans le cadre d'une politique DMARC définie sur quarantine, les e-mails rejetés sont envoyés dans le dossier « spam » du destinataire. Cela réduit la visibilité et l'engagement des utilisateurs, car vos e-mails légitimes risquent de se retrouver noyés parmi les courriers indésirables. Bien que cette politique offre une meilleure protection que « p=none », elle peut tout de même nuire à votre activité si des e-mails légitimes sont rejetés en raison d'erreurs de configuration plutôt que d'une véritable usurpation d'identité.

p=rejeter : Entièrement bloqué

Une politique DMARC définie sur « p=reject » entraînera le blocage total du message par les serveurs de réception, l'empêchant ainsi d'atteindre le destinataire. Il s'agit de la politique la plus stricte et la plus sécurisée. Elle met fin sur-le-champ aux tentatives d'hameçonnage et d'usurpation d'identité. Cependant, si vos SPF DKIM ne sont pas correctement configurés, une politique « p=reject » bloquera également vos propres e-mails légitimes, ce qui peut gravement perturber les communications professionnelles.

Impact des échecs DMARC sur votre entreprise

Les échecs DMARC posent des défis importants aux entreprises qui utilisent le courrier électronique comme moyen de communication. Voici comment un échec DMARC peut affecter votre organisation.

Réduction de la délivrabilité des e-mails

Les échecs DMARC peuvent entraîner le blocage ou le rejet d'e-mails légitimes par les fournisseurs de messagerie, ce qui a des répercussions sur les communications professionnelles. Que vos e-mails atterrissent dans le dossier « spam » ou soient purement et simplement rejetés, le résultat est le même : vos messages ne parviennent pas aux destinataires qui ont besoin de les recevoir. Pour les entreprises qui s'appuient sur la messagerie électronique pour leurs ventes, leur marketing, leur service client ou leurs communications transactionnelles, cela se traduit directement par des opportunités manquées.

Réputation de l'expéditeur endommagée

Des échecs répétés liés au protocole DMARC peuvent nuire à la réputation d'expéditeur de votre domaine, ce qui rendra plus difficile l'acheminement des e-mails, même ceux qui sont authentifiés, vers la boîte de réception. Les fournisseurs de messagerie tels que Google et Microsoft suivent l'historique d'authentification de votre domaine. Lorsqu'ils constatent une série d'échecs liés au protocole DMARC, ils commencent à considérer votre domaine comme moins fiable, ce qui signifie que même les e-mails correctement configurés peuvent, à terme, rencontrer des problèmes de délivrabilité.

Taux d'ouverture et engagement client en baisse

Les échecs DMARC peuvent entraîner le classement des e-mails dans les dossiers de spam, ce qui réduit les taux d'ouverture et l'engagement des clients. Si vos campagnes marketing, vos factures, vos confirmations de commande ou vos communications professionnelles importantes se retrouvent systématiquement dans les dossiers de spam, votre public ne les verra tout simplement pas, ce qui se traduira par une perte de chiffre d'affaires et des clients mécontents.

Risque accru d'hameçonnage et d'usurpation d'identité

Un taux d'échec DMARC élevé augmente le risque d'attaques par hameçonnage et d'usurpation de domaine, ce qui sape la confiance des clients. Si votre domaine fait l'objet d'une usurpation, les sources non autorisées échoueront aux contrôles DMARC ; toutefois, en l'absence d'une politique d'application stricte, ces e-mails usurpés pourraient tout de même parvenir à leurs destinataires, exposant ainsi vos clients, vos partenaires et vos employés au risque de se faire piéger par des messages frauduleux envoyés au nom de votre marque.

Dommages à long terme sur la délivrabilité

Les échecs DMARC peuvent indiquer aux fournisseurs de messagerie qu’un domaine n’est pas fiable, ce qui peut avoir des répercussions à long terme sur la délivrabilité des e-mails. Rétablir la réputation d’un expéditeur qui a été compromise demande beaucoup de temps et d’efforts. Une fois l’authentification rétablie, c’est souvent la manière dont on rétablit progressivement la confiance des destinataires — grâce à une « mise en route » structurée des adresses IP, en augmentant le volume des envois par paliers quotidiens mesurés et en générant des signaux d’engagement positifs de la part de véritables destinataires — qui détermine la rapidité avec laquelle la délivrabilité se rétablit réellement.

Comment corriger un échec DMARC

Pour résoudre un échec DMARC, il faut comprendre pourquoi cet échec s'est produit et apporter les modifications nécessaires à votre configuration d'authentification des e-mails.

Étape 1 : Commencez par une politique DMARC souple (p=none)

En l'absence de politique, vous pouvez commencer par surveiller votre domaine à l'aide des rapports agrégés DMARC (RUA) et suivre de près les e-mails entrants et sortants, ce qui vous permet de remédier aux problèmes de livraison avant qu'ils ne s'aggravent.
Cela permet aux messages légitimes de continuer à parvenir à leurs destinataires même si la validation DMARC échoue pour ceux-ci, mais cela vous expose toutefois au phishing et à l'usurpation d'identité pendant ce temps.

Étape 2 : Assurer l'alignement SPF et DKIM

Vérifiez que votre enregistrement DNS ne contient pas d'erreurs et assurez-vous que le domaine validé par SPF DKIM correspond bien à votre adresse d'expéditeur visible, conformément au mécanisme expliqué plus haut dans ce guide. Notre outil gratuit de vérification DMARC permet de détecter les erreurs de syntaxe DMARC ou de formatage de l'enregistrement DNS, notamment les espaces superflus et les fautes d'orthographe.

L'utilisation SPF de DKIM et SPF offre une approche à plusieurs niveaux : DKIM vérifie que le message n'a pas été altéré, tandis que SPF l'identité du serveur expéditeur. Ensemble, ces deux protocoles contribuent à renforcer la confiance dans la source du courriel et à réduire le risque d'usurpation d'identité et d'activité non autorisée par courriel.

Étape 3 : Renforcer votre défense par l'application de la loi

Une fois que les expéditeurs légitimes ont été confirmés et répertoriés, passez à une politique stricte (quarantine, puis p = rejet) afin de bénéficier d'une protection efficace contre l'usurpation de domaine et les attaques de hameçonnage.

Étape 4 : Protéger avec la détection des menaces basée sur l'IA

Supprimez les adresses IP malveillantes et signalez-les directement depuis votre plateforme DMARC afin de prévenir toute future tentative d'usurpation d'identité, en utilisant des outils de veille sur les menaces lorsque ceux-ci sont disponibles.

Étape 5 : Optimiser en continu à l'aide des rapports d'erreurs

Activez les rapports d'échec DMARC (RUF) pour obtenir des informations détaillées sur les cas spécifiques où des e-mails n'ont pas respecté les règles DMARC, ce qui vous permettra d'identifier la cause du problème et de le résoudre plus rapidement.

Résoudre les échecs DMARC avec PowerDMARC

La gestion des échecs DMARC peut s'avérer complexe, en particulier lorsque vous gérez plusieurs services d'envoi, des plateformes tierces et une infrastructure de messagerie en constante évolution. PowerDMARC simplifie l'ensemble du processus, de la configuration initiale à la surveillance continue et à la détection des menaces.

Nous aidons les organisations à déployer correctement DMARC en fournissant des conseils étape par étape et des outils d'automatisation qui garantissent que vos enregistrements DMARC, SPF et l'authentification DKIM sont correctement configurés et alignés dès le premier jour. Cela réduit le risque de mauvaises configurations qui entraînent des échecs DMARC et permet à votre domaine d'être plus rapidement en conformité totale.

Une fois DMARC mis en place, PowerDMARC surveille en permanence votre trafic de messagerie et génère des rapports et des alertes en temps réel dès qu'un échec DMARC est détecté.

Voici ce qui nous rend uniques :

• Renseignements sur les menaces basés sur l'IA et alertes automatisées qui identifient les tentatives d'hameçonnage et d'usurpation d'identité en temps réel
• Assistance étape par étape à l'intégration et à la mise en œuvre pour une utilisation optimale des protocoles DMARC, SPF et DKIM dès le premier jour.
• Des rapports lisibles et exploitables qui remplacent les données XML complexes par des informations claires.
• Plus de 5 000 organisations dans le monde entier lui font confiance pour corriger et prévenir les échecs DMARC.

Foire aux questions

1. Que signifie DMARC ?

DMARC signifie « Domain-Based Message Authentication, Reporting, and Conformance » (authentification, rapport et conformité des messages basés sur le domaine). Il s'agit d'un protocole d'authentification des e-mails qui aide à protéger les domaines contre l'usurpation d'adresse e-mail, le phishing et d'autres cyberattaques en vérifiant que les e-mails sont légitimement envoyés par des sources autorisées.

2. Comment réussir l'authentification DMARC ?

Pour réussir l'authentification DMARC, vos e-mails doivent être conformes SPF DKIM et correspondre au domaine indiqué dans le champ « De ». Pour cela, assurez-vous que vos adresses IP d'envoi sont autorisées dans SPF, que le DKIM est correctement signé et que votre enregistrement DMARC est correctement publié dans le DNS.

3. Comment remédier à l'absence de protection DMARC ?

Pour remédier à l'absence de protection DMARC, publiez un enregistrement DMARC dans le DNS de votre domaine. Commencez par une politique de surveillance (p=none) afin de collecter des rapports, puis passez progressivement à une application plus stricte (quarantine p=reject) une fois que vous aurez vérifié que toutes les sources d'e-mails légitimes sont authentifiées.

4. Comment corriger l'erreur DMARC ?

Pour résoudre l'erreur DMARC, commencez par vérifier pourquoi le message n'a pas réussi l'authentification. Assurez-vous que SPF DKIM sont correctement configurés et correspondent bien au domaine d'origine, puis vérifiez que la politique DMARC de votre domaine est correctement publiée dans le DNS et qu'elle correspond bien à la manière dont vos e-mails sont effectivement envoyés. Une fois que tout est en ordre, surveillez les rapports DMARC pour vous assurer que le problème est résolu.

5. Qu'est-ce qu'une violation DMARC ?

Une violation DMARC est une autre façon de décrire un message qui échoue au contrôle DMARC, soit parce qu’il n’est pas autorisé (quelqu’un usurpe votre domaine), soit parce qu’un expéditeur légitime n’est pas correctement aligné. La suite dépend de votre politique : p=none l’enregistre dans les journaux,quarantine dans le dossier spam, et p=reject le bloque purement et simplement.

6. Le DMARC peut-il échouer même si SPF le DKIM sont tous deux validés ?

Oui, et c’est l’une des sources de confusion les plus courantes. Techniquement, SPF DKIM peuvent tous deux passer leurs propres contrôles alors que DMARC échoue, si le domaine validé par l’un ou l’autre ne correspond pas à votre adresse « De » visible. Un message provenant de mail.esp-provider.com peut passer SPF et échouer tout de même au contrôle DMARC si votre domaine « De » visible est yourdomain.com, car c’est l’alignement, et pas seulement l’authentification, que DMARC vérifie réellement.

• À propos de
• Derniers messages

Maitham Al Lawati

Expert en cybersécurité, PDG de PowerDMARC

Maitham est un entrepreneur technologique, expert en cybersécurité, PDG et fondateur de PowerDMARC avec plus de 15 ans d'expérience dans l'industrie. Maitham est titulaire d'un Global MBA de l'Université de Manchester et de diverses certifications professionnelles, notamment CISSP, CISM, CRISC et ISC2 CCSP.

Derniers messages de Maitham Al Lawati (voir tous)

• Comment configurer DMARC : guide complet de configuration étape par étape (2026) - 20 juin 2026
• Comment lire les rapports DMARC : guide complet sur les indicateurs RUA et RUF - 10 juin 2026
• Qu'est-ce que le DMARC ? Définition, fonctionnement et importance - 28 avril 2026