GuidesAuthentification

DMARC échoue alors que SPF et DKIM passent

Les deux contrôles disent pass, et DMARC dit quand même fail. La cause est un domaine qui ne correspond pas à votre adresse d’expéditeur (From). Un email de test montre lequel, et la correction est un réglage chez celui qui envoie les emails.

Mis à jour le 5 octobre 20269 min de lecture

En bref

DMARC ne passe que si SPF ou DKIM passe pour le domaine de votre adresse d’expéditeur (From). Un pass pour le domaine de votre fournisseur ne compte pas.
Ouvrez un message envoyé dans Gmail avec Show original (« Afficher l’original ») et comparez smtp.mailfrom, header.i et header.from dans l’en-tête Authentication-Results.
Corrigez d’abord DKIM : activez la signature avec votre propre domaine dans chaque service qui envoie pour vous. Une signature DKIM survit au transfert, SPF non.
Par défaut, un sous-domaine est assez proche. Si votre enregistrement DMARC contient adkim=s ou aspf=s, il ne l’est pas.
La chauffe ne répare pas l’alignement. Les emails de chauffe partent de votre boîte mail et échouent avec elle.

DMARC ne demande pas si SPF et DKIM passent. Il demande si l’un des deux passe pour le domaine de votre adresse d’expéditeur (From). Si SPF passe pour le domaine de rebond de votre fournisseur et DKIM pour le domaine de signature de votre fournisseur, les deux lignes disent « pass » et DMARC dit quand même « fail ». La correction se fait chez celui qui envoie : faites-le signer avec votre domaine, ou utilisez une adresse de rebond sur votre domaine. L’un des deux suffit.

Cette correspondance s’appelle l’alignement. C’est la partie de DMARC qu’un vérificateur DNS ne peut pas voir. Que vos emails soient alignés ou non n’apparaît que dans un message réellement envoyé. Cette page montre comment en lire un.

Trois domaines voyagent avec chaque email

Un email porte votre domaine à trois endroits au plus. Chaque contrôle en regarde un différent.

Un fanion bleu marine avec un emblème d’enveloppe, un sac de courrier avec une étiquette en laiton et une lettre avec un sceau de cire, côte à côte sur un quai ; le sceau reprend l’emblème du fanion, l’étiquette non — Le fanion est la ligne From, l’étiquette du sac de courrier est le Return-Path, le sceau de cire est la signature DKIM. DMARC veut que l’étiquette ou le sceau corresponde au fanion.

Où	Aussi appelé	Qui le regarde
La ligne From que voit votre lecteur	Header From, `header.from`	DMARC. C’est l’étalon pour les deux autres.
Le Return-Path	Expéditeur d’enveloppe, MAIL FROM, adresse de rebond, `smtp.mailfrom`	SPF. Il vérifie si le serveur d’envoi a le droit d’utiliser ce domaine.
La valeur `d=` de l’en-tête DKIM-Signature	Domaine de signature, `header.d` ou `header.i`	DKIM. Il vérifie si la signature de ce domaine est valide.

SPF (RFC 7208) et DKIM (RFC 6376) répondent chacun à une question étroite, et aucune de ces questions ne mentionne votre ligne From. Un service de newsletters peut passer SPF pour son propre domaine de rebond et signer avec sa propre clé, et le message peut quand même prétendre venir de vous. DMARC comble cette faille. La RFC 9989, la norme DMARC depuis mai 2026, n’accepte un résultat que si le domaine qui le porte correspond au domaine From, et en donne la raison pour DKIM en une phrase :

DMARC exige que l’alignement des identifiants s’applique à l’identifiant authentifié par DKIM, car un message peut porter une signature valide de n’importe quel domaine, même d’un domaine utilisé par un acteur malveillant.

Il en va de même pour SPF, puisque n’importe qui peut publier un enregistrement SPF pour un domaine qu’il possède. La règle est donc : DMARC passe si SPF passe et que son domaine est aligné, ou si DKIM passe et que son domaine est aligné.

Trouvez l’écart dans un vrai message

Il vous faut un email envoyé de la même façon que vos vrais emails, et une adresse Gmail pour le recevoir.

Envoyez un message depuis la boîte mail ou l’outil concerné à une adresse Gmail que vous pouvez ouvrir.
Ouvrez-le dans Gmail sur un ordinateur. À côté de Répondre, cliquez sur More (« Plus »), puis sur Show original (« Afficher l’original »). Google décrit les mêmes étapes dans Trace an email with its full header.
Trouvez l’en-tête Authentication-Results, dans lequel le serveur destinataire note le résultat de ses contrôles (RFC 8601). Comparez trois valeurs : le domaine après smtp.mailfrom=, le domaine après header.i=@ (certains destinataires écrivent header.d=) et le domaine après header.from=. Comment lire les en-têtes d’un email parcourt cette ligne pas à pas.

Voici le schéma d’un message qui passe SPF et DKIM et échoue à DMARC. L’en-tête est abrégé et utilise des domaines d’exemple :

From: anna@example.com
Return-Path: <bounces@send.vendor-mail.example>

Authentication-Results: mx.google.com;
       dkim=pass header.i=@vendor-mail.example header.s=s1;
       spf=pass smtp.mailfrom=bounces@send.vendor-mail.example;
       dmarc=fail header.from=example.com

Lisez-le en partant du bas. Le domaine From est example.com. SPF passe, mais pour send.vendor-mail.example. DKIM passe, mais la signature appartient à vendor-mail.example. Aucun des deux n’est example.com : rien ne se porte donc garant du nom dans la ligne From.

Une fois le service configuré pour signer avec votre domaine, le même message ressemble à ceci :

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=s1;
       spf=pass smtp.mailfrom=bounces@send.vendor-mail.example;
       dmarc=pass header.from=example.com

SPF pointe toujours vers le prestataire. Ce n’est pas un problème. DKIM correspond désormais, et un seul pass aligné suffit à DMARC.

À quel point faut-il que ce soit proche : souple et strict

Les deux domaines n’ont pas besoin d’être identiques. Par défaut, l’alignement est souple (« relaxed ») : il suffit que les deux relèvent du même domaine enregistré, que la norme appelle le domaine organisationnel. L’alignement strict exige une correspondance exacte. Vous choisissez avec les balises adkim pour DKIM et aspf pour SPF dans votre enregistrement DMARC.

SPF ou DKIM passe pour	Domaine From	Souple (par défaut)	Strict
`example.com`	`example.com`	Aligné	Aligné
`mail.example.com`	`example.com`	Aligné	Non aligné
`example.com`	`news.example.com`	Aligné	Non aligné
`vendor-mail.example`	`example.com`	Non aligné	Non aligné

La norme note que « presque tous les propriétaires de domaine ont trouvé l’alignement souple suffisant pour leurs besoins ». Vérifiez tout de même votre propre enregistrement. L’exemple d’enregistrement en haut de la page Set up DMARC de Google se termine par adkim=s; aspf=s : un enregistrement copié de là est donc strict. Si le vôtre contient ces deux balises et qu’un outil envoie depuis un sous-domaine, retirez-les. Google lui-même avertit sur cette page que l’alignement strict « peut entraîner le rejet ou l’envoi en spam des messages provenant de sous-domaines associés ».

D’où vient en général l’écart

Un service qui envoie depuis ses propres serveurs

Les plateformes de newsletters, les CRM, les outils de facturation et les services d’assistance envoient vos emails depuis leur infrastructure. Tant que vous n’avez pas connecté votre domaine, ils utilisent en général une adresse de rebond sur leur domaine et signent avec leur propre clé. La documentation d’Amazon dit clairement pourquoi l’alignement SPF est rare ici : le Return-Path « sert aux rebonds et aux plaintes que le fournisseur (SES) suit au moyen d’une adresse qui lui appartient » (Amazon SES). Le réglage qui corrige cela porte un nom différent dans chaque service, et il aboutit à quelques enregistrements DNS de votre côté.

Service	Avant de connecter votre domaine	Le réglage à chercher
Twilio SendGrid	Les emails sont affichés comme envoyés « via sendgrid.net ».	Domain authentication : des enregistrements CNAME pour un sous-domaine de rebond et deux clés DKIM.
Amazon SES	Le Return-Path est un sous-domaine de `amazonses.com`.	Easy DKIM pour la signature, et un domaine MAIL FROM personnalisé pour SPF.
Mailchimp	Le domaine est vérifié mais pas authentifié.	Email domain authentication : deux enregistrements CNAME pour DKIM.

Ce sont les descriptions des éditeurs eux-mêmes, en octobre 2026. Les autres services fonctionnent sur le même principe. Cherchez dans leur aide « authenticate domain », « custom DKIM » ou « branded sending domain ».

Votre fournisseur de messagerie signe avec son propre domaine, ou pas du tout

Avec une boîte mail sur votre propre domaine, le Return-Path est normalement votre propre adresse : SPF est donc aligné dès que votre enregistrement SPF mentionne le fournisseur. La valeur après smtp.mailfrom= vous le dit. C’est DKIM qui demande d’actionner un interrupteur.

Google Workspace. Tant que vous n’avez pas activé DKIM pour votre domaine, Google signe avec l’un de ses propres domaines. Une version antérieure de la page d’aide de Google indiquait que Gmail signe alors « avec cette clé de domaine DKIM par défaut : d=*.gappssmtp.com ». La page actuelle ne nomme plus le domaine : vérifiez donc votre propre en-tête. Un header.i qui se termine par gappssmtp.com signifie que votre clé n’est pas active. Générez-la dans la console d’administration sous Apps, Google Workspace, Gmail, Authenticate email (authentifier les emails), ajoutez l’enregistrement TXT qu’elle vous affiche, puis cliquez sur Start authentication (démarrer l’authentification) (Set up DKIM).
Microsoft 365. La documentation de Microsoft, mise à jour en août 2026, indique : « Actuellement, aucune signature DKIM n’est appliquée aux emails sortants des domaines personnalisés ». Vous publiez deux enregistrements CNAME et activez la signature dans le portail Defender (How to use DKIM for email in your custom domain).

L’enregistrement que vous ajoutez pour une clé DKIM se place toujours sous _domainkey, sous un nom choisi par le fournisseur. Pour Google Workspace, il ressemble à ceci, avec la clé abrégée :

google._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Un outil qui se connecte à votre boîte mail et envoie par elle n’ajoute aucune signature propre. Les emails d’un tel outil ressemblent exactement à ceux que vous écrivez à la main : la correction se fait donc chez le fournisseur de messagerie et non dans l’outil.

Le message a été transféré

Quand un destinataire transfère automatiquement vos emails, ils arrivent depuis un serveur que votre enregistrement SPF ne mentionne pas. SPF échoue, ou passe pour le domaine de celui qui transfère. Une signature DKIM survit au trajet tant que personne ne modifie le message. Les listes de diffusion qui ajoutent un pied de page ou une mention dans l’objet cassent aussi la signature. Vous ne pouvez pas réparer cela de votre côté. La FAQ de Google pour les expéditeurs dit que, pour Gmail, « l’alignement DMARC n’est pas exigé pour les messages transférés ou issus de listes de diffusion ». C’est la raison d’avoir un DKIM aligné et de ne pas compter sur SPF seul.

Une lettre scellée passe d’un bateau postal à un autre ; chaque bateau a son propre sac de courrier et sa propre étiquette, et le sceau de cire de la lettre est intact — Le transfert change le sac de courrier et son étiquette. Le sceau de la lettre reste intact.

Ce ne sont pas vos emails

Si vos rapports DMARC montrent des échecs depuis des serveurs que vous n’avez jamais utilisés, quelqu’un envoie peut-être avec votre adresse. Ces messages sont censés échouer. Il n’y a rien à corriger, et ils sont l’argument en faveur d’une politique plus stricte par la suite.

Corrigez d’abord DKIM, puis SPF

L’un ou l’autre vous donne un pass. DKIM est le meilleur des deux à avoir, parce qu’il voyage avec le message. Les bonnes pratiques du M3AAWG en font une règle : « Signez tous les emails sortants avec une clé DKIM alignée sur le domaine de l’en-tête RFC5322.From. » La RFC 9989 recommande d’utiliser les deux.

Dressez la liste de tout ce qui envoie au nom de votre domaine. Les boîtes mail, l’outil de newsletters, le CRM, les factures, le formulaire de contact de votre site. Vos rapports DMARC nomment ceux que vous avez oubliés.
Testez chacun d’eux avec le contrôle d’en-tête ci-dessus et notez lequel des deux domaines n’est pas le vôtre.
Activez la signature avec votre domaine partout où header.i affiche un autre nom, et publiez les enregistrements que le service vous donne. Choisissez une clé de 2048 bits si votre hébergeur DNS l’accepte. Gmail exige au moins 1024 bits et recommande 2048.
Définissez un domaine de rebond personnalisé là où le service en propose un, sur un sous-domaine comme bounce.example.com. Cela aligne aussi SPF.
Renvoyez le test et cherchez dmarc=pass. Les modifications DNS peuvent prendre un moment. Google prévoit jusqu’à 48 heures pour qu’une nouvelle clé DKIM commence à fonctionner.

Ce qui ne marche pas, c’est d’ajouter le prestataire à vos propres enregistrements. Un include: pour le prestataire dans votre enregistrement SPF ne change rien si le Return-Path est sur le domaine du prestataire, car SPF consulte l’enregistrement de ce domaine-là et non le vôtre. Un enregistrement DMARC ne peut pas non plus énumérer des tiers de confiance. La norme dit qu’il n’existe « aucun mécanisme généralement accepté » pour cela.

Si l’en-tête affiche dmarc=pass et que le message arrive quand même en spam, l’authentification n’est plus la cause. SPF, DKIM et DMARC passent, mais l’email arrive quand même en spam prend le relais.

Ce que coûte un DMARC en échec tant que votre politique est p=none

Avec p=none, vous demandez aux destinataires de ne rien faire en cas d’échec : rien n’est donc rejeté à cause de votre politique. Cela joue quand même contre vous de deux façons.

Les règles pour les gros expéditeurs. Gmail, Yahoo et Outlook.com exigent des emails alignés de la part des gros expéditeurs, ce qui, pour Gmail et Outlook.com, veut dire à partir de 5 000 messages par jour. La FAQ de Google pour les expéditeurs mentionne l’erreur temporaire 4.7.32 pour les emails dont l’en-tête From « n’est aligné ni sur le domaine organisationnel SPF authentifié ni sur celui de DKIM », et cite comme conséquence « des codes d’échec temporaire ou permanent, ou un classement en spam ».
Cela bloque l’étape suivante. Dès que vous passez à p=quarantine ou p=reject, chacun de vos propres messages non alignés doit être traité comme spam ou refusé. Chez Gmail, le message de rejet dit « Unauthenticated email from domain-name is not accepted due to domain's DMARC policy » (un email non authentifié de domain-name n’est pas accepté en raison de la politique DMARC du domaine), erreur 5.7.26 (Troubleshoot DMARC issues).

Si vous n’avez aucun enregistrement DMARC, commencez par l’enregistrement à ajouter. Il active aussi les rapports qui montrent l’alignement pour tous vos expéditeurs à la fois.

Ce que la chauffe peut faire ici, et ce qu’elle ne peut pas

Une chauffe ne répare pas l’alignement. WarmupBay se connecte à votre boîte mail et envoie depuis celle-ci : ses emails de chauffe sont donc envoyés et signés par votre fournisseur exactement comme les emails que vous écrivez vous-même. Si votre boîte mail échoue à DMARC, ils échouent avec elle. Corrigez d’abord les enregistrements.

WarmupBay aide pour ce qui vient avant et pour ce qui vient après. Quand vous connectez une boîte mail, il vérifie SPF, DKIM et DMARC pour le domaine, et il arrête la chauffe s’ils manquent toujours au bout de 72 heures. Une fois qu’ils sont en place, votre boîte mail échange quelques emails par jour avec d’autres dans un réseau partagé, et le tableau de bord montre où ils sont arrivés : boîte de réception, onglet Gmail ou spam, séparément pour Google et pour les autres fournisseurs. Il ne teste pas les emails de votre outil de newsletters ou de votre CRM, car ils ne passent jamais par votre boîte mail, et il ne peut pas encore connecter les boîtes mail Microsoft 365 ou Outlook.com. Il est gratuit pour 10 emails de chauffe par jour. Connectez votre boîte mail quand l’en-tête affiche dmarc=pass.

Questions fréquentes

SPF passe et est aligné, DKIM n’est pas aligné. Est-ce suffisant ?

Pour DMARC, oui. Un seul pass aligné suffit. Cela ne suffit plus quand un destinataire transfère vos emails, car SPF ne correspond alors plus. Google écrit aussi dans sa FAQ pour les expéditeurs que l’alignement avec SPF et DKIM à la fois deviendra probablement une exigence : configurez donc DKIM pour votre domaine de toute façon.

Pourquoi DMARC échoue-t-il pour certains destinataires et passe-t-il pour d’autres ?

Parce que les emails leur parviennent par des chemins différents ou depuis des expéditeurs différents. Un destinataire qui transfère vers une autre boîte mail, ou une liste de diffusion, modifie ce que voient SPF et parfois DKIM. Il peut aussi s’agir de l’un de vos services d’envoi qui n’est pas encore configuré. Les rapports agrégés présentent les résultats par serveur d’envoi et montrent de quel cas il s’agit.

L’adresse Reply-To joue-t-elle un rôle dans DMARC ?

Non. DMARC n’utilise que le domaine de l’en-tête From. L’adresse Reply-To, le nom d’expéditeur et l’en-tête Sender ne font pas partie du contrôle.

Comment voir les problèmes d’alignement sans ouvrir les en-têtes ?

Dans les rapports agrégés DMARC. Chaque enregistrement comporte un bloc policy_evaluated avec un résultat dkim et un résultat spf, qui sont les résultats après le test d’alignement. Le bloc auth_results, en dessous, montre les résultats bruts et les domaines concernés. Un pass brut à côté d’un fail évalué, c’est exactement le cas traité sur cette page. Vous recevez ces rapports en ajoutant une adresse rua à votre enregistrement DMARC.

L’en-tête indique dkim=fail ou dkim=neutral. Est-ce le même problème ?

Non. Dans ce cas, c’est la signature elle-même qui n’a pas été validée, ce qui est une autre panne. Si le texte dit body hash did not verify, la page de dépannage de Google en nomme la cause : le message a été modifié après sa signature, par exemple par une passerelle qui ajoute un pied de page. L’alignement concerne une signature valide, mais qui appartient à un autre domaine.

Me faut-il une clé DKIM distincte pour chaque service qui envoie pour moi ?

En pratique, oui. Chaque service signe avec sa propre clé et la publie sous son propre nom de sélecteur, sous _domainkey de votre domaine : plusieurs clés cohabitent donc sans conflit. C’est différent de SPF, où un domaine ne peut avoir qu’un seul enregistrement.