DMARC échoue alors que SPF et DKIM passent ? Le correctif d'alignement (2026)

Publié 2026-07-08

Chiffres au 2026-06-29 · méthodologie v7. Données de recensement agrégées sur 261 millions de domaines évalués. Voir comment nous notons.

DMARC exige plus qu’un pass — le domaine qui a passé SPF ou DKIM doit correspondre à votre domaine From. La plupart du courrier « SPF pass, DMARC fail » a passé SPF sur le domaine de rebond du fournisseur, pas sur le vôtre. Seuls 7,4 % des 261 086 232 domaines évalués passent SPF avec alignement sous une politique DMARC appliquée, selon le recensement Defaults.Exposed (2026-06-29).

Le correctif est plus rapide que la confusion ne le laisse croire. Lisez l’en-tête Authentication-Results pour voir quelle jambe — SPF ou DKIM — passe sur le mauvais domaine ; puis activez soit la signature DKIM en domaine personnalisé de votre service d’envoi (généralement quelques CNAME, et le correctif qui survit au transfert), soit son return-path personnalisé pour que SPF passe sur votre domaine. Une seule jambe alignée suffit à DMARC.

Comment DMARC peut-il échouer quand SPF et DKIM passent tous les deux ?

Parce que DMARC ne demande jamais « SPF a-t-il passé ? ». Il demande : SPF ou DKIM a-t-il passé pour un domaine qui correspond à l’adresse From que voit votre destinataire ? Cette condition supplémentaire s’appelle l’alignement, et c’est toute la raison d’être de DMARC — sans elle, n’importe qui pourrait passer SPF sur un domaine qu’il possède tout en affichant le vôtre dans l’en-tête From.

Chaque vérification authentifie un domaine différent :

Vérification	Domaine réellement évalué	Où le voir
SPF	Le Return-Path (RFC5321.MailFrom, l’adresse de rebond/enveloppe expéditeur) — pas l’en-tête From	`smtp.mailfrom=` dans Authentication-Results
DKIM	Le domaine du tag `d=` de la signature — celui que le signataire a choisi	`header.d=` dans Authentication-Results
DMARC	Le domaine de votre en-tête From — et il exige que le domaine de SPF ou le `d=` de DKIM lui corresponde	`header.from=` dans Authentication-Results

Voici comment les pièces déraillent habituellement : votre plateforme de newsletter ou votre CRM envoie avec un Return-Path du type [email protected], SPF est vérifié contre vendor.com et passe, DKIM passe avec d=vendor.com — et DMARC échoue, parce qu’aucun des deux domaines qui passent ne correspond à yourcompany.com. Chaque vérification a dit la vérité ; aucune ne vous a authentifié, vous. Modifier votre propre enregistrement SPF ne peut pas corriger cela — il n’a jamais été consulté. C’est le même piège que dans SPF échoue pour vos outils SaaS.

Le recensement montre combien peu d’expéditeurs achèvent cette dernière étape : 27 640 987 des 261 086 232 domaines évalués (10,59 %) ont ne serait-ce qu’une politique DMARC appliquée, et seuls 7,4 % passent SPF avec alignement sous une telle politique. Parmi les 77,5 millions de domaines dont le SPF se termine en softfail (~all), seuls 9,2 % sont sous une politique DMARC appliquée ; parmi les éditeurs de hardfail (-all), 12 142 351 sont sous application tandis que 42 514 532 ne le sont pas. La plupart des domaines s’arrêtent à « SPF passe » — ce qui, sans DMARC pour agir dessus, ne protège presque rien.

Comment lire Authentication-Results pour voir quelle jambe n’est pas alignée ?

Envoyez-vous un message via le service en échec, ouvrez la source brute, et trouvez l’en-tête Authentication-Results. Un résultat non aligné typique ressemble à ceci :

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=bounces.espmail.net;
       dkim=pass header.d=espmail.net;
       dmarc=fail (p=NONE) header.from=yourcompany.com

Lisez-le en trois comparaisons :

Jambe SPF : smtp.mailfrom= se termine-t-il par votre domaine ? Ici c’est bounces.espmail.net — non aligné.
Jambe DKIM : header.d= se termine-t-il par votre domaine ? Ici c’est espmail.net — non aligné.
Verdict DMARC : header.from= est le domaine que DMARC défend. Aucune jambe ne lui a correspondu, donc dmarc=fail — alors même que les deux vérifications individuelles disent pass.

La jambe à corriger est celle qui implique déjà votre propre domaine (ou peut être amenée à le faire). Il n’en faut qu’une.

Quelle est la différence entre alignement relaxed et strict ?

DMARC offre deux modes de correspondance, réglés par les tags aspf (SPF) et adkim (DKIM) de votre enregistrement DMARC :

Relaxed (r, le défaut) : les deux domaines doivent partager le même domaine organisationnel — le domaine enregistrable selon la Public Suffix List. bounce.yourcompany.com s’aligne avec yourcompany.com ; de même qu’un DKIM d=mail.yourcompany.com. C’est pourquoi les return-paths personnalisés et le DKIM personnalisé des fournisseurs, qui vivent sur des sous-domaines, fonctionnent.
Strict (s) : les domaines doivent correspondre exactement, caractère pour caractère. bounce.yourcompany.com ne s’aligne plus avec yourcompany.com.

Si votre enregistrement ne mentionne ni aspf ni adkim, vous êtes en mode relaxed — et vous voulez presque certainement y rester. Le mode strict n’ajoute aucune sécurité significative pour la plupart des expéditeurs et casse silencieusement chaque expéditeur légitime en sous-domaine que vous mettez en place. Si DMARC échoue et que votre enregistrement contient aspf=s ou adkim=s, cela peut être le bug à lui seul.

Comment corriger l’alignement DMARC ?

Lancez le scan gratuit sur defaults.exposed avant de toucher au DNS. Il montre votre enregistrement DMARC et votre politique, si vos SPF et DKIM sont configurés pour s’aligner, et ce qui est cassé par ailleurs — pour corriger la bonne jambe en premier.
Testez chaque service d’envoi et lisez son Authentication-Results (comme ci-dessus). Listez chaque source — fournisseur de messagerie, outil de newsletter, CRM, application de facturation — et notez pour chacune si smtp.mailfrom et header.d sont votre domaine ou celui du fournisseur.
Activez la signature DKIM en domaine personnalisé pour chaque fournisseur — le correctif qui dure. Tout service d’envoi sérieux propose une « authentification de domaine » : quelques enregistrements CNAME qui lui permettent de signer en d=yourcompany.com (ou un sous-domaine, qui s’aligne en mode relaxed). Le DKIM aligné est généralement le correctif le plus simple et le seul qui survive au transfert, parce que le transfert casse SPF par conception.
Pour l’alignement SPF, activez le return-path personnalisé du fournisseur (souvent appelé domaine de rebond personnalisé) — typiquement un CNAME tel que bounce.yourcompany.com pointant vers le fournisseur. SPF passe alors sur votre domaine organisationnel et s’aligne. Faites-le là où c’est proposé, mais traitez-le comme la seconde jambe, pas comme un substitut au DKIM aligné.
Laissez l’alignement en mode relaxed sauf raison spécifique et comprise d’utiliser aspf=s/adkim=s.
Relancez le scan, confirmez les deux jambes, puis avancez vers l’application. Une politique DMARC en p=none rapporte mais ne bloque rien ; une fois vos vrais expéditeurs alignés, le chemin complet vers une politique qui vous protège est sur la page corriger DMARC, et les guides par prestataire comme DMARC chez IONOS couvrent les clics dans le panneau DNS.

Dois-je corriger l’alignement SPF ou l’alignement DKIM ?

Il vous faut une jambe alignée par source d’envoi. Si vous ne pouvez en faire qu’une, le choix n’est pas serré :

Correctif	Ce que cela implique	Survit au transfert ?
DKIM aligné (signature en domaine personnalisé)	Quelques CNAME dans le panneau « authentification de domaine » du fournisseur	Oui — la signature voyage avec le message
SPF aligné (return-path/domaine de rebond personnalisé)	Un CNAME, là où le fournisseur le propose	Non — l’IP de tout serveur de transfert remplace celle du fournisseur

Le cas particulier à connaître : Google Workspace et Microsoft 365 signent votre courrier en DKIM par défaut avec leurs propres domaines de repli (gappssmtp.com, onmicrosoft.com) — DKIM affiche donc pass tandis que DMARC échoue quand même. C’est l’instance spécifique la plus courante de tout ce problème, et elle a son propre guide : DKIM passe mais DMARC échoue encore : le piège de la signature par défaut.

Questions fréquentes

SPF et DKIM doivent-ils tous les deux s’aligner pour que DMARC passe ? Non — un seul pass aligné suffit. La bonne pratique est d’aligner les deux malgré tout, pour que, quand le transfert casse la jambe SPF, la jambe DKIM porte encore le pass DMARC. Sur les 261 086 232 domaines évalués dans le recensement du 2026-06-29, seuls 3,87 % complètent la triade SPF + DMARC + DKIM.

Le tableau de bord de mon ESP dit que SPF et DKIM sont « vérifiés » — pourquoi DMARC échoue-t-il encore ? « Vérifié » signifie généralement que l’envoi propre du fournisseur passe sur les domaines du fournisseur. Tant que vous n’avez pas complété ses étapes de domaine personnalisé (CNAME DKIM, return-path personnalisé), le courrier s’authentifie comme le fournisseur, pas comme vous — et DMARC compare avec votre domaine From.

Un enregistrement SPF strict en -all suffit-il sans alignement ? Non. Un qualificateur strict renforce le verdict de SPF sur le domaine du Return-Path, mais DMARC exige toujours que ce domaine soit le vôtre. Au recensement du 2026-06-29, seuls 12 142 351 des domaines publiant -all sont sous une politique DMARC appliquée — les 42 514 532 autres ont un enregistrement strict sur lequel aucune politique n’agit.

Dois-je passer en alignement strict (aspf=s/adkim=s) pour plus de sécurité ? Presque jamais. L’alignement relaxed exige déjà le même domaine enregistrable, qu’un usurpateur ne contrôle pas. Le mode strict casse surtout vos propres expéditeurs en sous-domaine — vérifiez sa présence chaque fois que l’alignement échoue de façon inattendue.

DMARC n’échoue que sur le courrier que les destinataires transfèrent — même correctif ? C’est la jambe SPF qui meurt en transit : le serveur du transféreur n’est dans l’enregistrement SPF de personne pour votre return-path. Vous ne pouvez pas corriger SPF pour le courrier transféré ; le DKIM aligné est la réponse, puisque la signature survit intacte au transfert. Détails dans le courrier transféré échoue à SPF.

Envoyez le rapport au propriétaire

Si vous corrigez cela pour un client ou votre employeur, bouclez la boucle avec une preuve. Relancez le scan gratuit une fois les CNAME en place et transmettez le rapport noté au chef d’entreprise : daté, en langage clair, montrant SPF, DKIM et DMARC alignés et passants. C’est la pièce dont il aura besoin pour le renouvellement de la cyberassurance et le prochain questionnaire de sécurité fournisseurs — la preuve d’une configuration qui fonctionne, pas seulement « j’ai ajouté des enregistrements DNS ».

Vérifiez votre domaine → · DKIM passe mais DMARC échoue encore → · Corriger DMARC → · Comment nous notons → · Données agrégées uniquement. Données stockées et traitées dans l’UE.