6 échecs DKIM et DMARC les plus courants et comment les corriger

SPF (Sender Policy Framework) n’est qu’un des éléments du puzzle de l’authentification des emails. Vous pouvez avoir un enregistrement SPF parfait et voir quand même vos emails finir en spam, rejetés ou échouer au DMARC. Pourquoi ? DKIM (DomainKeys Identified Mail) et DMARC (Domain-based Message Authentication, Reporting, and Conformance) introduisent leurs propres modes d’échec, piégeant même les administrateurs email expérimentés.

Nous constatons cela en permanence au sein des organisations utilisatrices de Red Sift OnDMARC. Une équipe marketing configure correctement SPF mais n’active jamais la signature DKIM. Une équipe IT publie un enregistrement DMARC avec p=none et le laisse ainsi pendant un an. Un expéditeur tiers signe les emails avec son propre domaine au lieu du vôtre, cassant l’alignement. Ce ne sont pas des cas isolés. C’est la réalité quotidienne de l’authentification email en 2026.

Avec les nouvelles exigences d’authentification des emails en 2026, SPF seul ne suffira plus à garantir la délivrabilité. Quand c’est possible, avoir DKIM ET SPF configurés est le meilleur moyen d’assurer les taux de délivrabilité les plus élevés

Le calendrier de mise en application rend la chose urgente. Google et Yahoo exigent SPF, DKIM et DMARC pour les expéditeurs en masse depuis février 2024 [1]. Microsoft a suivi en mai 2025, rejetant les emails non conformes avec le code d’erreur 550 5.7.515 [2]. Il ne s’agit pas de simples recommandations. Gmail est passé d’avertissements pédagogiques à des rejets directs en novembre 2025, et Microsoft bloque désormais les emails non conformes sans passer par le dossier indésirable.

Les chiffres d’adoption témoignent du chemin qu’il reste à parcourir. Une étude sur 5,5 millions de domaines indique que seuls 22,7 % possèdent un enregistrement DKIM détectable, ce qui en fait le protocole d’authentification majeure le moins adopté [3]. Et même si l’adoption de DMARC progresse, 69,6 % des domaines n’ont aucun enregistrement DMARC et seuls 6 % appliquent p=reject [3]. L’analyse de Red Sift sur 73,3 millions de domaines révèle que seulement 2,5 % ont mis en place p=reject [4].

Parallèlement, les pertes liées à la cybercriminalité continuent d’augmenter. Le FBI a enregistré dans son rapport 2025 sur la criminalité Internet plus de 20,8 milliards de dollars de pertes (soit +26 % par rapport à 2024), le phishing et l’usurpation étant encore la catégorie la plus signalée avec 191 561 plaintes [5]. La compromission d’e-mails professionnels représente plus de 3 milliards de dollars de pertes pour 24 768 incidents [5]. Des configurations correctes de SPF et DKIM associées à un DMARC appliqué sont la clé pour empêcher des attaques d’usurpation de votre domaine. Configurer DKIM sur tous les expéditeurs légitimes vous permet aussi d’éviter toute rupture d’authentification, même en cas de transfert ou de redirection ultérieure.

La pression réglementaire est réelle. PCI DSS v4.0.1 exige DMARC en quarantaine ou rejet pour les organisations traitant des paiements [6]. CISA, NCSC britannique, ASD australien et CCCS canadien l’imposent pour les domaines publics. Pour un point complet, consultez notre récapitulatif des mandats DMARC dans le monde. De plus, de plus en plus d’assureurs exigent l’application DMARC en condition de souscription.

Voici les six échecs DKIM et DMARC que nous constatons le plus souvent, et comment les corriger.

Ce à quoi cela ressemble : Vos rapports DMARC ou les en-têtes des emails indiquent dkim=fail (le hash du corps n’a pas été vérifié). La signature DKIM est présente, la clé publique existe en DNS, mais la vérification échoue.

Pourquoi cela arrive : DKIM fonctionne en calculant un hash du corps du mail lors de la signature (balise bh= dans DKIM-Signature). Le serveur destinataire interroge la clé publique associée au sélecteur ayant servi à signer, puis recalcule le hash. Si le contenu change entre la signature et la réception, les hash ne correspondent plus et DKIM échoue.

Les coupables habituels sont les systèmes intermédiaires qui modifient le message après la signature :

• Passerelles de sécurité email qui réécrivent les liens URL pour analyse (Microsoft Defender, Barracuda, etc.)
• Filtres anti-spam qui ajoutent ou modifient des en-têtes
• Logiciels de listes de diffusion qui ajoutent des pieds de page, en-têtes de liste, liens de désinscription, ou modifient le MailFrom SMTP, voire remplacent la signature DKIM par la leur
• Outils DLP (prévention de fuite de données) qui scannent et parfois modifient le contenu sortant
• Transferts automatiques où le serveur de redirection modifie le message

C’est l’un des scénarios DKIM les plus difficiles à diagnostiquer : la signature semble valide (clé et sélecteur corrects, présence dans le DNS), mais le corps du message a changé après la signature.

Comment corriger :

Le principe de base : la signature DKIM doit s’effectuer en toute dernière étape avant la sortie de votre infrastructure. Toute modification après la signature casse la signature.

• Réorganisez votre flux d’emails. Si vous disposez d’une passerelle de sécurité qui réécrit les liens, configurez la signature DKIM après cette opération, pas avant. Cela signifie souvent de faire signer la passerelle, et non pas le serveur de messagerie initial.
• Utilisez la canonisation c=relaxed/relaxed. DKIM supporte les modes simple et relaxed. Le mode relaxed tolère les variations d’espaces ou de formatage d’entête. Réglez l’entête et le corps tous deux en canonisation relaxed (c=relaxed/relaxed) pour limiter les faux échecs.
• Identifiez le système modificateur. Comparez le hash DKIM du corps dans la signature originale (bh=) à celui recalculé par le serveur destinataire. S’ils diffèrent, un élément dans le trajet email a modifié le contenu. Remontez votre flux d’envoi (application, passerelles, filtres) pour isoler le coupable.
• Pour listes de diffusion et transferts, utilisez DKIM + ARC. Les listes de diffusion modifient les messages (c’est leur fonctionnement). On ne peut pas l’éviter. ARC (Authenticated Received Chain) préserve les résultats d’authentification originaux à travers la chaîne de transmission ; Gmail et Microsoft en tiennent compte dans la livraison. De votre côté, assurez-vous que DKIM est toujours configuré pour que l’envoi direct reste valide. Utilisez Red Sift Investigate pour vérifier que vos messages passent le test de hash avant tout transfert. Pour plus d’infos sur l’impact du transfert sur l’authentification, voyez notre guide de configuration SPF, DKIM et DMARC.

Ce à quoi cela ressemble : Les en-têtes d’email affichent dkim=fail (pas de clé pour la signature) ou dkim=permerror. Le serveur de réception ne trouve pas ou ne parvient pas à lire votre clé publique DKIM en DNS.

Pourquoi cela arrive : DKIM dépend d’une clé publique publiée en DNS à un emplacement précis : selector._domainkey.votredomaine.com. Si le serveur de réception ne trouve pas ou lit mal cet enregistrement, la vérification échoue complètement. C’est l’échec DKIM le plus courant pour plusieurs raisons :

• L’enregistrement DNS n’a jamais été créé. On active la signature DKIM côté service email mais on oublie d’ajouter la clé publique DNS. Google Workspace, par exemple, nécessite de générer la clé DKIM dans la console d’administration puis de l’ajouter à la main dans le DNS. Si on oublie, la signature a lieu mais échoue systématiquement en réception.
• L’enregistrement est mis au mauvais endroit du DNS. Si vous gérez le DNS sur plusieurs plateformes (registrar, Cloudflare, hébergeur), l’enregistrement DKIM peut avoir été inséré dans une zone inactive. Le serveur destinataire interroge la zone DNS autoritaire et ne trouve rien.
• Tronquature des clés 2048 bits. Les clés publiques DKIM RSA 2048 bits sont longues, dépassant souvent la limite de 255 caractères d’une chaîne TXT DNS. Si votre prestataire DNS tronque la clé sans la découper en plusieurs chaînes entre guillemets, la clé devient incomplète donc la vérification échoue.
• Mauvais sélecteur. La balise s= dans DKIM-Signature détermine le sélecteur utilisé pour l’interrogation DNS. Si la valeur s= ne correspond pas au nom du sélecteur DNS, le résultat est vide. Ce cas survient lors d’une rotation de sélecteurs non synchronisée (l’ancien sélecteur reste en DNS alors que le nouveau n’est jamais créé).

Comment corriger :

Commencez par identifier le sélecteur. Consultez l’en-tête DKIM-Signature d’un mail envoyé (dans Gmail, cliquez sur "Afficher l’original"). Repérez la balise s=. Cherchez ensuite l’enregistrement DNS associé manuellement, ou via l’outil Domain Analyzer d’Red Sift OnDMARC.

Indiquez le domaine et le sélecteur à contrôler, pour voir l’intégralité de l’enregistrement DKIM et les anomalies de configuration détectables.

dig TXT selector._domainkey.yourdomain.com +short

Si la requête ne renvoie rien, l’enregistrement manque. Si le résultat est partiel, la clé est tronquée.

• Si l’enregistrement manque : Rendez-vous sur la page d’administration DKIM de votre service email, copiez la clé publique et ajoutez-la comme TXT à selector._domainkey.votredomaine.com dans la zone DNS active.
• Pour les clés tronquées : Scindez la clé en plusieurs sous-chaînes de 255 caractères entre guillemets dans un seul champ TXT. La plupart des DNS modernes le gèrent automatiquement avec DKIM via CNAME.
• En cas de mauvais sélecteur : Vérifiez que le nom de sélecteur dans votre service email correspond à celui de votre DNS. Si votre ESP change de sélecteur, actualisez le DNS.
• Préférez le DKIM via CNAME quand possible. Au lieu de publier la totalité de la clé publique en TXT, nombre d’ESPs proposent une délégation CNAME. Vous n’avez alors rien à modifier en DNS lors d’une rotation de clé côté ESP.

Ce à quoi cela ressemble : DKIM fonctionnait pendant des mois puis soudain échoue. Les entêtes signalent dkim=fail sans changement côté DNS ou configuration chez vous.

Pourquoi cela arrive : Les clés DKIM ne sont pas éternelles. Pour des raisons de sécurité, elles doivent être remplacées régulièrement, ce qui engendre parfois des interruptions d’authentification sans avertissement.

Trois cas fréquents :

• L’ESP a changé la clé sans que vous en soyez informé. Avec DKIM en TXT (clé publique dans votre DNS), l’ESP peut changer de clé privée à tout moment. Si le privé et le public ne correspondent plus, la signature échoue même si de votre côté rien n’a bougé.
• Clés RSA 1024 bits rejetées. Le NIST recommande 2048 bits mini, et l’industrie y est passée [7]. Certains serveurs refusent ou signalent désormais les signatures DKIM 1024 bits. Si votre configuration date, vous pouvez être concerné.
• Échéance de la balise x=. La balise x= DKIM précise une date d’expiration de la signature. Si le mail prend du retard (ex: file d’attente), il peut arriver expiré donc non vérifiable malgré une config correcte.

Comment corriger :

• Passez aux clés 2048 bits. Si vous utilisez encore du 1024 bits, migrez au plus vite. Sous Microsoft 365, utilisez la commande Rotate-DkimSigningConfig PowerShell ; sous Google Workspace, générez une nouvelle clé 2048 bits depuis Admin Console \> Apps \> Google Workspace \> Gmail \> Authentifier l’email. Notre guide de configuration des protocoles email détaille la gestion des clés DKIM.
• Optez pour le DKIM par CNAME pour simplifier les rotations. En déléguant le DKIM à l’ESP (via CNAME), les changements de clé se font de leur côté sans action DNS manuelle. Red Sift OnDMARC centralise et gère toutes vos configurations DKIM sur une même plateforme.
• Planifiez la rotation. Bonne pratique : rotation tous les 6 à 12 mois avec des clés 2048 bits, noms de sélecteurs explicites (ex : jan2026) pour savoir quand la clé doit être renouvelée.
• Évitez ou allongez la balise x=. Si le tag d’expiration est utilisé, prévoyez une marge d’acheminement suffisante. Beaucoup choisissent tout simplement de l’omettre (x=) pour éviter les échecs intempestifs.

Ce à quoi cela ressemble : DKIM vérifié (dkim=pass), mais DMARC échoue. Les rapports DMARC indiquent une réussite DKIM mais un alignement échoué.

Pourquoi cela arrive : Il s’agit de l’échec DMARC/DKIM le plus courant. Il affecte toutes les organisations qui délèguent des envois à des prestataires tiers.

DMARC ne vérifie pas seulement le succès DKIM. Il contrôle aussi l’alignement entre le domaine DKIM (d=) et le From. Si un service tiers signe les emails avec son propre domaine au lieu du vôtre, DKIM passe mais l’alignement DMARC échoue.

Concrètement :

• Vous utilisez SendGrid pour envoyer des campagnes depuis marketing@yourdomain.com.
• SendGrid signe avec d=sendgrid.net par défaut.
• Le serveur destinataire vérifie DKIM : la signature correspond à la clé publique SendGrid donc dkim=pass.
• Puis DMARC vérifie l’alignement : sendgrid.net =? yourdomain.com ?
• Non. Alignement échoué. Si SPF échoue aussi l’alignement (fréquent avec les tiers), DMARC échoue totalement.

Ceci concerne la quasi-totalité des ESP, CRM et solutions SaaS (Mailchimp, HubSpot, Salesforce, Zendesk, Freshdesk, Intercom…) qui signent par défaut avec leur domaine sauf configuration DKIM personnalisée.

Comment corriger :

Activez la signature DKIM personnalisée pour chaque service afin que la balise d= corresponde à votre domaine :

• Pour la majorité des ESP (Mailchimp, SendGrid, HubSpot…) : Cherchez « Authentification de domaine » ou « DKIM personnalisé ». Ajoutez les records CNAME ou TXT fournis à votre DNS. Les signatures prendront alors d=yourdomain.com.
• Google Workspace : DKIM utilise votre domaine par défaut, mais il faut l’activer et publier l’enregistrement DNS explicitement.
• Microsoft 365 : Signature DKIM personnalisée à activer dans le portail Defender (deux CNAME par domaine).

Une fois DKIM personnalisé en place pour chaque service, vérifiez le mode d’alignement DMARC. Deux modes sont possibles (balise adkim=) :

• Relaxed (adkim=r) : Le domaine de signature DKIM peut être un sous-domaine du From. mail.yourdomain.com s’aligne sur yourdomain.com. C’est la valeur par défaut, recommandée pour la plupart.
• Strict (adkim=s) : Le domaine doit être exactement identique.

Red Sift OnDMARC repère les expéditeurs qui passent la vérification DKIM mais échouent l’alignement, avec l’indication du domaine d= problématique. Pour un éclairage sur les liens entre DKIM, SPF et DMARC, consultez notre comparatif.

Ce à quoi cela ressemble : Votre record DMARC existe, des rapports sont produits, mais la politique est p=none. Les emails contrefaits utilisant votre domaine sont livrés sans restriction. Votre domaine est « DMARC activé » mais pas protégé.

Pourquoi cela arrive : Rester bloqué en p=none est l’échec DMARC le plus généralisé, d’ordre opérationnel plus que technique.

On publie DMARC en p=none pour collecter les rapports au démarrage, ce qui est correct, mais sans jamais passer à l’application. Les raisons sont connues : rapports illisibles (XML brut), incertitude sur la légitimité des expéditeurs, peur de bloquer de vrais emails, projet qui perd en priorité… Résultat : le record DMARC reste à p=none, sans effet sur la sécurité.

Les chiffres sont parlants. Sur 5,5 millions de domaines analysés, 17,6 % en p=none [3]. Selon Red Sift (73,3 millions de domaines analysés), seuls 14,9 % ont commencé leur parcours DMARC, 2,5 % en p=reject [4]. La très grande majorité reste ainsi en mode « surveillance ».

La politique p=none n’est qu’un outil de reporting, pas un rempart. Elle indique au destinataire de délivrer tous les emails sans contrôle d’authentification, et de simplement générer des rapports. Les attaquants peuvent usurper votre domaine à volonté, chaque faux email arrive à destination.

Comment corriger :

Le chemin de p=none à p=reject est direct à condition d’avoir les bons outils et la bonne méthode. Voici l’approche recommandée avec Red Sift OnDMARC :

1. Identifiez tous les expéditeurs légitimes. Reconstituez l’inventaire exhaustif de tous les services envoyant en votre nom via les rapports DMARC. OnDMARC le fait automatiquement, en classifiant l’authentification de chaque expéditeur.
2. Corrigez l’authentification de chaque expéditeur. Activez SPF et DKIM pour toutes les sources légitimes. Assurez-vous qu’au moins l’un des deux (idéalement les deux) passe et s’aligne.
3. Passez à p=quarantine. Quand tous les légitimes sont authentifiés, basculez sur quarantine (les échecs vont en spam). Surveillez une à deux semaines pour déceler les oublis.
4. Passez à p=reject. Quand plus aucun mail légitime n’est coincé en quarantaine, appliquez reject (blocage total en cas d’échec DMARC).
5. Utilisez le tag pct= pour déployer progressivement. Si le passage direct à reject vous inquiète, appliquez pct=25 — la politique ne touche que 25 % des messages échoués. Augmentez peu à peu (50, 75, 100 %) avec la confiance.

Avec le bon outil, les organisations atteignent généralement p=reject en 6 à 8 semaines. Sans, beaucoup n’y parviennent jamais. Notre guide de mise en application DMARC pas à pas détaille toute la procédure.

Ce à quoi cela ressemble : SPF et DKIM affichés comme pass dans les rapports ou en-têtes, et pourtant DMARC échoue. Ce cas est l’un des plus déroutants : tout semble correct, et ça échoue quand même.

Pourquoi cela arrive : DMARC exige l’alignement, pas uniquement l’authentification. SPF et DKIM peuvent réussir individuellement, mais échouer DMARC si leurs domaines authentifiés diffèrent du From affiché.

Deux contrôles d’alignement sont effectués en parallèle :

• Alignement SPF : Le domaine du Return-Path (envelope-from) doit correspondre ou être un sous-domaine du From.
• Alignement DKIM : Le domaine d= de la signature DKIM doit correspondre ou être un sous-domaine du From.

DMARC est validé si au moins un de ces alignements réussit. L’échec n’apparaît que si aucun ne s’aligne.

Exemple concret :

• Votre entreprise envoie des notifications clients depuis support@yourdomain.com via Zendesk.
• Zendesk utilise son propre domaine pour le Return-Path (@zendesk.com).
• SPF contrôle l’enregistrement SPF Zendesk, retrouve l’IP et passe, mais le domaine détecté est zendesk.com, pas yourdomain.com.
• L’alignement échoue. Zendesk signe aussi avec d=zendesk.com par défaut. DKIM passe côté Zendesk, mais échoue l’alignement car zendesk.com ne correspond pas à yourdomain.com.
• Les deux protocoles authentifient mais échouent l’alignement : DMARC échoue.

Cet exemple se retrouve chez presque tous les expéditeurs tiers sans authentification personnalisée.

Comment corriger :

Au moins un protocole doit à la fois réussir et s’aligner. Le plus fiable est de corriger les deux :

• Alignement DKIM : Activez la signature DKIM personnalisée chez chaque expéditeur tiers (balise d= sur votre domaine ; voir l’échec nº 4 ci-dessus pour chaque plateforme).
• Alignement SPF : Paramétrez chaque service pour qu’il utilise votre domaine (ou un sous-domaine) comme Return-Path. Cela dépend des plateformes. Salesforce (désactiver le traitement des rebonds), HubSpot et Marketo proposent des options d’envelope-from personnalisables.
• Utilisez l’alignement relaxed par défaut. Avec aspf=r et adkim=r (par défaut dans DMARC), les sous-domaines sont considérés comme alignés. Si votre plateforme envoie en Return-Path bounce.yourdomain.com et que votre From est yourdomain.com, l’alignement passe.

Le diagnostic est simple : regardez vos rapports d’agrégat DMARC. On y retrouve les résultats d’authentification (succès/échec) associés à l’alignement SPF/DKIM. Si vous voyez success mais échec d’alignement, vous ciblez tout de suite le protocole et l’expéditeur à corriger.

Red Sift OnDMARC présente le tout par expéditeur, indiquant les cas où l’authentification passe mais l’alignement échoue, avec le détail des domaines non alignés. Vérifiez immédiatement votre situation avec Red Sift Investigate.

Pour tout dépannage, l’en-tête Authentication-Results d’un email reçu donne le détail du processus. Voici ce qu’il faut repérer :

Pour un suivi continu au-delà des vérifications email individuelles, les rapports agrégés DMARC vous offrent une vue d’ensemble de toutes les sources d’envoi. Red Sift OnDMARC transforme les rapports XML bruts en tableaux de bord exploitables, et notre guide des meilleures solutions d’authentification email présente d’autres ressources pour chaque étape de la mise en œuvre.

Les échecs DKIM et DMARC suivent des schémas prévisibles. Incohérences du hash du corps, enregistrements DNS manquants, lacunes dans la rotation des clés, incohérences d’alignement, politiques bloquées et l’écart d’alignement entre l’authentification réussie et le passage DMARC. Chacun peut être diagnostiqué via les en-têtes d’email et les rapports DMARC, et chacun peut être corrigé.

Le plus grand risque n’est pas la complexité. C’est l’inaction. Un enregistrement DMARC en p=none vous donne de la visibilité mais zéro protection. Chaque jour où votre domaine reste en p=none est un jour de plus où des attaquants peuvent se faire passer pour vous sans conséquence.

[1] Mise à jour sur les exigences pour les expéditeurs en masse – Google

[2] Renforcer l’écosystème email – Microsoft Community Hub

[3] Échec DKIM : comment corriger les erreurs d’alignement et de vérification – DMARCguard

[4] Flattening SPF : le problème caché de l’infrastructure email – AutoSPF

[5] Rapport annuel IC3 2025

[6] PCI DSS v4.0.1 Résumé des modifications

[7] RFC 6376 – DomainKeys Identified Mail (DKIM) Signatures