Puis-je avoir plusieurs enregistrements SPF sur un même domaine ?

Peut-on avoir plusieurs enregistrements SPF sur un même domaine ?

Pour un même nom d'hôte, non. Un domaine ne doit publier qu'un seul enregistrement SPF par nom d'hôte. La RFC 7208 stipule qu'un nom de domaine ne doit pas comporter plusieurs enregistrements qui pourraient amener un contrôle d'autorisation à sélectionner plus d'un enregistrement « ». Dans la pratique, la présence de plusieurs enregistrements SPF génère une erreur « SPF multiple records » plutôt qu'un résultat valide de type « SPF pass » .

La distinction entre les sous-domaines revêt ici une importance particulière. example.com et mail.example.com peuvent chacun disposer de leur propre enregistrement TXT SPF si ils envoient des e-mails de manière indépendante, car il s'agit de noms DNS différents. Cependant, example.com ne doit pas publier deux entrées TXT distinctes de type « v=spf1 » pour le même hôte. C'est là la différence entre un domaine utilisant un single record et plusieurs sous-domaines utilisant chacun leurs propres enregistrements.

Suggestion visuelle : ajoutez un schéma DNS simple illustrant example.com avec un enregistrement SPF et mail.example.com avec son propre enregistrement SPF distinct .

Problèmes courants liés à la présence de plusieurs enregistrements SPF

Les destinataires ne considèrent pas les politiques SPF en double comme une autorisation supplémentaire. Ils les interprètent généralement comme une condition d'erreur de type « ». La RFC 7208 considère que la présence de plusieurs enregistrements SPF rend l'évaluation invalide, et lors des vérifications en conditions réelles, cela se traduit généralement par une erreur « SPF PermError ». Cela signifie que le serveur destinataire ne peut pas considérer le SPF comme un résultat de validation normal.

Cette erreur technique a des répercussions sur l'activité. Un e-mail légitime peut être marqué comme spam, filtré de manière plus stricte ou rejeté. Au fil du temps, les enregistrements en double peuvent entraîner une charge administrative supplémentaire, nuire à la délivrabilité des e-mails et porter atteinte à la réputation d' de l'expéditeur, car les problèmes d'authentification répétés affaiblissent la confiance accordée au domaine.

Comment se produit la présence de plusieurs enregistrements SPF ?

La cause la plus fréquente est le changement sans consolidation. Lorsqu'une équipe ajoute Microsoft Exchange Online Protection, Google Workspace, Amazon SES, un CRM, une plateforme d'assistance ou un service marketing, le guide de configuration du fournisseur fournit un nouvel exemple d'enregistrement SPF de type « ». Au lieu d'intégrer ce nouveau mécanisme à l'enregistrement SPF existant, quelqu'un publie un enregistrement SPF distinct.

Ce phénomène est particulièrement fréquent dans les grandes entreprises, où les paramètres DNS sont modifiés par différentes équipes et où personne n’assume la responsabilité de l’authentification des e-mails de bout en bout. Ce phénomène se produit également lors de fusions, de migrations et de changements de fournisseur, lorsque les anciens et les nouveaux services d' s envoient des messages à partir du même domaine en même temps. Dans ces cas-là, la présence de plusieurs enregistrements reflète souvent une gestion fragmentée de l' , plutôt qu'une intention malveillante.

À quoi ressemble une erreur liée à la présence de plusieurs enregistrements SPF ?

Le signe le plus évident est l'apparition d'un résultat « SPF PermError » lors d'une vérification SPF, dans un outil de vérification SPF, dans l'en-tête d'un message ou dans un outil d'analyse de l' d'authentification. Un autre signe évident est une requête DNS qui révèle la présence de plusieurs enregistrements TXT commençant par « v=spf1 » pour le même nom d'hôte . 

Sur le plan opérationnel, ce problème se manifeste souvent par une défaillance soudaine du SPF après l'intégration d'un nouvel expéditeur. Vous pouvez également rencontrer des problèmes inexpliqués de classement dans la boîte de réception , même lorsque les expéditeurs visés sont légitimes. Si aucun autre facteur n'entre en jeu, mais que le taux de délivrabilité de baisse immédiatement après la mise en service d'une nouvelle plateforme, il convient de vérifier en premier lieu s'il existe des enregistrements SPF en double. 

Suggestion visuelle : ajoutez une capture d'écran d'un outil de vérification SPF affichant deux entrées « v=spf1 » et un résultat « SPF PermError ».

Comment vérifier si un nom de domaine comporte plusieurs enregistrements SPF ?

Commencez par la couche DNS. Vérifiez les enregistrements TXT du domaine et recherchez s'il existe plusieurs entrées « v=spf1 » associées au nom d'hôte exact utilisé pour l'envoi. Ne partez pas du principe que le domaine racine est le seul endroit à vérifier. Si des e-mails sont envoyés depuis un sous-domaine, effectuez également la recherche SPF sur pour ce sous-domaine.

Cette vérification est particulièrement importante après :

• Ajouter Google Workspace, Microsoft 365, Amazon SES ou une autre plateforme de messagerie externe
• Migrations DNS ou changements de registraire
• Déploiements de plateformes de sécurité ou autres mises à jour de l'infrastructure de messagerie électronique

C'est dans ces moments-là que des enregistrements SPF en double apparaissent le plus souvent.

Comment corriger plusieurs enregistrements SPF ?

La solution ne consiste pas à continuer à chercher les causes des doublons. Il s'agit de regrouper tous ces éléments en une seule politique SPF valide pour ce nom d'hôte, puis de vérifier qu'elle fonctionne comme prévu.

1. Rassemblez tous les enregistrements SPF existants. Répertoriez tous les enregistrements TXT SPF associés au domaine et à tous les sous-domaines concernés. Vérifiez attentivement votre zone DNS et dressez la liste de tous les noms d'hôte pour lesquels un enregistrement SPF est publié, afin de disposer d'un inventaire complet .
2. Passez en revue tous les mécanismes et toutes les inclusions. Passez en revue chaque enregistrement SPF et identifiez les sources d'envoi qui sont toujours légitimes et qui restent nécessaires. Vérifiez chaque entrée IPv4, IPv6, « include », « a » et « mx » par rapport à vos systèmes de messagerie actuels et afin de confirmer si cette source envoie toujours des e-mails pour ce domaine.
3. Supprimez les entrées obsolètes. Une fois que vous aurez identifié les sources valides, supprimez tout ce qui ne nécessite plus d' autorisation. Supprimez les plateformes obsolètes, les mécanismes redondants, les systèmes de test et les anciens services tiers qui ne font plus partie de votre flux de messagerie.
4. Créez un enregistrement SPF consolidé. Regroupez toutes les sources d'envoi requises dans une single politique v=spf1 pour ce nom d'hôte . N'ajoutez que les mécanismes dont vous avez encore besoin, classez-les dans un ordre logique et clair, puis terminez l'enregistrement par un qualificateur « » tel que ~all ou -all.
5. Vérifiez que le nouvel enregistrement SPF est valide. Avant de le publier en production, effectuez une vérification de l'enregistrement SPF via afin de vous assurer que la syntaxe est correcte, que le nombre de requêtes reste dans les limites autorisées et que l'enregistrement couvre toujours tous les expéditeurs légitimes . Corrigez tout problème de syntaxe ou de recherche avant de remplacer l'enregistrement en production.
6. Publiez l'enregistrement SPF unified et supprimez les enregistrements superflus. Mettez à jour le DNS de manière à ce que seule la nouvelle politique SPF consolidée soit conservée pour ce nom d'hôte. Supprimez également les enregistrements TXT SPF superflus plutôt que de les laisser en place aux côtés de le nouvel enregistrement.
7. Vérifiez qu'il n'existe qu'un seul enregistrement SPF. Une fois la publication effectuée, vérifiez à nouveau l'ensemble des enregistrements TXT DNS et assurez-vous qu'un seul enregistrement SPF est publié pour ce nom d'hôte. Si votre fournisseur DNS affiche plusieurs entrées TXT, vérifiez attentivement pour vous assurer que les anciens enregistrements SPF ont bien été entièrement supprimés.
8. Suivre la délivrabilité. Une fois l'enregistrement unified mis en service, surveillez attentivement le flux de courrier afin de détecter d'éventuels échecs SPF, des e-mails bloqués, des messages de type « » ou tout autre problème d'authentification. Vérifiez les messages de rejet, les journaux de messagerie ou les résultats d'authentification afin d'identifier les expéditeurs dont l' manque et de corriger les informations si nécessaire. 

L'objectif n'est pas simplement de corriger l'erreur. L'objectif est de disposer d'un enregistrement SPF valide, facile à gérer et conforme à tous les services d'envoi légitimes.

Comment fusionner correctement plusieurs enregistrements SPF ?

La fusion des enregistrements SPF ne se résume pas à regrouper du texte sur une seule ligne. L'objectif est d'élaborer une politique SPF claire et valide qui couvre tous les expéditeurs légitimes sans ajouter de complexité inutile.

Élaborer une politique claire en matière de SPF

Un enregistrement SPF fusionné et épuré regroupe des mécanismes tels que ip4, ip6, a, mx et include en une seule séquence logique, puis se termine par une politique claire telle que ~all ou -all. Voici à quoi devrait ressembler la fusion des enregistrements SPF. L'objectif est de disposer d'un single enregistrement SPF qui regroupe tous les expéditeurs légitimes.

Évitez la complexité lors de la fusion

Les principales erreurs commises lors de la fusion sont la duplication et une complexité excessive. Évitez les mécanismes redondants ou contradictoires, , et surveillez attentivement les inclusions multiples, car chaque requête DNS est comptabilisée dans la limite de requêtes DNS SPF. L' de « flattening » du SPF est parfois utilisée pour réduire ce nombre, mais même un enregistrement SPF fusionné techniquement valide peut devenir difficile à gérer si la propriété de l' est fragmentée.

Quel est l'impact de la présence de plusieurs enregistrements SPF sur le protocole DMARC et la délivrabilité ?

Le SPF n'est pas un système isolé. Lorsque SPF renvoie une erreur « PermError », il peut ne pas parvenir à fournir un résultat SPF aligné et exploitable pour le DMARC de. La situation s'aggrave lorsque l', le DKIM est absent, défectueux ou mal configuré, car le destinataire dispose alors de moins de signaux d'authentification valides auxquels se fier. 

Concrètement, la présence d'enregistrements SPF en double peut entraîner un filtrage par les filtres anti-spam, un risque de rejet et une moins bonne délivrabilité dans la boîte de réception. Les erreurs d'authentification répétées affaiblissent également, au fil du temps, la confiance accordée au domaine expéditeur ; c'est pourquoi il est important de mettre en place des rapports DMARC plus rigoureux . C'est pourquoi il s'agit à la fois d'un problème de sécurité des e-mails et d'un problème de délivrabilité. Un outil de vérification des enregistrements DMARC, tel que, peut vous aider à avoir une vue d'ensemble de la situation, mais son efficacité repose tout de même sur des données d'authentification SPF valides. 

Que se passe-t-il lorsque vous avez plusieurs expéditeurs mais un seul enregistrement SPF ?

Le fait d'avoir plusieurs expéditeurs ne signifie pas que vous ayez besoin de plusieurs enregistrements SPF. A single enregistrement SPF peut autoriser de nombreuses sources d' s d'envoi via des mécanismes tels que ip4, ip6, mx et include. C'est la bonne façon de gérer un domaine en utilisant simultanément plusieurs services de messagerie légitimes .

La distinction essentielle porte sur la présence d'expéditeurs multiples et de politiques SPF multiples. Une seule politique SPF doit prendre en compte tous les services approuvés par , plutôt que de publier des enregistrements distincts pour un même nom d'hôte. Même après la consolidation, la complexité continue de générer des risques. Un nombre trop élevé d'instructions « include » peut faire approcher l'enregistrement de la limite des 10 recherches DNS, et même un enregistrement techniquement valide ( ) peut s'avérer difficile à gérer si la responsabilité de sa gestion est répartie entre plusieurs équipes.

Bonnes pratiques pour une meilleure gestion des enregistrements SPF

Les problèmes liés au SPF tiennent souvent moins à la syntaxe qu'à la responsabilité et au contrôle des modifications. Une gestion quotidienne plus rigoureuse permet d'éviter les doublons, de réduire les erreurs d'authentification et de faciliter la mise à jour des politiques au fil du temps.

• Définissez clairement les responsabilités en matière de SPF et d'autorisation des expéditeurs sortants au sein des différentes équipes.
• Veuillez examiner la politique SPF en vigueur avant de mettre en place toute nouvelle plateforme de messagerie ou de faire appel à un nouveau prestataire.
• Répertoriez chaque expéditeur autorisé, précisez la raison de son inclusion et indiquez qui en est responsable.
• Vérifiez régulièrement les paramètres DNS et d'authentification après tout changement d'infrastructure ou de fournisseur.

• Keep one single record per nom d'hôte et n'utilisez des enregistrements SPF distincts que pour les sous-domaines qui envoient réellement des e-mails de manière indépendante.

Ces bonnes pratiques permettent d'améliorer la visibilité à long terme, la maîtrise des changements et les pratiques en matière d'authentification des e-mails. Elles facilitent également la gestion de l' e SPF à mesure que les listes d'expéditeurs s'allongent et évoluent.

Facilitez la gestion de plusieurs enregistrements SPF 

Le point essentiel à retenir est simple : un domaine ou un nom d'hôte ne doit comporter qu'un seul enregistrement SPF, et non plusieurs enregistrements SPF contradictoires. La présence de plusieurs enregistrements SPF n'améliore pas l'authentification. Elles génèrent des erreurs, généralement de type « SPF PermError », et ces erreurs peuvent nuire à la délivrabilité des e-mails, à la confiance accordée à l'expéditeur et à l'efficacité opérationnelle.