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 comment fonctionnent les trois protocoles, où ils s'articulent, comment les configurer dans le bon ordre et quoi faire lorsque quelque chose se casse. En 2026, tous les trois sont effectivement obligatoires pour toute entreprise qui envoie des e-mails. Gmail, Yahoo et Microsoft les appliquent directement, et ignorer l'un d'eux fait chuter votre placement dans la boîte de réception.

SPF vs DKIM vs DMARC en un coup d'œil

Si vous avez juste besoin de la version rapide, ce tableau couvre l'essentiel. Chaque protocole fait quelque chose que les autres ne peuvent pas faire, c'est pourquoi les trois sont nécessaires ensemble.

Réparez vos e-mails WordPress maintenant

L'explication en 30 secondes

Si quelqu'un vous demandait d'expliquer l'authentification des e-mails lors d'une fête, voici la version qui tient en trois phrases :

• SPF indique quels serveurs sont autorisés à envoyer des e-mails pour votre domaine.
• DKIM prouve que l'e-mail n'a été modifié par personne pendant le transit.
• DMARC indique au serveur destinataire quoi faire lorsque SPF ou DKIM échoue : livrer, envoyer dans les spams ou rejeter.

Vous avez besoin des trois car chacun corrige ce que les autres manquent.

Comment SPF, DKIM et DMARC fonctionnent ensemble

Lorsqu'un e-mail arrive sur Gmail, Outlook ou toute autre boîte de réception, trois vérifications se produisent l'une après l'autre.

Premièrement, le serveur de réception prend l'adresse IP d'où provient le message et examine votre enregistrement SPF. L'enregistrement SPF est une liste de serveurs que vous avez autorisés à envoyer des e-mails pour votre domaine. Si l'IP d'envoi est sur la liste, SPF réussit.

Deuxièmement, le serveur vérifie la signature DKIM jointe à l'e-mail. DKIM est une signature cryptographique appliquée au moment de l'envoi, et votre DNS contient la clé publique correspondante. Si la signature est vérifiée par rapport à la clé, DKIM réussit, et cela prouve que le contenu de l'e-mail n'a pas été modifié entre l'expéditeur et le destinataire.

Troisièmement, le serveur examine votre enregistrement DMARC. DMARC indique deux choses : laquelle de ces deux vérifications doit réussir et s'aligner avec votre adresse From: visible, et quoi faire si aucune des deux ne réussit. Les trois options sont : livrer normalement, envoyer vers le spam (quarantaine) ou rejeter le message entièrement.

La partie « alignement » est importante. Sans elle, un attaquant pourrait réussir SPF pour son propre domaine tout en usurpant le vôtre dans la ligne From: visible. DMARC comble cette lacune en exigeant que le domaine authentifié corresponde à celui que le destinataire voit.

Qu'est-ce que SPF ?

SPF (Sender Policy Framework) est un enregistrement TXT dans votre DNS qui liste chaque serveur et service autorisé à 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

Décortiquons :

• v=spf1 déclare qu'il s'agit d'un enregistrement SPF.
• include:sendlayer.net autorise un service d'envoi, dans ce cas, 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 » (autoriser mais signaler comme suspect). Utilisez -all pour « échec strict » (rejeter) 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'IP d'où il provient et vérifie si cette 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 IP, qui ne figure pas dans votre enregistrement SPF. SPF échoue même si l'original était légitime. Et il ne vérifie que le chemin de retour, pas l'adresse From: visible. Un attaquant peut réussir SPF avec un domaine qu'il contrôle tout en faisant apparaître la ligne From: comme la vôtre. C'est pourquoi l'alignement DMARC est important. Voir la section DMARC 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 : vous ne pouvez avoir qu'un seul enregistrement SPF par domaine. Si vous essayez d'en ajouter un deuxième, la RFC 7208 stipule que les destinataires doivent considérer l'ensemble de la configuration comme invalide, ce qui revient au même que de n'avoir aucun SPF du tout.

Qu'est-ce que DKIM ?

DKIM (DomainKeys Identified Mail) 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 contient 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 ressemblant à 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 rôle de SPF. Un attaquant peut usurper votre domaine sans signature DKIM, et DKIM seul n'a aucune opinion à ce sujet. Il peut également échouer 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 de mécanisme d'application intégré. 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 (Domain-based Message Authentication, Reporting, and Conformance) 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 : 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 : p=none → p=quarantine → p=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 : Mode de surveillance. Les e-mails échoués sont livrés normalement, mais vous recevez des rapports à leur sujet. Commencez toujours ici.
• p=quarantine : Les e-mails échoués sont envoyé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 : Les e-mails échoués sont rejetés directement (une erreur SMTP 550). Passez ici après 2 à 4 semaines supplémentaires en 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 : Google, Microsoft, Yahoo, et d’autres. Ces rapports montrent chaque 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, etc.) qui analyse les rapports dans un tableau de bord lisible. C’est le seul moyen de découvrir des sources d’envoi légitimes que vous auriez pu manquer avant de resserrer votre politique.

Alignement DMARC

DMARC introduit un concept que les autres protocoles n’ont pas : l’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.

Deux variantes :

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

DMARC réussit si au moins 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, un e-mail de mail.example.com s’aligne 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 (et ce qui se passe si vous n'en avez qu'un)

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

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

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

L'authentification des e-mails est passée de « meilleure pratique » à « 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 tous requis. En-têtes de désabonnement en un clic 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 temporaires) 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 sans appel.

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

Vous n'êtes techniquement pas soumis aux règles des expéditeurs en masse, 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 masse ; 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.

La leçon à retenir : 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 (la plupart des gens se trompent)

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 ?

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, cela signifie que vos e-mails commencent à aller dans les spams ou sont rejetés 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 passé 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 en cliquant sur « 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ébergements 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 enregistreur. 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 les enregistrements sous « Enregistrements DNS ».

Squarespace

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

Comment tester SPF, DKIM et DMARC

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

Méthode 1 : Gmail « Afficher l’original »

Envoyez un e-mail de test depuis votre domaine vers 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.

Méthode 2 : 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.

Méthode 3 : Vérificateur de domaine de WP Mail SMTP

L’outil de test d’e-mails de WP Mail SMTP valide automatiquement les trois enregistrements à chaque fois que vous envoyez un e-mail de test, aucun outil séparé n’est requis. 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.

Dépannage des échecs SPF, DKIM et DMARC

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

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

Symptôme : « Afficher l’original » de Gmail affiche SPF : PASS mais DMARC : FAIL.

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

Diagnostic : Regardez 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 corresponde à 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, qui est souvent plus facile à configurer.

2. 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 à partir d’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, 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 avec lequel le fournisseur signe, les fautes de frappe ici sont extrêmement courantes.

3. SPF « permerror : trop de recherches DNS »

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

Cause probable : Votre enregistrement SPF contient plus de 10 recherches DNS (la limite stricte 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 sur notre guide de fusion SPF.

4. 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, 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 enregistrement. Guide détaillé ici.

5. Échec d'alignement DMARC (le tueur silencieux)

Symptôme : 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 l'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 opter pour l'alignement.

6. 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 de 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 : "v=DKIM1; k=rsa; p=ABC..." "DEF..." "GHI...". La plupart des fournisseurs DNS modernes le font automatiquement ; certains non. Guide complet sur comment diviser un enregistrement DKIM.

7. SPF inclut votre fournisseur, mais les e-mails échouent toujours

Symptôme : Votre enregistrement SPF inclut correctement votre service de messagerie (par exemple, include:sendlayer.net), mais les e-mails échouent toujours au SPF.

Cause probable : Vous envoyez depuis une adresse IP différente de celle vers laquelle votre include pointe, généralement parce que plusieurs services envoient sous le même domaine (par exemple, des e-mails transactionnels via SendLayer, du marketing via Mailchimp) mais que vous n'en avez inclus qu'un.

Diagnostic : Vérifiez les en-têtes pour l'adresse IP d'envoi réelle. Comparez-la aux adresses IP dans l'enregistrement SPF de votre include.

Correction : Ajoutez des includes pour chaque service qui envoie depuis votre domaine, chaque outil de marketing, service transactionnel, helpdesk et CRM. Si cela vous fait dépasser la limite de 10 recherches, consultez le problème n°3.

8. DMARC p=reject bloque vos propres e-mails légitimes

Symptôme : 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 capturé 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 de 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.

9. Enregistrements ajoutés mais ne se propageant pas

Symptôme : Vous avez ajouté les enregistrements, mais les outils indiquent toujours qu'ils sont manquants.

Cause probable : Mise en cache DNS au niveau de votre bureau d'enregistrement, de votre résolveur local ou du 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 une mise en cache.

Correction : Attendez. La plupart des propagations se terminent dans l'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é auprès de votre bureau d'enregistrement, une erreur courante est que les interfaces nécessitent une étape de confirmation que vous avez manquée.

10. L'e-mail de test réussit, mais les vrais e-mails échouent

Symptôme : Votre e-mail de test WP Mail SMTP affiche tout en vert, mais les vrais e-mails WordPress (notifications de formulaire, réinitialisations de mot de passe) échouent à l'authentification.

Cause probable : Chemins d'envoi différents. Le test du plugin passe par le service de messagerie configuré, mais les e-mails WordPress générés par certains plugins ou formulaires peuvent le contourner.

Diagnostic : Vérifiez l'adresse From: sur les e-mails défaillants, est-ce votre domaine, ou [email protected] ? Si c'est le cas, vous avez une discordance d'adresse d'expéditeur.

Correction : Dans WP Mail SMTP, activez "Forcer l'e-mail From" afin que chaque e-mail WordPress utilise votre adresse authentifiée, quel que soit le paramètre du plugin d'origine.

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 la fonction mail() de PHP depuis l'adresse IP partagée de votre hébergeur, et que cette adresse IP ne figure 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 correspondre à votre domaine.

Si vos e-mails WordPress atterrissent dans le spam, la cause est généralement une authentification manquante ou mal alignée. Le diagnostic complet se trouve dans notre guide sur pourquoi les e-mails WordPress vont dans le spam.

Réparez vos e-mails WordPress maintenant

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

v=spf1 include:sendlayer.net ~all

v=spf1 include:sendlayer.net include:_spf.google.com ~all

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é. Si vous envoyez un volume important, vous voudrez également configurer les Outils Postmaster de Google pour surveiller la façon dont Gmail perçoit votre réputation d'expéditeur.

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.

Si cet article vous a aidé, suivez-nous sur Facebook et Twitter pour plus de conseils et tutoriels WordPress.