Enregistrement SPF : syntaxe, limite DNS et corrections

Un enregistrement SPF est une entrée TXT publiée dans le DNS de votre domaine. Elle liste les serveurs autorisés à envoyer du courrier avec ce domaine comme expéditeur d'enveloppe. Le serveur destinataire compare l'adresse IP qui se connecte à cette liste et renvoie un verdict : pass, fail, softfail ou neutral. L'enregistrement SPF authentifie le chemin d'envoi, pas le message, et ne dit rien de l'adresse From que lit une personne.

C'est cette confusion qui explique la plupart des tickets SPF que nous voyons dans les traces.

Un enregistrement SPF est une liste d'expéditeurs autorisés, publiée dans le DNS

SPF signifie Sender Policy Framework, défini dans la RFC 7208. L'enregistrement est une entrée TXT à la racine du domaine, qui commence par v=spf1. Voici un exemple minimal :

example.com.  IN  TXT  "v=spf1 ip4:203.0.113.10 include:_spf.provider.example ~all"

Lisez-le de gauche à droite. Le récepteur vérifie chaque terme dans l'ordre et s'arrête au premier qui correspond. Le terme all final attrape tout ce qui n'a pas correspondu avant lui.

Le domaine vérifié n'est pas celui de l'en-tête From. C'est celui de la commande SMTP MAIL FROM, appelé expéditeur d'enveloppe ou Return-Path. Si cette valeur est vide, comme sur les rebonds, le récepteur se rabat sur le nom annoncé dans HELO.

Les mécanismes : ip4, ip6, a, mx, include, exists

Chaque terme est un mécanisme, éventuellement précédé d'un qualificateur. Six mécanismes suffisent pour couvrir presque tous les enregistrements réels.

• ip4: et ip6: correspondent à une adresse littérale ou à une plage CIDR. Ils ne coûtent aucune requête.

• a correspond aux enregistrements A ou AAAA d'un domaine. Il coûte une requête.

• mx correspond aux hôtes listés dans les enregistrements MX du domaine. Il coûte une requête, plus une par hôte.

• include: correspond à tout ce que l'enregistrement SPF d'un autre domaine correspond. Il coûte une requête, plus tout ce qui est imbriqué à l'intérieur.

• exists: correspond à tout enregistrement A d'un nom construit. Il coûte une requête.

• ptr correspond à la résolution inverse de l'IP qui se connecte. Il coûte des requêtes, et la RFC 7208 déconseille de l'utiliser.

Les qualificateurs fixent le résultat quand un terme correspond. + signifie pass et est la valeur par défaut, - signifie fail, ~ signifie softfail, ? signifie neutral. Ainsi, -all veut dire « rejeter tout ce qui n'est pas listé », et ~all veut dire « accepter mais signaler ».

Privilégiez ip4: et ip6: chaque fois que vous contrôlez l'adresse. Ils ne coûtent aucune requête et ne peuvent pas casser quand le DNS de quelqu'un d'autre change.

La limite de 10 requêtes DNS casse les vrais enregistrements

La RFC 7208 plafonne une évaluation SPF à 10 termes qui déclenchent une requête DNS : include, a, mx, ptr, exists, et le modificateur redirect. Les include imbriqués comptent aussi. Au-delà de 10, le résultat est permerror et la vérification échoue de façon définitive, sans retomber sur une autre valeur.

Une seconde limite attire moins l'attention. Les termes qui renvoient une réponse vide ou un NXDOMAIN sont des void lookups, et la norme demande de s'arrêter à deux. Un include: périmé qui pointe vers un fournisseur abandonné l'an dernier est un void lookup que vous continuez à payer.

Voici comment les équipes atteignent réellement le plafond. Google Workspace prend un include. Un fournisseur transactionnel en prend un. Une plateforme marketing en prend un, et en imbrique trois autres. Un outil de support, un CRM et un outil de facturation en ajoutent quatre. Vous êtes à 11 sans avoir rien fait d'inhabituel.

L'échec est silencieux. Le courrier part encore, et certains récepteurs le délivrent malgré tout, mais SPF n'authentifie plus rien pour vous. Si votre alignement DMARC passe par SPF, ce chemin est coupé tant que vous n'aplatissez pas l'enregistrement ou ne retirez pas d'expéditeurs.

Trois corrections fonctionnent, par ordre de préférence :

1. Retirez les expéditeurs que vous n'utilisez plus. Auditez les include à partir de vos 90 derniers jours de rapports agrégés DMARC.

2. Déplacez le trafic en masse vers un sous-domaine, comme mail.example.com, avec son propre enregistrement SPF et son propre budget de 10 requêtes.

3. Aplatissez les include en plages ip4: littérales, mais seulement avec de l'automatisation. Les fournisseurs changent d'IP, et un enregistrement aplati à la main devient obsolète sans aucune alerte.

Publiez un seul enregistrement SPF par domaine

Un domaine ne doit pas publier deux enregistrements SPF. Si un récepteur trouve deux entrées TXT v=spf1, le résultat est permerror, comme pour la limite de requêtes. Cela arrive quand une personne ajoute un enregistrement pour un nouvel outil pendant qu'une autre en a déjà un en place.

La correction est mécanique. Fusionnez les termes dans un seul enregistrement, avec un seul v=spf1 au début et un seul all à la fin. Tout ce que la documentation du fournisseur vous demande d'ajouter va dans l'enregistrement existant, sous forme d'un include: de plus, jamais comme une nouvelle entrée TXT.

Deux pièges plus petits. Une chaîne TXT de plus de 255 caractères doit être découpée en plusieurs chaînes entre guillemets dans le même enregistrement, ce que la plupart des hébergeurs DNS font pour vous. Et gardez la réponse complète sous environ 450 octets si vous le pouvez, car les réponses plus grosses peuvent basculer de l'UDP vers le TCP, et certains résolveurs gèrent mal cette bascule.

Softfail ou hardfail : choisissez selon ce que vous voyez

Le terme all est une déclaration de politique, et le conseil par défaut (« utilisez -all ») passe à côté de l'essentiel. Un hard fail n'est sûr que si vous connaissez chaque expéditeur légitime.

Notre règle empirique, tirée de la lecture de traces :

• ~all tant que vous recensez encore les expéditeurs, ou si vous transférez du courrier et ne contrôlez pas le chemin.

• -all une fois que les rapports DMARC montrent que chaque source légitime passe, pendant quelques semaines.

• Jamais +all, qui autorise l'internet entier, et jamais ?all sur un domaine de production.

Dans la pratique, la différence est plus petite qu'on ne le pense. La plupart des gros récepteurs traitent SPF comme un signal parmi d'autres, et avec une politique DMARC en place, c'est le verdict DMARC qui tranche. Cela dit, un -all sur un enregistrement incomplet, c'est la façon la plus sûre de perdre des factures.

SPF casse au transfert, et c'est voulu

SPF valide l'IP qui s'est connectée au serveur récepteur. Quand un message est transféré, qu'une liste de diffusion le redistribue ou qu'un service d'alias le relaie, l'IP connectée est celle du relais, pas la vôtre. La vérification SPF échoue alors, même si vous n'avez rien fait de mal.

Vous ne pouvez pas corriger cela à l'intérieur de SPF. C'est la raison pour laquelle DKIM existe à côté : une signature traverse le saut, une liste d'IP ne le traverse pas. Un domaine qui s'appuie sur SPF seul verra des échecs d'authentification sur chaque message transféré.

C'est aussi pourquoi SPF seul ne satisfait pas DMARC pour le courrier transféré. Prévoyez que DKIM porte ces messages.

Alignement SPF : réussir ne veut pas dire correspondre à votre domaine From

Un message peut réussir SPF et échouer quand même à DMARC. DMARC exige que le domaine qui a réussi SPF, celui du Return-Path, corresponde au domaine From visible. De nombreux fournisseurs mutualisés utilisent par défaut leur propre domaine de rebond. SPF passe alors pour provider-mail.net et ne dit rien de example.com.

Vérifiez cela dans les en-têtes bruts. Dans la ligne Authentication-Results, regardez smtp.mailfrom=. Si ce n'est pas votre domaine ou un sous-domaine de celui-ci, SPF passe sans vous aider.

Le remède est un Return-Path personnalisé sur votre propre sous-domaine, ce que la plupart des expéditeurs sérieux supportent. Postmark, Resend, Mailgun et SendGrid documentent tous cette configuration, même si elle n'est pas toujours activée par défaut.

Les fournisseurs de boîtes de réception exigent désormais une authentification

Depuis février 2024, Google impose à tous les expéditeurs de s'authentifier avec SPF ou DKIM. Les expéditeurs de plus de 5 000 messages par jour vers Gmail doivent avoir SPF, DKIM et DMARC en place. Les détails figurent dans les consignes de Google pour les expéditeurs de courrier. Yahoo a fixé des règles de correspondance au même moment.

SPF est ainsi passé de « utile » à un prérequis de délivrabilité. Un enregistrement absent ou cassé se traduit désormais par des rejets et du spam, pas seulement par un score de réputation plus bas.

À l'usage, voilà ce que nous observons après quelques années de traces : les règles attrapent surtout les domaines sans aucune authentification et les expéditeurs à fort taux de plaintes. Un enregistrement SPF correct ne vous fera pas entrer dans la boîte de réception à lui seul, mais un enregistrement absent vous en gardera éloigné.

Vérifier et corriger un enregistrement SPF en quatre étapes

Suivez ces étapes dans l'ordre, et revérifiez après chaque modification DNS.

1. Consultez l'enregistrement actuel. Lancez dig +short TXT example.com et repérez l'entrée qui commence par v=spf1. S'il y en a deux, fusionnez-les.

2. Comptez les requêtes. Additionnez include, a, mx, exists, redirect et tout ce qui est imbriqué dans les include. Si vous êtes à 8 ou plus, planifiez le nettoyage maintenant, pas au onzième.

3. Listez les vrais expéditeurs. Utilisez les rapports DMARC agrégés ou les en-têtes Authentication-Results de vos envois de test. N'ajoutez que les sources qui apparaissent.

4. Envoyez un test et lisez l'en-tête. Le résultat doit afficher spf=pass avec smtp.mailfrom sur votre domaine.

La propagation DNS prend du temps, et le TTL de votre enregistrement actuel détermine la durée de vie des anciennes réponses. Abaissez-le à 300 secondes la veille d'un changement planifié.

Un exemple complet pour une SaaS avec trois expéditeurs

Prenons un produit qui envoie depuis Google Workspace, un fournisseur transactionnel et un outil de support. Un enregistrement propre ressemble à ceci :

example.com.  IN  TXT  "v=spf1 include:_spf.google.com include:spf.transactional.example include:spf.helpdesk.example -all"

Ce sont trois include, et chacun cache ses propres requêtes imbriquées. Comptez-les avant de publier, car la longueur visible ne dit rien du vrai budget. Un enregistrement avec trois include peut déjà se situer entre 7 et 8 requêtes.

Découpez ensuite par usage. Gardez le courrier humain sur le domaine racine. Placez les notifications produit sur notify.example.com, avec un enregistrement qui ne liste que le fournisseur transactionnel. L'enregistrement racine reste court, le sous-domaine obtient son propre budget de 10 requêtes, et un problème de réputation sur un flux n'entraîne plus l'autre.

Cette séparation rend aussi les rapports DMARC lisibles. Chaque flux a son propre domaine Return-Path, donc un échec désigne un seul expéditeur au lieu d'un tas.

Ce que SPF ne fera pas

Il n'empêchera pas quelqu'un d'usurper votre adresse From, car il ne regarde jamais cet en-tête. Il ne chiffre rien. Il ne vous dira pas pourquoi un message a atterri dans le spam. Et il ne passera pas à l'échelle au-delà du budget de 10 requêtes sans maintenance continue.

Traitez-le comme l'un des trois enregistrements à publier ensemble : SPF pour le chemin d'envoi, DKIM pour l'intégrité du message, DMARC pour la politique qui les relie à votre domaine From. Si vous avez SPF et rien d'autre, l'étape suivante concrète est de publier un enregistrement DMARC en p=none et de lire les rapports pendant deux semaines.