Syntaxe des enregistrements SPF : composants et règles de structuration

Le SPF semble souvent simple, jusqu'à ce que vous deviez créer ou dépanner l'enregistrement vous-même. Le problème ne se limite pas à savoir quels expéditeurs autoriser. Il s'agit de savoir les exprimer correctement dans le système de noms de domaine afin que les serveurs destinataires puissent interpréter la politique conformément à votre intention.

Qu'est-ce que la syntaxe d'un enregistrement SPF ?

La syntaxe des enregistrements SPF désigne la structure et les règles de mise en forme utilisées pour créer un enregistrement TXT SPF valide. Concrètement, il s'agit du langage utilisé par un domaine dans le DNS pour indiquer à un serveur destinataire quelles sources de messagerie sont autorisées à envoyer des messages en son nom.

Cela est important car la syntaxe SPF détermine la manière dont les sources d'envoi autorisées sont exprimées dans un enregistrement TXT du DNS. Si la syntaxe est incorrecte, l'authentification SPF peut échouer même si les expéditeurs autorisés figurent bien dans la liste. Cela permet également de distinguer la syntaxe de la stratégie : la syntaxe SPF constitue la couche de mise en forme qui rend une politique lisible pour les systèmes de messagerie, tandis que la stratégie détermine quels expéditeurs autoriser et quel doit être le niveau de rigueur de la politique.

Éléments essentiels de la syntaxe des enregistrements SPF

Un enregistrement SPF est constitué d'un petit nombre d'éléments essentiels : la balise de version, les mécanismes, les qualificatifs et les modificateurs. Ensemble, ils indiquent au serveur destinataire ce qu’il doit vérifier, comment interpréter le résultat et comment réagir lorsqu’aucun mécanisme antérieur ne correspond. La spécification traite différemment les mécanismes et les modificateurs, même si les deux apparaissent dans le même enregistrement TXT.

Mécanismes de protection solaire (SPF)

Les mécanismes correspondent aux termes de correspondance dans un enregistrement SPF. Ils définissent quelles sont les sources autorisées. Dans les dossiers concrets, les cas les plus courants sont les suivants :

• ip4 et ip6 pour des plages IPv4 ou IPv6 spécifiques
• a) pour autoriser l'adresse IP renvoyée par un enregistrement A ou AAAA
• mx afin d'autoriser les adresses IP des serveurs associés à l'enregistrement MX du domaine
• inclure pour faire référence à la politique SPF d'un autre domaine et l'évaluer
• tout cela en tant que dernier recours

Ces mécanismes sont courants, car ils reflètent la manière dont les e-mails d'entreprise sont généralement acheminés. Les adresses IPv4 et IPv6 sont utilisées pour les infrastructures d'envoi connues ; l'enregistrement « mx » est courant lorsque le serveur de messagerie du domaine envoie également des e-mails ; et l'enregistrement « include » est largement utilisé pour les plateformes cloud telles que Microsoft 365 et Google Workspace.

Vous pouvez également rencontrer les mots-clés « exists » ou « ptr », mais ces deux-là nécessitent une certaine prudence. Le RFC du SPF indique explicitement de ne pas utiliser « ptr », et la fonction « exists » est plus complexe et plus susceptible d'entraîner des erreurs que les mécanismes sur lesquels s'appuient la plupart des organisations.

Épreuves de qualification pour le SPF

Un qualificatif modifie le sens d'un mécanisme. Les résultats concrets sont les suivants :

• + pass, bien que le signe « plus » soit généralement sous-entendu
• - échec
• ~ softfail
• ? neutre

Ces qualificatifs influencent la manière dont les vérifications SPF sont interprétées par le serveur destinataire. Une politique de fermeture plus stricte, telle que -all, indique au destinataire que tout message ne correspondant pas aux critères doit échouer au test SPF.

Une approche de fermeture plus souple, telle que ~all, indique que les sources non appariées doivent plutôt faire l'objet d'un « softfail » ; cette méthode est souvent utilisée pendant les phases de transition ou lorsque les listes d'expéditeurs sont encore en cours de nettoyage. Dans la pratique, ce choix a des répercussions sur l'application des règles, le dépannage et, parfois, le classement des e-mails dans la boîte de réception en aval.

Modificateurs SPF

Les modificateurs sont des éléments syntaxiques spécifiques qui étendent le fonctionnement du SPF plutôt que de vérifier directement l'identité des expéditeurs. Les plus pertinentes pour la plupart des lecteurs issus du monde de l'entreprise sont « redirect » et « exp ». La RFC SPF définit le paramètre « redirect » pour déléguer l'évaluation à la politique SPF d'un autre domaine, et le paramètre « exp » pour renvoyer une explication personnalisée en cas d'échec.

Cela diffère des mécanismes. Les mécanismes interviennent directement dans la mise en correspondance, tandis que les modificateurs modifient la manière dont l'enregistrement est traité. Dans des environnements plus complexes, la redirection peut s'avérer utile lorsque plusieurs domaines partagent le même système de messagerie et qu'une seule politique doit s'appliquer à plusieurs domaines liés. La RFC recommande également de placer la redirection à la fin de l'enregistrement, par souci de clarté.

Balises de version SPF

Chaque enregistrement SPF doit commencer par « v=spf1 ». Il s'agit de la balise d'ouverture obligatoire qui identifie l'enregistrement TXT DNS comme une politique SPF. Les serveurs destinataires utilisent cette balise pour savoir que l'enregistrement doit être évalué à l'aide des règles SPF. Si l'indicateur de version est manquant, en double ou mal formé, l'enregistrement peut être considéré comme non valide.

À quoi ressemble un enregistrement SPF valide ?

La structure standard d'un enregistrement SPF valide est simple : elle commence par l'indicateur de version, est suivie d'un ou plusieurs mécanismes, peut inclure des modificateurs, puis se termine par une politique de fermeture. En termes plus simples, un enregistrement SPF valide respecte une structure claire que les serveurs destinataires peuvent analyser sans ambiguïté.

Voici un exemple simple d'enregistrement SPF :

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

Pourquoi cela est-il valable :

• v=spf1 identifie l'enregistrement comme étant un enregistrement SPF
• inclut : _spf.google.com autorise l'infrastructure d'envoi de Google Workspace
• ~all définit une politique de « softfail » pour les sources non correspondantes

Voici un exemple d'enregistrement SPF plus avancé :

v=spf1 ip4:192.168.0.10 include:spf.protection.outlook.com -all

Pourquoi cela est-il valable :

• « v=spf1 » est la balise de version requise
• ip4:192.168.0.10 autorise une adresse IP spécifique
• inclut : spf.protection.outlook.com autorise les expéditeurs de Microsoft 365
• -all définit un échec strict pour tout le reste

Dans ces deux exemples, la syntaxe SPF est correcte, car l'enregistrement commence correctement, utilise des mécanismes reconnus et se termine par une politique claire. La stratégie diffère, mais la structure reste la même.

Règles et validation pour un format SPF correct

La validité d'un enregistrement SPF dépend d'un formatage précis. L'enregistrement doit commencer correctement, respecter les conventions SPF reconnues et respecter un ordre logique, car les systèmes DNS et de messagerie ne tolèrent pas les entrées mal formées.

Commencez par choisir la balise de version appropriée

Chaque enregistrement SPF doit commencer par « v=spf1 ». Si l'indicateur de version est manquant, en double ou incorrect, l'enregistrement peut être considéré comme non valide. SPF n'utilise qu'une seule balise de version valide ; il n'existe donc aucune autre chaîne de version SPF que vous devriez utiliser à la place.

N'utilisez que les termes SPF reconnus

Les mécanismes, les qualificatifs et les modificateurs doivent respecter la syntaxe SPF valide. Des termes non reconnus ou mal placés peuvent fausser l'évaluation. Le fait de n'utiliser que des termes SPF pris en charge contribue également à garantir la prévisibilité de la politique pour les serveurs destinataires et facilite sa mise à jour à mesure que les services d'envoi évoluent.

Veillez à ce que les enregistrements soient classés de manière logique

Les enregistrements SPF doivent être structurés de manière claire afin que les mécanismes, les critères de sélection et les modificateurs soient faciles à évaluer et à gérer. Une structure plus claire facilite également le dépannage lorsqu'un service d'envoi change ou qu'un problème d'authentification survient.

Soyez attentif aux erreurs de syntaxe courantes

Parmi les problèmes de syntaxe courants, on peut citer :

• v=spf1 manquant
• Qualificateurs en double ou mal formés
• Termes non reconnus
• Trop de recherches imbriquées via « include », « a » ou « mx »
• Tentatives incorrectes de combinaison de plusieurs enregistrements SPF
• Classement des termes dans un ordre prêtant à confusion ou incorrect

Même de petites erreurs de mise en forme peuvent entraîner l'échec de la validation SPF, ce qui peut affaiblir votre stratégie globale d'authentification des e-mails avant même que le protocole DMARC et les rapports ne puissent remplir leur rôle. C'est pourquoi les vérifications syntaxiques devraient être effectuées à chaque mise à jour d'un enregistrement, et pas seulement lors de la configuration initiale.

Ne publiez qu'une seule politique SPF par nom d'hôte

Un domaine ne doit pas publier plusieurs enregistrements SPF pour un même nom d'hôte. Une combinaison incorrecte de plusieurs enregistrements SPF peut entraîner des problèmes de validation SPF et des échecs d'authentification.

Respectez les bonnes pratiques de base en matière de SPF

Commencez toujours par « v=spf1 », veillez à ce que la syntaxe soit correcte et vérifiez régulièrement cet enregistrement à mesure que les services d'envoi évoluent. De petits problèmes de syntaxe peuvent entraver l'authentification SPF ; c'est pourquoi des vérifications régulières font partie d'une bonne gestion à long terme des enregistrements.

L'objectif n'est pas seulement de garantir la validité technique du record. L'objectif est de veiller à ce que la configuration SPF reste suffisamment claire pour que les modifications n'entraînent pas de nouveaux problèmes de syntaxe au fil du temps ; c'est pourquoi il est utile de valider les mises à jour à l'aide d'une vérification de l'enregistrement SPF.

Comment devez-vous structurer les enregistrements SPF lorsque vous avez plusieurs expéditeurs ?

De nos jours, les entreprises envoient rarement leurs e-mails à partir d'un seul et même endroit. Un même domaine peut être amené à autoriser des serveurs internes, Microsoft Exchange, Google Workspace, des plateformes d'assistance et d'autres services tiers au sein d'un single enregistrement SPF.

Pour que cela reste gérable :

• Veillez à ce que la structure soit claire afin que chaque mécanisme ait une finalité évidente
• N'utilisez que les expéditeurs dont vous avez réellement besoin afin d'éviter les inclusions obsolètes ou inutiles
• Limitez la complexité, car les enregistrements longs et à plusieurs niveaux sont plus difficiles à examiner et présentent un risque accru de défaillance
• Veuillez revoir régulièrement cette politique, car les services d'envoi évoluent au fil du temps

L'objectif n'est pas seulement l'exactitude, mais aussi la facilité de maintenance. Une bonne gestion du SPF favorise à la fois l'authentification SPF et la délivrabilité des e-mails à long terme.

Il est également utile de garder à l'esprit que le SPF ne constitue qu'un élément parmi d'autres de l'authentification des e-mails. Ce système fonctionne en complément de DomainKeys Identified Mail et d'une politique DMARC. Même un enregistrement TXT SPF valide ne résout pas à lui seul tous les problèmes de sécurité liés aux e-mails, mais une syntaxe correcte de l'enregistrement SPF reste un point de contrôle indispensable, car un enregistrement erroné affaiblit l'authentification avant même que les politiques de niveau supérieur ne puissent jouer leur rôle.

Mettre en place des enregistrements SPF corrects

Le principal enseignement opérationnel à retenir est simple : la syntaxe des enregistrements SPF ne se résume pas à une simple question de mise en forme. C'est la couche de contrôle qui indique à un serveur destinataire comment déterminer quels expéditeurs sont autorisés à utiliser votre domaine. Si la syntaxe est incorrecte, l'authentification SPF peut échouer même si vos expéditeurs autorisés sont corrects.

C'est pourquoi la conception des enregistrements SPF doit trouver un juste équilibre entre exactitude et facilité de maintenance. Adoptez une structure claire, évitez les enregistrements SPF multiples, veillez à ce que les mécanismes soient pertinents et réexaminez régulièrement ces enregistrements à mesure que les services d'envoi évoluent. Un format d'enregistrement SPF clair facilite la gestion de ce processus au fil du temps.