Fièrement canadien 
Les erreurs d'enregistrement SPF sont responsables d'une part significative des problèmes de délivrabilité des courriels que nous rencontrons. Ce qui les rend frustrants, c'est que le côté expéditeur ne montre aucune erreur. Votre serveur de messagerie signale un envoi réussi, le message quitte votre serveur sans problème, et vous n'avez aucune indication que quelque chose a mal tourné jusqu'à ce que quelqu'un vous dise qu'il n'a pas reçu votre courriel, ou que vous le découvriez dans son dossier spam.
Les erreurs SPF se produisent du côté destinataire, quand le serveur de messagerie de destination vérifie votre DNS pour s'assurer que le serveur qui a envoyé votre message était autorisé à le faire. Si votre enregistrement SPF est manquant, dupliqué, syntaxiquement incorrect ou dépasse la limite de recherches, cette vérification échoue et le message est traité comme suspect ou rejeté purement selon la façon dont le serveur destinataire gère les échecs SPF.
Ce guide couvre le fonctionnement réel de la validation SPF, ce que signifie chaque type d'erreur, comment diagnostiquer l'erreur que vous avez, et comment la corriger correctement pour que le problème ne revienne pas.
Résumé de la correction rapide
- S'assurer que votre domaine a exactement un enregistrement TXT SPF, pas plus
- Fusionner tous les services d'envoi dans ce seul enregistrement
- Maintenir le nombre total de recherches DNS à 10 ou moins
- Vérifier l'enregistrement avec MXToolbox ou Google Admin Toolbox avant de considérer la correction terminée
- Vérifier les en-têtes de courriel après la correction pour confirmer que SPF passe
Comment fonctionne la validation SPF
SPF, ou Sender Policy Framework, est un enregistrement DNS qui liste chaque serveur autorisé à envoyer des courriels au nom de votre domaine. Quand un message arrive sur un serveur de messagerie destinataire, ce serveur extrait l'adresse IP d'envoi et votre domaine de l'enveloppe du message, puis interroge votre DNS pour un enregistrement SPF. Il évalue si l'IP d'envoi correspond à l'une des sources autorisées listées dans votre enregistrement. Si c'est le cas, SPF passe. Si ce n'est pas le cas, ou si l'enregistrement est invalide, SPF échoue.
Le détail technique important ici est que SPF vérifie l'expéditeur de l'enveloppe, aussi appelé Return-Path ou adresse MAIL FROM, pas l'adresse De visible que les destinataires voient dans leur client de messagerie. C'est pourquoi SPF seul ne prévient pas entièrement l'usurpation d'identité par courriel. Un expéditeur peut créer un courriel où l'expéditeur de l'enveloppe passe SPF tout en affichant une adresse De d'un domaine complètement différent aux destinataires. C'est l'une des raisons pour lesquelles DMARC existe, pour imposer l'alignement entre le domaine authentifié par SPF et l'adresse De visible.
Les résultats SPF se répartissent en plusieurs catégories. Un pass signifie que l'IP d'envoi était autorisée et que l'enregistrement était valide. Un fail, parfois écrit hardfail, signifie que l'IP d'envoi n'était explicitement pas autorisée. Un softfail signifie que l'autorisation a échoué mais que l'enregistrement a demandé aux serveurs destinataires d'accepter le message quand même et de le marquer plutôt que de le rejeter. Un permerror signifie que l'enregistrement lui-même est invalide, généralement en raison d'une erreur de syntaxe ou du dépassement de la limite de recherches. Un temperror signifie que la requête DNS n'a pas pu être complétée à ce moment-là en raison d'un problème d'infrastructure temporaire.
Permerror est le résultat le plus couramment causé par les erreurs de configuration couvertes dans ce guide, et c'est le plus important à corriger car il fait échouer SPF complètement pour chaque message que vous envoyez jusqu'à ce que l'enregistrement soit corrigé.
Étape 1 : Vérifier ce qui se trouve actuellement dans votre DNS
Avant d'apporter des modifications, vous devez voir exactement ce que votre DNS contient actuellement. La façon la plus directe depuis une ligne de commande est :
dig TXT votredomaine.com
Parcourez les enregistrements TXT retournés pour toute ligne contenant v=spf1. Si vous en voyez plus d'une, vous avez un problème d'enregistrement SPF en double qui doit être résolu avant toute autre chose.
Si vous préférez un outil en navigateur, MXToolbox sur mxtoolbox.com/spf.aspx est l'option la plus utile. Entrez votre domaine et il retourne votre enregistrement SPF, valide la syntaxe, compte le nombre de recherches DNS que l'enregistrement nécessite, et signale les erreurs spécifiques. Google Admin Toolbox sur toolbox.googleapps.com fournit une sortie similaire avec des messages d'erreur légèrement différents.
Notez tout ce qui se trouve actuellement dans votre enregistrement SPF avant de modifier quoi que ce soit. Si vous fusionnez ou réécrivez l'enregistrement, vous devez vous assurer qu'aucune source d'envoi autorisée n'est accidentellement supprimée dans le processus.
Les erreurs SPF les plus courantes et comment corriger chacune
Plusieurs enregistrements SPF sur le même domaine
C'est l'erreur la plus courante et l'une des plus dommageables. RFC 7208, la spécification technique qui définit le fonctionnement de SPF, est explicite : un domaine ne doit pas avoir plus d'un enregistrement TXT qui commence par v=spf1. Quand un serveur destinataire en trouve deux ou plus, il ne peut pas déterminer lequel fait autorité et retourne une PermError. Chaque message que vous envoyez échouera SPF jusqu'à ce que cela soit résolu, quel que soit l'aspect correct des enregistrements individuels.
Cette situation survient généralement quand quelqu'un ajoute un nouveau service de messagerie et crée un deuxième enregistrement SPF au lieu de modifier l'existant, ou quand une zone DNS a été migrée et que les enregistrements ont été dupliqués dans le processus.
La correction consiste à supprimer tous sauf un des enregistrements SPF et à fusionner toutes les directives include dans le seul enregistrement restant. Si vous avez :
v=spf1 include:_spf.google.com ~all
v=spf1 include:mailgun.org ~all
Supprimez les deux et remplacez par un seul enregistrement qui contient tout :
v=spf1 include:_spf.google.com include:mailgun.org ~all
Un seul enregistrement TXT commençant par v=spf1 doit exister sur votre domaine à tout moment.
Dépasser la limite de 10 recherches DNS
L'évaluation SPF implique des recherches DNS. Chaque directive include: dans votre enregistrement demande au serveur destinataire de chercher l'enregistrement SPF du domaine inclus pour trouver les IPs autorisées. Les mécanismes a, mx et exists déclenchent également des recherches. SPF autorise un maximum de 10 de ces recherches lors d'une seule évaluation. Si votre enregistrement en nécessite plus, l'évaluation retourne une PermError et SPF échoue.
Le problème est que chaque déclaration include: peut elle-même contenir d'autres déclarations include:, qui comptent chacune dans votre limite. Un enregistrement qui semble avoir cinq includes peut en réalité déclencher huit ou neuf recherches une fois que les références imbriquées sont suivies.
Pour connaître le nombre de recherches que votre enregistrement nécessite actuellement, utilisez le vérificateur SPF de MXToolbox. Il compte les recherches explicitement et signale les enregistrements qui dépassent la limite.
Il existe plusieurs approches pour résoudre un nombre de recherches trop élevé. La plus propre consiste à remplacer les directives include: par les plages IP réelles vers lesquelles elles se résolvent, en utilisant à la place les mécanismes ip4: et ip6:. Ceux-ci ne déclenchent pas de recherches DNS et ne comptent donc pas dans la limite. Par exemple, si vous connaissez les plages IP exactes de votre service de messagerie :
v=spf1 ip4:192.0.2.0/24 include:_spf.google.com ~all
Le compromis est que les plages IP des services tiers peuvent changer sans préavis, vous obligeant à mettre à jour votre enregistrement quand ils le font. Les services qui changent fréquemment leurs plages IP sont mieux laissés comme directives include: en comprenant que vous devrez gérer le nombre de recherches avec soin.
Une autre option est l'aplatissement SPF, où un script ou un service résout périodiquement tous les includes imbriqués dans votre enregistrement et les remplace par la liste d'IPs résultante, supprimant entièrement la dépendance aux recherches. Des outils comme AutoSPF ou dmarcly.com offrent cela comme service géré. L'inconvénient est que les enregistrements aplatis nécessitent une maintenance régulière à mesure que les plages IP des services d'envoi changent.
Directives include manquantes pour les expéditeurs tiers
Chaque service qui envoie des courriels au nom de votre domaine doit être autorisé dans votre enregistrement SPF. Cela inclut votre fournisseur de messagerie principal, mais aussi votre CRM s'il envoie des courriels automatisés, votre plateforme marketing si elle envoie des campagnes, votre service de courriel transactionnel, votre système de tickets de support, et tout autre outil qui génère des courriels sortants en utilisant votre domaine dans l'adresse De ou Return-Path.
Un scénario courant est une entreprise qui configure Google Workspace et ajoute include:_spf.google.com à son enregistrement SPF, puis commence à utiliser Mailchimp, HubSpot ou Zendesk sans mettre à jour l'enregistrement. Les messages de ces services échouent SPF car ils ne sont pas autorisés.
Directives include courantes pour les services fréquemment utilisés :
Google Workspace: include:_spf.google.com Microsoft 365: include:spf.protection.outlook.com SendGrid: include:sendgrid.net Mailgun: include:mailgun.org Mailchimp: include:servers.mcsv.net HubSpot: include:hubspotemail.net Zendesk: include:mail.zendesk.com Salesforce: include:_spf.salesforce.com
Lors de l'ajout d'un nouveau service, vérifiez sa documentation pour la directive include SPF correcte. La plupart des services majeurs publient cela dans leur documentation d'authentification des courriels ou de configuration DNS.
Erreurs de syntaxe dans l'enregistrement
Les enregistrements SPF doivent suivre un format spécifique. Les erreurs de syntaxe courantes qui rendent l'enregistrement invalide incluent l'utilisation d'un point-virgule au lieu d'un espace entre les mécanismes, l'oubli du préfixe v=spf1, le placement de all ailleurs qu'à la fin de l'enregistrement, l'utilisation d'include sans deux-points avant le domaine, et laisser un espace de fin ou un caractère invisible dans la valeur de l'enregistrement.
Un enregistrement SPF correctement formaté ressemble à ceci :
v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.0/24 ~all
Chaque mécanisme est séparé par un seul espace. L'enregistrement commence par v=spf1 et se termine par un mécanisme all. Il n'y a pas de points-virgules, pas de virgules, et pas de caractères en dehors de la syntaxe de mécanisme SPF définie.
Si vous n'êtes pas certain que la syntaxe de votre enregistrement est valide, collez-la dans le vérificateur SPF de MXToolbox, qui signalera les erreurs de syntaxe spécifiques et vous montrera ce que signifie chaque partie de l'enregistrement.
Utiliser redirect au lieu de include incorrectement
SPF a deux mécanismes pour référencer des enregistrements externes : include: et redirect=. Ils se comportent différemment et sont souvent confondus. Le mécanisme include: importe les mécanismes de l'enregistrement SPF d'un autre domaine comme s'ils étaient écrits dans le vôtre. Si l'enregistrement du domaine inclus passe pour l'IP d'envoi, l'évaluation continue. Le modificateur redirect= remplace entièrement votre enregistrement SPF par l'enregistrement du domaine spécifié. Il ne doit être utilisé que lorsque vous souhaitez déléguer SPF entièrement à un autre domaine, pas quand vous souhaitez autoriser un service supplémentaire.
Utiliser redirect= quand vous vouliez dire include: signifie que votre enregistrement SPF entier est remplacé par ce que le domaine redirigé spécifie, supprimant toute autre autorisation que vous aviez. C'est une erreur subtile mais aux conséquences importantes.
Vérifier votre correction
Après avoir apporté des modifications à votre enregistrement SPF, la propagation DNS prend généralement entre quelques minutes et quelques heures selon les paramètres TTL de votre registraire. Une fois la propagation terminée, vérifiez la correction en utilisant une combinaison des méthodes suivantes.
Passez à nouveau votre domaine dans le vérificateur SPF de MXToolbox. Confirmez qu'il montre exactement un enregistrement SPF, que la syntaxe est valide, que tous vos services d'envoi sont inclus, et que le nombre de recherches est dans la limite de 10.
Envoyez un courriel de test depuis chaque service que vous avez autorisé dans votre enregistrement SPF à une adresse Gmail que vous contrôlez. Ouvrez le message dans Gmail, cliquez sur le menu à trois points et sélectionnez Afficher l'original. Cherchez l'en-tête Authentication-Results près du haut des en-têtes bruts. Il contiendra une ligne commençant par spf= suivie de pass, fail, softfail ou permerror, ainsi que le domaine et l'IP qui ont été vérifiés.
Si vous voyez spf=pass, la correction fonctionne. Si vous voyez encore spf=permerror, l'enregistrement est toujours invalide et nécessite une investigation plus poussée. Si vous voyez spf=fail ou spf=softfail pour un service spécifique, ce service n'est pas couvert par votre enregistrement SPF et sa directive include doit être ajoutée.
Gérer SPF via votre espace client WHMCS
Si votre DNS de domaine est géré via notre plateforme, vous pouvez modifier votre enregistrement SPF directement depuis votre espace client sans avoir besoin d'accéder à un panneau de contrôle DNS séparé. Accédez à Mes domaines, cliquez sur Gérer à côté du domaine concerné, et sélectionnez Gestion DNS. Votre enregistrement SPF sera listé comme un enregistrement TXT à l'hôte racine, affiché comme @ ou votre nom de domaine. Modifiez le champ de valeur directement et sauvegardez. Les modifications se propagent généralement en quelques minutes à quelques heures selon le TTL configuré pour cet enregistrement.
Si vous ne trouvez pas l'option de gestion DNS ou si le DNS de votre domaine est géré ailleurs, contactez notre équipe de support et nous pourrons examiner votre enregistrement SPF actuel et conseiller sur les modifications correctes.
SPF dans le cadre d'une configuration d'authentification complète
SPF est l'un des trois protocoles d'authentification qui forment ensemble une configuration d'authentification des courriels complète. Corriger votre enregistrement SPF est une étape importante, mais isolément il ne fournit pas une protection complète contre l'usurpation ni ne garantit le placement en boîte de réception.
DKIM ajoute une signature cryptographique aux messages sortants, ce qui prouve que le message n'a pas été altéré en transit et fournit un signal d'authentification qui survit mieux au transfert de courriels que SPF. DMARC s'appuie sur les deux en imposant l'alignement entre les domaines authentifiés et l'adresse De visible, et en fournissant des rapports agrégés qui vous montrent comment votre domaine est utilisé et si l'authentification passe pour toutes vos sources d'envoi.
Si vous avez corrigé votre enregistrement SPF et souhaitez compléter votre configuration d'authentification des courriels, les prochaines étapes sont d'activer DKIM via votre fournisseur de messagerie et de publier un enregistrement DMARC commençant par p=none pour commencer la surveillance. Les deux sont couverts en détail dans nos guides de configuration DMARC et DKIM.
Quand contacter le support?
Si vous avez vérifié que votre enregistrement SPF est syntaxiquement correct, contient tous vos services d'envoi et reste dans la limite de 10 recherches, mais que les messages échouent encore à l'authentification SPF chez certains fournisseurs, le problème peut impliquer la façon dont un service particulier envoie en votre nom. Certains services envoient en utilisant un sous-domaine ou une adresse Return-Path qui ne correspond pas à votre domaine racine, ce qui fait que SPF vérifie une partie différente de votre DNS de là où votre enregistrement SPF se trouve.
De même, si vous atteignez la limite de recherches mais ne pouvez pas réduire vos services autorisés, une approche d'aplatissement SPF peut nécessiter une aide à la mise en œuvre. Ouvrez un ticket de support depuis votre espace client avec votre nom de domaine et une copie de votre enregistrement SPF actuel. Notre équipe peut identifier le problème spécifique et recommander la bonne correction.
Ce qui se passe si vous n'avez pas d'enregistrement SPF
Les recherches qui amènent beaucoup de personnes sur ce guide partent d'un point différent d'un enregistrement défectueux. Elles n'ont pas d'enregistrement SPF du tout et veulent comprendre ce que cela signifie avant d'en créer un. Si c'est votre situation, cette section s'adresse à vous.
Quand un serveur de messagerie destinataire traite un courriel entrant de votre domaine, il vérifie le DNS pour un enregistrement SPF à la racine de votre domaine. Si aucun enregistrement SPF n'existe, le résultat n'est ni une réussite ni un échec — c'est un résultat neutre appelé « none ». Ce que le serveur destinataire fait avec un résultat none dépend entièrement de sa propre politique. Certains serveurs traitent none comme une réussite et livrent le message normalement. D'autres traitent none comme un échec partiel et appliquent un examen supplémentaire. Gmail et Outlook utilisent tous deux l'absence d'enregistrement SPF comme signal négatif dans leur filtrage anti-spam, même s'ils ne rejettent pas explicitement les messages sur cette seule base.
La conséquence la plus significative d'un enregistrement SPF absent est son interaction avec DMARC. Si vous avez une politique DMARC en place et que SPF retourne none plutôt que pass, DMARC ne peut pas utiliser SPF pour l'alignement. DMARC exige qu'au moins l'un de SPF ou DKIM réussisse et soit aligné avec l'adresse De. Sans enregistrement SPF valide, la charge repose entièrement sur DKIM. Si DKIM n'est pas non plus configuré ou échoue, DMARC échouera, et si votre politique DMARC est définie sur quarantine ou reject, vos courriels légitimes seront bloqués ou envoyés dans le spam.
Créer un enregistrement SPF pour un domaine qui n'en a pas est simple. L'enregistrement SPF minimal viable qui autorise votre serveur d'hébergement à envoyer au nom de votre domaine est :
v=spf1 a mx ~all
Cet enregistrement autorise les adresses IP associées à l'enregistrement A et MX de votre domaine à envoyer des courriels. Le ~all à la fin est un échec partiel pour tout ce qui n'est pas couvert par l'enregistrement. Si vous utilisez Google Workspace pour la messagerie, l'enregistrement devient :
v=spf1 include:_spf.google.com ~all
Si vous utilisez à la fois votre serveur d'hébergement et Google Workspace, combinez-les :
v=spf1 a mx include:_spf.google.com ~all
Ajoutez ceci comme enregistrement TXT à la racine de votre domaine dans votre panneau de gestion DNS. Une fois publié, attendez jusqu'à 48 heures pour la propagation, puis vérifiez qu'il est visible en utilisant la recherche SPF de MXToolbox.
Gotekky
Besoin d’aide pour choisir la prochaine étape?
Décrivez ce que vous observez et le résultat recherché. Nous identifierons si un service géré, un projet défini ou une évaluation technique payante est la bonne prochaine étape.