SPF, DKIM et DMARC expliqués : le guide complet d'authentification des e-mails [2026]

L'e-mail pose un problème de confiance. Il n'existe aucun moyen intégré de prouver qu'un message provient réellement du domaine qu'il prétend représenter, c'est pourquoi quelqu'un peut envoyer un e-mail qui semble provenir de votre patron, de votre banque ou de votre entreprise avec peu plus qu'une configuration de quelques minutes.

SPF, DKIM et DMARC sont les trois enregistrements DNS qui règlent ce problème. Ensemble, ils indiquent aux serveurs de messagerie destinataires quels serveurs sont autorisés à envoyer pour votre domaine, si chaque message a été falsifié pendant le transit et quoi faire lorsque l'une de ces vérifications échoue.

Ce guide explique ce que fait chacun, comment ils fonctionnent ensemble, l'ordre de configuration et comment les tester. Depuis 2026, les trois sont obligatoires pour toute entreprise qui envoie des e-mails. Gmail, Yahoo et Microsoft l'imposent directement, et le fait de sauter l'un d'eux nuit à votre placement dans la boîte de réception.

Réponses rapides

• Qu'est-ce que SPF, DKIM et DMARC ? Trois enregistrements DNS qui fonctionnent ensemble pour vérifier que vos e-mails proviennent bien de vous. SPF autorise les serveurs qui peuvent envoyer pour votre domaine, DKIM ajoute une signature cryptographique prouvant que le message n'a pas été modifié, et DMARC indique aux destinataires quoi faire lorsque SPF ou DKIM échoue.
• Avez-vous besoin des trois ? Oui. Chacun corrige ce que les autres manquent, et depuis février 2024, Gmail et Yahoo les exigent pour les expéditeurs de 5 000 e-mails par jour et plus.
• Dans quel ordre les configurer ? SPF d'abord, puis DKIM, puis DMARC, avec une vérification entre chaque étape.
• Vérifiez les vôtres maintenant : Utilisez l'outil de vérification gratuit sur cette page pour tester les trois enregistrements de votre domaine.

SPF, DKIM et DMARC : Authentification des e-mails expliquée

Les trois enregistrements sont des vérifications indépendantes qui se combinent en une seule politique. Une fois en place, vous n'avez plus à deviner pourquoi une réinitialisation de mot de passe n'est jamais arrivée ou pourquoi un e-mail transactionnel est allé dans le spam.

Qu'est-ce que SPF, DKIM et DMARC ?

SPF, DKIM et DMARC sont trois enregistrements DNS qui authentifient les e-mails provenant de votre domaine.

• SPF (Sender Policy Framework) liste tous les serveurs autorisés à envoyer des e-mails pour votre domaine.
• DKIM (DomainKeys Identified Mail) ajoute une signature cryptographique à chaque message afin que les destinataires puissent confirmer que le contenu n'a pas été modifié pendant le transit.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance) indique aux destinataires quoi faire lorsque SPF ou DKIM échoue, et lie les deux vérifications à l'adresse visible From:.

Chacun corrige une lacune différente. SPF empêche les serveurs non autorisés de revendiquer votre domaine, DKIM empêche quiconque de modifier vos messages en cours de transmission, et DMARC empêche les attaquants de passer SPF ou DKIM avec un domaine différent tout en usurpant le vôtre dans la ligne From: visible.

Comparaison rapide

	SPF	DKIM	DMARC
Ce qu’elle fait	Liste les serveurs autorisés à envoyer des e-mails pour votre domaine	Signe chaque e-mail afin que les destinataires puissent confirmer qu'il n'a pas été modifié	Indique aux destinataires quoi faire lorsque SPF ou DKIM échoue
Comment ça marche	Le destinataire compare l'adresse IP d'envoi à une liste dans votre DNS	Le destinataire vérifie une signature cryptographique par rapport à votre clé publique	Le destinataire applique votre politique (livrer, spam ou rejeter) aux e-mails échoués
Ce qu'il ne fait pas	Ne vérifie pas l'adresse From: visible, échoue lors du transfert	Ne dit pas quels serveurs peuvent envoyer, peut échouer si les relais modifient les e-mails	N'authentifie rien par lui-même, repose sur SPF et DKIM
Où il se trouve dans le DNS	Enregistrement TXT à votre domaine apex	Enregistrement TXT à [sélecteur]._domainkey.votredomaine.com	Enregistrement TXT à _dmarc.votredomaine.com
Obligatoire en 2026 ?	Oui	Oui	Oui

Lorsqu'un e-mail arrive chez Gmail, Outlook ou toute autre boîte de réception, trois vérifications se produisent l'une après l'autre. Le destinataire recherche votre enregistrement SPF et compare l'IP d'envoi à la liste. Le destinataire vérifie la signature DKIM par rapport à la clé publique de votre DNS. Ensuite, le destinataire lit votre politique DMARC et décide quoi faire du résultat.

Qu'est-ce que SPF ?

SPF est un enregistrement TXT dans votre DNS qui répertorie tous les serveurs et services autorisés à envoyer des e-mails au nom de votre domaine. C'est la première ligne de défense contre l'usurpation de domaine.

Un enregistrement SPF de base ressemble à ceci :

v=spf1 include:sendlayer.net ~all

Les parties :

• v=spf1 déclare qu'il s'agit d'un enregistrement SPF.
• include:sendlayer.net autorise un service d'envoi, ici SendLayer. Chaque outil d'envoi a sa propre directive include:.
• ~all est la règle générale pour tout ce qui ne correspond pas. Le tilde signifie « échec léger », ce qui autorise l'e-mail mais le signale. Utilisez -all pour un « échec strict » (rejet) une fois que vous êtes sûr que votre enregistrement couvre tous les expéditeurs légitimes.

Lorsqu'un e-mail arrive, le serveur de réception prend l'adresse IP d'où il provient et vérifie si cette adresse IP est autorisée par votre enregistrement SPF. Si oui, SPF réussit. Sinon, SPF échoue.

Ce que SPF ne peut pas faire

SPF a deux limitations bien connues. Il ne fonctionne pas avec le transfert d'e-mails. Lorsque quelqu'un transfère votre e-mail, le serveur de transfert utilise sa propre adresse IP, qui ne figure pas dans votre enregistrement SPF, donc SPF échoue même si l'original était légitime. Il ne vérifie que l'adresse de retour (return-path), pas l'adresse visible From:. Un attaquant peut réussir SPF avec un domaine qu'il contrôle tout en faisant ressembler la ligne From: à la vôtre. C'est pourquoi l'alignement DMARC est important (plus à ce sujet ci-dessous).

La limite de 10 recherches DNS

Les enregistrements SPF sont limités à 10 recherches DNS au total (RFC 7208). Chaque directive include:, a, mx, ptr et exists: compte pour la limite. Ajoutez trop de services d'envoi et vous atteindrez une PERMERROR, auquel cas toute authentification échouera silencieusement.

La plupart des domaines atteignent cette limite lorsqu'ils cumulent plusieurs outils marketing, CRM, services transactionnels et helpdesks. Si vous êtes proche de la limite, suivez notre guide sur comment fusionner plusieurs enregistrements SPF en un seul enregistrement aplati.

Et notez que vous ne pouvez avoir qu'un seul enregistrement SPF par domaine. Si vous essayez d'en ajouter un second, RFC 7208 stipule que les destinataires doivent considérer l'ensemble comme invalide, le même effet que s'il n'y avait pas d'SPF du tout.

Qu'est-ce que DKIM ?

DKIM ajoute une signature cryptographique à chaque e-mail que vous envoyez. La signature est générée à l'aide d'une clé privée détenue par votre service d'envoi, et votre DNS détient la clé publique correspondante. Les serveurs de réception comparent les deux pour confirmer que l'e-mail provient bien de votre domaine et que rien n'a été modifié pendant le transit.

Un enregistrement DKIM dans le DNS ressemble à ceci :

selector1._domainkey.example.com.    IN    TXT    "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQ..."

Le sélecteur (« selector1 » dans cet exemple) indique aux serveurs de réception quelle clé DKIM rechercher. La plupart des fournisseurs font pivoter les clés périodiquement et utilisent différents sélecteurs pour différents flux d'envoi, le nom du sélecteur fait donc partie de l'emplacement de l'enregistrement.

Chaque e-mail que vous envoyez contient un en-tête DKIM-Signature qui ressemble à ceci :

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; h=from:to:subject:date; bh=...; b=...

La balise d= est le domaine qui revendique la signature. La balise s= est le sélecteur. C'est l'enregistrement DNS que les destinataires rechercheront.

Ce que DKIM ne peut pas faire

DKIM est puissant mais il a des limites. Il ne dit pas quels serveurs sont autorisés à envoyer pour votre domaine. C'est le travail de SPF. Un attaquant peut usurper votre domaine sans signature DKIM, et DKIM seul n'a aucune opinion à ce sujet. Il peut également ne pas fonctionner si un serveur relais modifie le corps du message, par exemple une liste de diffusion qui ajoute un pied de page aux e-mails sortants. Et DKIM n'a pas d'application intégrée. Un serveur de réception peut ignorer une signature échouée à moins que DMARC ne lui dise de ne pas le faire.

Longueur de la clé DKIM

Les clés DKIM modernes font 2048 bits, ce qui produit une chaîne de clé publique plus longue que 255 caractères, la longueur maximale d'une seule valeur d'enregistrement TXT. La plupart des fournisseurs DNS gèrent cela automatiquement en divisant la valeur en plusieurs chaînes entre guillemets, mais certains ne le font pas. Si votre enregistrement DKIM ne s'enregistre pas ou ne valide pas, consultez notre guide sur comment diviser un enregistrement DKIM.

Qu'est-ce que DMARC ?

DMARC lie SPF et DKIM ensemble et indique aux serveurs de réception quoi faire lorsque l'authentification échoue. C'est le seul des trois qui génère des rapports pour vous.

Un enregistrement DMARC typique ressemble à ceci :

_dmarc.example.com.    IN    TXT    "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100; aspf=r; adkim=r"

Chaque balise a un rôle :

• v=DMARC1 déclare qu'il s'agit d'un enregistrement DMARC.
• p= est la politique, l'une des options none, quarantine ou reject.
• rua= est l'endroit où les rapports agrégés sont envoyés.
• pct= est le pourcentage d'e-mails auxquels la politique s'applique (utile pour les déploiements progressifs).
• aspf= et adkim= contrôlent le mode d'alignement, détendu (r) ou strict (s).

Progression de la politique, de none à quarantine à reject

L’application de DMARC est un parcours, pas un interrupteur. Les trois politiques sont des étapes, et vous progressez à travers elles à mesure que votre confiance grandit.

• p=none est le mode de surveillance. Les e-mails échoués sont livrés normalement, mais vous recevez des rapports à leur sujet. Commencez toujours par ici.
• p=quarantine envoie les e-mails échoués dans le dossier spam du destinataire. Passez ici après 2 à 4 semaines en p=none sans que des e-mails légitimes n'échouent.
• p=reject rejette les e-mails défaillants d'emblée (une erreur SMTP 550). Passez ici après 2 à 4 semaines supplémentaires à p=quarantine.

Sauter directement à p=reject est la cause la plus fréquente des interruptions liées à DMARC. Vous découvrirez des sources d’envoi légitimes que vous aviez oubliées (votre CRM, votre outil marketing, votre service d’assistance) seulement après qu’elles aient été rejetées. Commencez toujours par p=none, lisez les rapports, puis augmentez la politique.

Rapports agrégés DMARC

Lorsque vous définissez rua= dans votre enregistrement DMARC, vous commencerez à recevoir des rapports XML quotidiens de chaque fournisseur de messagerie qui gère les e-mails de votre domaine, y compris Google, Microsoft, Yahoo et d'autres. Ces rapports montrent chaque adresse IP qui a envoyé des e-mails sous votre domaine et si SPF et DKIM ont réussi et se sont alignés pour chacun d'eux.

Le XML brut est bruyant et lisible par machine, donc la plupart des équipes connectent leur adresse rua= à un service de reporting DMARC (Postmark, dmarcian, EasyDMARC et similaires) qui analyse les rapports dans un tableau de bord lisible. C'est la seule façon pratique de découvrir les sources d'envoi légitimes que vous auriez pu manquer avant de renforcer votre politique.

Alignement DMARC

DMARC introduit un concept que les autres protocoles n'ont pas, appelé alignement. SPF et DKIM réussissent chacun lorsque leur vérification respective est valide, mais DMARC ne compte cette réussite que si le domaine authentifié correspond à l'adresse From: visible.

Il existe deux types d'alignement.

• Alignement SPF signifie que le domaine smtp.mailfrom (return-path) correspond au domaine From:.
• Alignement DKIM signifie que la balise d= dans la signature DKIM correspond au domaine From:.

DMARC réussit si au moins l'un de ces éléments s'aligne ET que la vérification sous-jacente a réussi.

L'alignement détendu (par défaut) autorise les correspondances de sous-domaines, donc les e-mails de mail.example.com s'alignent avec un From: à example.com. L'alignement strict exige une correspondance exacte. La plupart des expéditeurs utilisent l'alignement détendu, sauf s'ils ont une raison de sécurité spécifique pour l'alignement strict.

L’alignement est la raison la plus fréquente de l’échec DMARC, même lorsque SPF et DKIM réussissent individuellement. De nombreux services d’envoi s’authentifient en utilisant leur propre domaine (par exemple, sendgrid.net), et non le vôtre, ce qui signifie que SPF et DKIM réussissent mais que DMARC échoue car rien ne s’aligne avec example.com. Corriger l’alignement implique généralement de passer à un return-path personnalisé ou à une signature DKIM de marque proposée par votre fournisseur.

Comment ajouter un enregistrement DMARC

Si votre fournisseur de messagerie vous donne un enregistrement DMARC spécifique, ajoutez-le. Sinon, voici un enregistrement de départ générique sûr à _dmarc.yourdomain.com :

v=DMARC1; p=none; rua=mailto:[email protected];

Cela vous place en mode surveillance avec des rapports envoyés à une boîte aux lettres que vous contrôlez. Pour une configuration complète, y compris la gestion des rapports et la progression des politiques, consultez notre guide dédié sur comment créer un enregistrement DMARC.

Pourquoi vous avez besoin des trois

Chaque protocole corrige ce que les autres ne peuvent pas. Voici la répartition.

	SPF	DKIM	DMARC
Ce qu'il empêche	Des serveurs non autorisés envoyant au nom de votre domaine	Le contenu des e-mails étant modifié pendant le transit	Des attaquants usurpant votre adresse From: même lorsque d'autres vérifications réussissent
Ce qu'il vérifie	Adresse IP d'envoi par rapport à votre liste autorisée	Signature cryptographique par rapport à votre clé publique	Alignement entre les résultats d'authentification et le domaine From:
Échec courant	Les e-mails légitimes échouent lors du transfert	Les relais de listes de diffusion modifient le corps et cassent la signature	SPF et DKIM échouent à l'alignement avec le domaine visible
Si vous l'ignorez	N'importe quel serveur peut prétendre envoyer au nom de votre domaine	N'importe qui peut modifier votre e-mail en transit sans être détecté	Les authentifications échouées n'ont aucune application

Utilisez uniquement SPF, et vous êtes vulnérable à l'usurpation basée sur l'alignement, où un attaquant s'authentifie avec son propre domaine tout en affichant le vôtre. Utilisez uniquement DKIM, et n'importe quel serveur peut toujours prétendre être vous. Utilisez uniquement DMARC, et vous n'avez aucune authentification sous-jacente à appliquer. Les trois ensemble sont la seule configuration qui fonctionne réellement.

SPF, DKIM et DMARC sont-ils obligatoires en 2026 ?

L'authentification par e-mail est passée de la meilleure pratique à une exigence non négociable entre 2024 et 2026. Voici où en sont les choses.

Expéditeurs en masse (5 000+ e-mails par jour vers Gmail ou Yahoo)

• Février 2024. Gmail et Yahoo ont introduit des exigences pour les expéditeurs en masse. SPF, DKIM et DMARC sont tous requis. Les en-têtes de désabonnement en un clic sont requis. Le taux de plaintes pour spam doit rester inférieur à 0,3 %.
• Mai 2025. Microsoft a introduit des exigences équivalentes pour Outlook.com, Hotmail et Live.com.
• Novembre 2025. Gmail est passé des reports temporaires (erreurs 421) au rejet permanent (erreurs 550) pour les messages non conformes. Il n'y a plus de période de grâce. Les e-mails non conformes sont rejetés d'emblée.

Expéditeurs à faible volume (moins de 5 000 par jour)

Vous n'êtes techniquement pas soumis aux règles des expéditeurs en nombre, mais les vérifications d'authentification sous-jacentes s'appliquent à chaque connexion. L'absence de SPF, DKIM ou DMARC réduit le placement dans la boîte de réception jusqu'à 76 %, même à faible volume. Les règles ciblent nominalement les expéditeurs en nombre, mais les filtres anti-spam utilisent les mêmes signaux pour tout le monde.

Contextes de conformité

• PCI DSS v4.0 inclut des exigences d'authentification des e-mails pour les organisations traitant des données de cartes de paiement.
• La directive opérationnelle contraignante 18-01 de la CISA exige que toutes les agences fédérales américaines déploient SPF, DKIM et DMARC avec p=reject.
• Des exigences similaires existent au Royaume-Uni (NCSC), en Australie (ACSC) et au Canada (CCCS) pour les gouvernements et les infrastructures critiques.

Même si vous envoyez 50 e-mails par mois depuis votre formulaire de contact, vous avez toujours besoin des trois enregistrements.

L'ordre de configuration qui compte

Ajoutez d'abord SPF. Puis DKIM. Puis DMARC. Avec des délais entre chaque. Cet ordre est non négociable, et se tromper est la raison la plus courante pour laquelle les nouveaux déploiements brisent la délivrabilité.

Pourquoi cet ordre est important

DMARC vérifie les résultats de SPF et DKIM. Si vous ajoutez DMARC avant que ces deux ne soient en place et validés, chaque e-mail échoue à l'authentification. Avec une politique de p=quarantine ou p=reject, votre courrier commence à aller dans les spams ou à être rejeté dès que DMARC se propage. De nombreux fournisseurs ne vous laisseront même pas ajouter un enregistrement DMARC tant que SPF n'aura pas réussi la validation.

Temps avant que chacun ne soit actif

• SPF : 5 à 30 minutes
• DKIM : 1 à 4 heures
• DMARC : 1 à 24 heures

Après la propagation de chaque enregistrement, envoyez un e-mail de test à une adresse Gmail que vous contrôlez et vérifiez les en-têtes via Afficher l'original. SPF et DKIM doivent tous deux afficher PASS avant d'ajouter DMARC.

Où ajouter les enregistrements SPF, DKIM et DMARC

Les trois enregistrements sont ajoutés en tant qu'enregistrements TXT dans les paramètres DNS de votre domaine, au même endroit où vous gérez les enregistrements A, les enregistrements MX et les serveurs de noms. L'emplacement exact dépend de qui gère votre DNS.

Hébergements mutualisés (Bluehost, SiteGround, HostGator)

La plupart des hébergeurs mutualisés incluent un éditeur de zone DNS dans leur panneau de contrôle sous Domaine ou Gestion DNS. Recherchez une option pour ajouter un enregistrement TXT.

Enregistreurs de domaines (GoDaddy, Namecheap, Google Domains)

Si votre hébergement et votre domaine sont séparés, votre DNS se trouve généralement chez votre registraire. Recherchez Paramètres DNS ou Gérer le DNS dans le tableau de bord de votre domaine.

Cloudflare

Ouvrez le tableau de bord Cloudflare, sélectionnez votre domaine, cliquez sur DNS dans le menu de gauche, et ajoutez un nouvel enregistrement TXT. Voici la vue de l'éditeur.

Vercel

Si Vercel héberge le DNS de votre domaine, ouvrez le projet, cliquez sur Paramètres » Domaines » Enregistrements DNS, et ajoutez un nouvel enregistrement TXT. Le champ Hôte accepte @ pour l'apex (utilisé pour SPF) et _dmarc pour DMARC.

Netlify

Le DNS Netlify se trouve sous Domaines dans le tableau de bord de votre équipe. Cliquez sur le domaine, puis sur Configurer le DNS Netlify si vous ne l'avez pas déjà fait, puis ajoutez des enregistrements sous Enregistrements DNS.

Squarespace

Squarespace gère le DNS via Domaines » [nom du domaine] » Paramètres DNS » Enregistrements personnalisés. Ajoutez des enregistrements TXT avec Hôte = @ pour le domaine apex, ou _dmarc pour DMARC.

WP Engine

WP Engine n'héberge pas votre DNS par défaut, vous ajouterez donc les enregistrements SPF, DKIM et DMARC chez le registraire que vous utilisez pour le domaine (GoDaddy, Namecheap, Cloudflare, etc.). Ce dont vous aurez besoin de la part de WP Engine, c'est la bonne valeur pour votre include: SPF afin que leurs serveurs de messagerie puissent envoyer au nom de votre site. Trouvez cela dans le portail utilisateur WP Engine sous les paramètres DNS ou de messagerie de votre environnement. Leur include SPF typique est mail1.wpengine.com. Ajoutez-le à votre enregistrement SPF existant aux côtés de tout autre expéditeur, jamais comme un second enregistrement v=spf1.

Comment tester SPF, DKIM et DMARC

Trois méthodes fiables pour vérifier que les trois enregistrements font ce que vous attendez.

Gmail « Afficher l'original »

Envoyez un e-mail de test depuis votre domaine à une adresse Gmail que vous contrôlez. Une fois qu'il arrive, ouvrez l'e-mail, cliquez sur le menu à trois points en haut à droite et choisissez Afficher l'original. Recherchez ces trois lignes près du haut.

• SPF : PASS (avec votre domaine)
• DKIM : PASS (avec header.d= indiquant votre domaine)
• DMARC : PASS

Si l’un de ces éléments affiche FAIL ou NEUTRAL, passez à la section de dépannage ci-dessous.

Le vérificateur de domaine de WP Mail SMTP

L'outil de test d'e-mail de WP Mail SMTP valide automatiquement les trois enregistrements à chaque envoi d'e-mail de test, sans outil séparé. Il signale les enregistrements manquants, les enregistrements SPF multiples, les problèmes de signature DKIM, les échecs d'alignement DMARC et les problèmes d'enregistrement PTR, le tout depuis votre administration WordPress. Le vérificateur de domaine est gratuit dans WP Mail SMTP Lite.

Vérificateurs en ligne

MxToolbox, dmarcian et HostedScan proposent tous des recherches gratuites SPF, DKIM et DMARC. Entrez votre domaine et vous obtiendrez un statut rapide de réussite/échec pour chaque enregistrement, ainsi que des diagnostics pour les erreurs courantes telles que trop de recherches DNS ou des problèmes de syntaxe.

Dépannage des échecs courants

Si vos enregistrements sont configurés mais que l'authentification échoue toujours, l'une de ces situations en est presque toujours la cause. Chacune suit le même modèle : symptôme, cause probable, diagnostic, correction.

1. Gmail a rejeté votre e-mail avec « 550-5.7.26 »

Symptôme. Gmail rejette l'e-mail avec un rejet SMTP 550-5.7.26. Le texte complet indique généralement quelque chose comme « Gmail exige que tous les expéditeurs s'authentifient avec SPF ou DKIM. »

Cause probable. Pas de SPF ou DKIM valide sur le domaine d'envoi, ou les deux sont mal configurés.

Diagnostic. Faites passer votre domaine par le vérificateur en haut de cette page, ou utilisez le vérificateur de domaine de WP Mail SMTP. Le résultat indiquera lequel des trois enregistrements est manquant ou défaillant.

Correction. Ajoutez un enregistrement SPF valide et confirmez que DKIM signe pour votre domaine d'envoi. Renvoyez après la propagation des deux enregistrements. Pour un diagnostic complet, consultez notre guide sur la correction du blocage des e-mails par Gmail.

2. « Action requise : l'enregistrement SPF requis par votre serveur SMTP n'a pas été ajouté »

Symptôme. Le tableau de bord de votre fournisseur SMTP affiche un avertissement indiquant que votre enregistrement SPF est manquant ou ne vous inclut pas.

Cause probable. La directive include: de votre fournisseur n'est pas dans l'enregistrement SPF de votre domaine.

Diagnostic. Exécutez dig TXT votredomaine.com, ou utilisez le vérificateur ci-dessus. Recherchez l'enregistrement SPF et vérifiez si le domaine du fournisseur (par exemple, sendlayer.net, _spf.google.com) figure dans la liste.

Correction. Ajoutez l'include: du fournisseur à votre enregistrement SPF existant. Par exemple, un enregistrement SPF utilisant SendLayer et Google Workspace se lirait v=spf1 include:sendlayer.net include:_spf.google.com ~all. Ne créez jamais un deuxième enregistrement SPF sur le même domaine.

3. DMARC échoue malgré le succès de SPF

Symptôme. L'option Afficher l'original de Gmail indique SPF: PASS mais DMARC: FAIL.

Cause probable. Échec de l'alignement SPF. Votre domaine de retour ne correspond pas au domaine visible From:.

Diagnostic. Examinez la valeur smtp.mailfrom dans les en-têtes. Correspond-elle au domaine dans From: ?

Correction. Modifiez le chemin de retour de votre service d'envoi pour qu'il pointe vers votre domaine (la plupart des fournisseurs proposent un paramètre « chemin de retour personnalisé » ou « domaine de rebond »), ou fiez-vous plutôt à l'alignement DKIM, souvent plus facile à configurer.

4. Signature DKIM manquante dans les e-mails reçus

Symptôme. Les en-têtes n'affichent aucune ligne DKIM-Signature:.

Cause probable. DKIM n'est pas réellement configuré côté expéditeur, ou le mauvais sélecteur est utilisé.

Diagnostic. Envoyez un test depuis un autre outil (Gmail directement, ou un autre service SMTP) pour comparer. Vérifiez le tableau de bord de votre fournisseur SMTP pour le statut DKIM, car la plupart indiquent si le sélecteur est vérifié.

Correction. Revérifiez que les enregistrements CNAME ou TXT DKIM existent exactement comme spécifié par votre fournisseur. Le nom du sélecteur dans votre enregistrement DNS doit correspondre à celui utilisé par le fournisseur pour la signature. Les fautes de frappe sont extrêmement courantes ici.

5. SPF « permerror: trop de recherches DNS »

Symptôme. Les serveurs de messagerie rejettent vos messages avec un PERMERROR SPF.

Cause probable. Votre enregistrement SPF contient plus de 10 recherches DNS (la limite stricte de 10 de la RFC 7208). Courant lors de l'empilement de directives include: pour plusieurs services.

Diagnostic. Utilisez un outil d'aplatissement SPF pour compter vos recherches. Chaque include:, a, mx, ptr et exists: compte.

Correction. Supprimez les inclusions inutiles, ou utilisez un service d'aplatissement SPF qui résout les inclusions en entrées IP directes. Guide complet dans notre guide de fusion SPF.

6. Plusieurs enregistrements SPF sur le même domaine

Symptôme. PERMERROR ou NEUTRAL SPF malgré un enregistrement d'apparence valide.

Cause probable. Vous avez deux enregistrements TXT SPF ou plus. La RFC 7208 stipule que c'est invalide, et les récepteurs le traiteront comme s'il n'y avait pas d'enregistrement SPF.

Diagnostic. Exécutez dig TXT votredomaine.com, ou utilisez la recherche SPF de MxToolbox. Si vous voyez deux enregistrements commençant par v=spf1, c'est le problème.

Correction. Combinez les directives include: des deux enregistrements en un seul. Voir le guide de fusion ci-dessus.

7. Enregistrement DKIM trop long pour le DNS

Symptôme. Votre fournisseur vous a donné une clé DKIM, mais le DNS ne l'accepte pas.

Cause probable. Les enregistrements TXT uniques ont une limite de 255 caractères par chaîne. Les clés DKIM 2048 bits dépassent cette limite et doivent être divisées en plusieurs chaînes entre guillemets dans le même enregistrement.

Diagnostic. Comptez les caractères de votre clé. Plus de 255 signifie que c'est le problème.

Correction. Divisez la valeur en morceaux de 255 caractères, chacun entre guillemets, comme "v=DKIM1; k=rsa; p=ABC..." "DEF..." "GHI...". La plupart des fournisseurs DNS modernes le font automatiquement. Certains non. Voir la section sur la longueur de la clé DKIM ci-dessus pour le guide complet.

8. Échec de l'alignement DMARC (le tueur silencieux)

Symptom. SPF: PASS et DKIM: PASS mais DMARC: FAIL.

Cause probable. Aucun des protocoles n’est aligné avec le domaine From: même si les deux réussissent individuellement.

Diagnostic. Comparez trois valeurs dans les en-têtes : le domaine From:, le domaine smtp.mailfrom et la balise DKIM d=. Au moins un des deux derniers doit correspondre au premier.

Correction. Configurez votre service d’envoi pour utiliser votre domaine soit dans le chemin de retour (pour l’alignement SPF), soit dans la signature DKIM (pour l’alignement DKIM). La plupart des fournisseurs utilisent par défaut leur propre domaine. Vous devez activer l’alignement.

9. p=reject de DMARC bloquant vos propres e-mails légitimes

Symptom. Les clients ne reçoivent plus vos e-mails transactionnels (réinitialisations de mot de passe, reçus), mais vos envois de test fonctionnent correctement.

Cause probable. Vous êtes passé trop rapidement à p=reject, avant d’avoir répertorié toutes les sources d’envoi légitimes dans votre SPF.

Diagnostic. Vérifiez vos rapports agrégés DMARC. Ils montrent chaque expéditeur qui a échoué sous votre domaine. Les expéditeurs légitimes seront évidents (votre CRM, outil marketing, helpdesk).

Correction. Revenez à p=quarantine ou p=none. Utilisez les rapports DMARC pour ajouter les expéditeurs légitimes manquants au SPF. Attendez 2 à 4 semaines jusqu’à ce que les rapports montrent 0 % d’échec des e-mails légitimes, puis renforcez.

10. Enregistrements ajoutés mais ne se propageant pas

Symptom. Vous avez ajouté les enregistrements, mais les outils indiquent toujours qu’ils sont manquants.

Cause probable. Mise en cache DNS chez votre registraire, votre résolveur local ou le serveur de réception. Courant avec des modifications de TTL faibles après que des enregistrements de TTL élevés aient été mis en cache précédemment.

Diagnostic. Exécutez dig +trace TXT yourdomain.com depuis un réseau différent, ou interrogez directement Google DNS avec dig @8.8.8.8 TXT yourdomain.com. Si ceux-ci montrent l’enregistrement mais que votre testeur ne le fait pas, c’est la mise en cache.

Correction. Attendez. La plupart des propagations s’achèvent en une heure pour SPF et jusqu’à 24 heures pour DMARC. Si après 48 heures vous ne voyez toujours rien, vérifiez que l’enregistrement a été correctement enregistré chez votre registraire. Une erreur courante concerne les interfaces qui nécessitent une étape de confirmation que vous avez manquée.

Notes spécifiques à WordPress

WordPress a un problème d’e-mail spécifique. Par défaut, il utilise la fonction mail() de PHP, qui envoie des messages sans aucune authentification. Vos enregistrements SPF, DKIM et DMARC peuvent être parfaitement configurés, mais si WordPress envoie des e-mails via mail() de PHP depuis l’adresse IP partagée de votre hébergeur web, et que cette IP n’est pas dans votre enregistrement SPF, toutes les vérifications d’authentification échouent.

La solution consiste à acheminer tous les e-mails WordPress via un service SMTP authentifié. WP Mail SMTP le fait avec des intégrations en un clic pour SendLayer, SMTP.com, Brevo, Gmail/Google Workspace, Microsoft 365, Amazon SES, Mailgun, SendGrid, Postmark, SparkPost, et d'autres. Chaque intégration est préconfigurée pour s'authentifier correctement et s'aligner sur votre domaine. Les fonctionnalités améliorées de délivrabilité des e-mails de WP Mail SMTP incluent le vérificateur de domaine gratuit qui signale les enregistrements SPF, DKIM et DMARC manquants ou mal configurés directement dans WordPress.

Si vos e-mails WordPress atterrissent dans le spam, une authentification manquante ou mal alignée en est généralement la cause. Le diagnostic complet se trouve dans notre guide sur pourquoi les e-mails WordPress vont dans le spam. Pour la configuration, notre guide de validation des e-mails WordPress vous guide à travers la vérification des enregistrements.

Réparez vos e-mails WordPress maintenant

FAQ sur SPF, DKIM et DMARC

Ce sont les questions les plus recherchées sur l'authentification des e-mails, organisées du plus fréquent au plus technique. Chaque réponse est autonome.

Quelle est la différence entre SPF, DKIM et DMARC ?

SPF indique qui peut envoyer, DKIM prouve que les e-mails sont authentiques et non modifiés, et DMARC applique ce qui se passe lorsque l'une ou l'autre vérification échoue.

SPF autorise les serveurs d'envoi, DKIM ajoute une signature cryptographique inviolable, et DMARC définit la politique que les destinataires suivent lorsque SPF ou DKIM échoue à l'alignement. Vous avez besoin des trois car chacun couvre une lacune que les autres laissent ouverte. SPF sans DKIM échoue sur les e-mails transférés. DKIM sans SPF permet à des serveurs non autorisés de revendiquer votre domaine. Les deux sans DMARC signifient que les serveurs de réception n'ont aucune instruction d'application lorsque quelque chose échoue.

Avez-vous besoin des trois, SPF, DKIM et DMARC ?

Oui. Depuis février 2024, Gmail et Yahoo exigent les trois pour les expéditeurs de 5 000+ e-mails par jour, et Gmail a commencé à rejeter catégoriquement les e-mails non conformes en novembre 2025. Même en dessous de ce seuil, manquer l'un des trois réduit le placement dans la boîte de réception.

SPF et DKIM échouent chacun dans des situations différentes (SPF échoue lors du transfert, DKIM échoue si un relais modifie le message), donc une configuration à protocole unique échoue de manière imprévisible.

Pouvez-vous utiliser DMARC sans SPF ou DKIM ?

Techniquement, DMARC réussit si SPF ou DKIM réussit et s'aligne, vous pouvez donc exécuter DMARC avec un seul. En pratique, vous devriez configurer les deux, car chacun échoue dans des scénarios où l'autre survit.

Exécuter DMARC avec seulement SPF signifie que les e-mails transférés échouent. L'exécuter avec seulement DKIM signifie que les messages modifiés en transit échouent. Les deux ensemble assurent une authentification fiable.

Que signifient p=none, p=quarantine et p=reject ?

Ce sont les niveaux d'application DMARC, par ordre de rigueur.

p=none est le mode de surveillance. Il signale les échecs mais ne bloque rien, et c'est par là que chaque domaine devrait commencer. p=quarantine envoie les e-mails échoués dans le dossier spam. p=reject bloque complètement les e-mails échoués.

Passez progressivement de none à quarantine à reject, seulement après que vos rapports confirment qu'aucun e-mail légitime n'échoue.

Dans quel ordre devriez-vous configurer SPF, DKIM et DMARC ?

Configurez d'abord SPF, puis DKIM, puis DMARC. DMARC lit les résultats de SPF et DKIM, donc l'ajouter en premier entraîne l'échec immédiat de l'authentification de tous les e-mails.

Ajoutez SPF, attendez sa propagation, ajoutez DKIM, vérifiez que les deux réussissent dans une vérification Afficher l'original de Gmail, puis ajoutez DMARC en commençant par p=none.

Comment vérifier si SPF, DKIM et DMARC sont correctement configurés ?

Utilisez un outil de vérification (comme celui gratuit en haut de cette page) qui recherche les trois enregistrements pour votre domaine et signale leur état.

Vous pouvez également vérifier manuellement. Envoyez un e-mail à une adresse Gmail, ouvrez-le, cliquez sur le menu à trois points, choisissez Afficher l'original et confirmez que SPF, DKIM et DMARC indiquent chacun RÉUSSITE.

Qu'est-ce que l'alignement DMARC ?

L'alignement est la vérification qui donne un sens à DMARC. Il confirme que le domaine qui a réussi SPF ou DKIM correspond au domaine de l'adresse visible From: de l'e-mail.

L'alignement SPF exige que le domaine du chemin de retour corresponde au domaine From:. L'alignement DKIM exige que la balise d= de la signature corresponde. La cause la plus fréquente d'échec DMARC est le désalignement, pas un échec SPF ou DKIM pur et simple.

Que signifie l'erreur Gmail « 550-5.7.26 » ?

L'erreur 550-5.7.26 signifie que Gmail a rejeté votre e-mail car le domaine d'envoi n'est pas authentifié. Gmail exige désormais que tous les expéditeurs s'authentifient avec SPF ou DKIM.

Pour résoudre ce problème, ajoutez un enregistrement SPF valide et une signature DKIM pour votre domaine d'envoi, puis confirmez que les deux réussissent avant de renvoyer. Le premier élément de dépannage ci-dessus explique le diagnostic complet.

Que signifie lorsque « Afficher l'original » de Gmail indique SPF, DKIM et DMARC RÉUSSITE ?

Cela signifie que votre e-mail a été correctement authentifié. SPF RÉUSSITE confirme que l'e-mail provient d'un serveur autorisé. DKIM RÉUSSITE confirme que le message n'a pas été modifié pendant le transit. DMARC RÉUSSITE confirme que le domaine authentifié correspond à votre adresse From: visible.

Les trois réussites sont le résultat que vous souhaitez. Cela maximise le placement dans la boîte de réception.

SPF, DKIM et DMARC empêchent-ils les e-mails d'aller dans le spam ?

Ils sont nécessaires mais pas suffisants. L'authentification indique aux fournisseurs de boîtes aux lettres que vos e-mails proviennent bien de vous, ce qui est un prérequis pour le placement dans la boîte de réception, mais d'autres facteurs entrent toujours en jeu. Ceux-ci incluent la réputation de l'expéditeur, la qualité du contenu, les taux d'engagement, l'hygiène de la liste et un enregistrement PTR valide.

Configurez d'abord les trois, puis abordez les autres facteurs de délivrabilité des e-mails.

Quel est le meilleur outil pour vérifier DMARC, SPF et DKIM ?

Le moyen le plus rapide est un vérificateur qui teste les trois à la fois, comme celui gratuit sur cette page. Pour une surveillance continue, Google Postmaster Tools montre comment Gmail évalue votre authentification, et le vérificateur de domaine intégré de WP Mail SMTP vérifie les trois enregistrements directement dans WordPress.

Quelle est la signification complète de SPF, DKIM et DMARC ?

SPF signifie Sender Policy Framework. DKIM signifie DomainKeys Identified Mail. DMARC signifie Domain-based Message Authentication, Reporting, and Conformance.

Ensemble, ils forment la pile standard pour authentifier les e-mails et protéger un domaine contre l'usurpation.

Ensuite, vérifiez votre enregistrement PTR

SPF, DKIM et DMARC sont trois des quatre enregistrements DNS importants pour la délivrabilité des e-mails. Le quatrième est votre enregistrement PTR, l'entrée DNS inversée qui associe votre IP d'envoi à votre domaine. Les fournisseurs de boîtes aux lettres le vérifient à chaque connexion, et un PTR manquant ou générique nuira à votre délivrabilité même lorsque SPF, DKIM et DMARC réussissent tous.

Pour une analyse complète, consultez notre guide sur les enregistrements PTR et le DNS inversé.

Réparez vos e-mails WordPress maintenant

Prêt à réparer vos e-mails ? Commencez dès aujourd'hui avec le meilleur plugin SMTP WordPress. Si vous n'avez pas le temps de réparer vos e-mails, vous pouvez obtenir une assistance complète de configuration "White Glove" moyennant un supplément, et il y a une garantie de remboursement de 14 jours pour tous les plans payants.