« Utiliser ?all dans un enregistrement SPF, c’est le signe que la personne qui l’a écrit ne sait pas ce qu’elle fait », écrivait Laura Atkins, fondatrice de Word to the Wise, dans un article publié sur le blog en 2016. Dix ans plus tard, ce genre d’erreur de syntaxe coexiste toujours avec des pannes bien plus discrètes.
Un enregistrement SPF casse rarement dès sa création. Il casse des mois ou des années plus tard, quand un cinquième outil d’envoi vient s’ajouter aux quatre précédents sans qu’aucun ne soit retiré. La conséquence directe est un PermError qui invalide l’authentification pour tout le domaine, pas seulement pour le nouvel expéditeur.
Les erreurs SPF les plus fréquentes et leur symptôme
La documentation officielle de Google et Microsoft décrit la syntaxe attendue. Elle dit rarement ce qui se passe quand un enregistrement valide au départ accumule des includes année après année jusqu’à franchir une limite que personne ne surveille. Cette dérive, parfois appelée SPF drift, produit la majorité des pannes réelles.
| Erreur | Symptôme observé | Correction |
|---|---|---|
| Deux enregistrements SPF sur un domaine | PermError systématique, vérificateur signale un doublon | Fusionner en un seul TXT commençant par v=spf1 |
| Plus de 10 lookups DNS | PermError intermittent selon le receveur | Remplacer les includes par des mécanismes ip4/ip6, retirer les prestataires abandonnés |
| Plus de 2 lookups vides | PermError même sous la limite de 10 | Nettoyer les mécanismes qui pointent vers un enregistrement DNS inexistant |
| Syntaxe invalide (guillemets, espace, v=spf1 mal écrit) | SoftFail ou Neutral inattendu, alignement DMARC cassé | Vérifier avec dig txt puis un analyseur syntaxique |
| +all au lieu de -all ou ~all | N’importe quel serveur peut se faire passer pour le domaine | Passer à -all une fois tous les expéditeurs identifiés |
Deux enregistrements SPF sur le même domaine
La RFC 7208, qui définit le protocole SPF, autorise un seul enregistrement SPF par domaine. Deux enregistrements présents en même temps ne s’additionnent pas. Le serveur receveur ne sait plus lequel appliquer et renvoie une erreur permanente. Le cas type se produit lors d’une migration d’ESP, quand l’équipe technique ajoute le nouveau TXT recommandé par Salesforce ou SendGrid sans supprimer celui laissé par l’ancien prestataire. La correction consiste à fusionner tous les mécanismes include dans une seule ligne, sans en choisir un des deux au hasard.
Dépasser la limite de 10 lookups DNS
Chaque mécanisme include, a, mx, ptr, exists déclenche une requête DNS. Le total, includes imbriqués compris, ne doit jamais dépasser 10 par vérification. Une entreprise qui empile au fil du temps Google Workspace, Salesforce, HubSpot, SendGrid, un outil de facturation atteint facilement cette limite sans jamais avoir touché directement le champ include. Un include compte pour un lookup à lui seul ; chaque include imbriqué à l’intérieur en ajoute d’autres, souvent invisibles depuis l’enregistrement racine.
Ce budget bouge aussi sans intervention du domaine. Google a modifié son propre enregistrement _spf.google.com en décembre 2025, faisant passer sa consommation de 4 à 1 lookup pour tout domaine qui l’inclut via include:_spf.google.com. Les domaines qui utilisaient la syntaxe recommandée en ont bénéficié automatiquement. Ceux qui avaient codé en dur les sous-enregistrements _netblocks2 ou _netblocks3 se sont retrouvés avec des références mortes à nettoyer.
EchoSpoofing : ce qu’un include délègue vraiment
Compter les lookups ne suffit pas. Un include délègue une partie de la confiance du domaine à l’infrastructure d’un tiers, bien au-delà de la charge DNS qu’il ajoute. Entre janvier et juin 2024, Guardio Labs a documenté une faille baptisée EchoSpoofing : des attaquants ont exploité des permissions laxistes chez Proofpoint pour relayer des emails usurpant Disney, Nike, IBM, Coca-Cola, avec une moyenne de 3 millions d’envois quotidiens et des pics à 14 millions. Les messages passaient les vérifications SPF et DKIM parce qu’ils transitaient réellement par les serveurs autorisés du prestataire.
La leçon délivrabilité ne concerne pas que les cibles de la campagne. Chaque include ajouté dans un enregistrement SPF importe la posture de sécurité de ce prestataire, ses contrôles d’accès, ses éventuelles failles de configuration. Retirer les includes de services abandonnés réduit autant l’exposition à la sécurité de tiers que le nombre de lookups DNS à économiser.
Qualifieurs et syntaxe : ce qui invalide tout l’enregistrement
Un enregistrement SPF techniquement correct peut rester inefficace à cause du qualifieur choisi en fin de ligne. -all rejette formellement tout expéditeur non listé, ~all les marque en échec souple sans les bloquer, ?all les traite en neutre. En production, évitez toujours +all : il autorise littéralement n’importe quel serveur à envoyer au nom du domaine, ce qui annule l’intérêt même du SPF.
Les fautes de syntaxe restent la source d’erreur la plus banale : un espace manquant entre deux mécanismes, des guillemets courbes copiés depuis un traitement de texte ou v=spf1 tapé avec une faute qui rend l’enregistrement illisible pour l’évaluateur. Ce dernier cas produit un enregistrement TXT présent dans le DNS mais totalement ignoré, comme s’il n’existait pas.
La checklist de diagnostic dans l’ordre
Testez dans cet ordre plutôt qu’au hasard. Chaque étape écarte une catégorie d’erreur avant de passer à la suivante.
- Vérifiez le nombre d’enregistrements SPF avec dig txt votredomaine.com. Un seul résultat commençant par v=spf1 doit apparaître.
- Comptez les lookups DNS avec l’outil SPF Surveyor de dmarcian ou MXToolbox. Au-delà de 10, identifiez quels includes sont encore utilisés.
- Repérez les lookups vides, ceux qui pointent vers un mécanisme sans enregistrement DNS correspondant. Deux suffisent à déclencher un PermError.
- Validez la syntaxe caractère par caractère, en particulier les guillemets et les espaces entre mécanismes.
- Vérifiez le qualifieur final. -all en production, jamais +all.
- Envoyez un email de test et lisez l’en-tête Received-SPF sur le serveur receveur pour confirmer le résultat réel, pas seulement ce qu’affiche un vérificateur en ligne.
La majorité des pannes se résolvent aux deux premières étapes. Le reste tient à des cas plus rares : sous-domaine sans son propre enregistrement, redirection mal configurée ou service tiers qui a changé son propre include sans prévenir ses clients, comme Google l’a fait en décembre 2025.
Ce qu’un DMARC pass ne garantit pas sur votre SPF
Un enregistrement SPF au-delà de la limite de lookups peut continuer à afficher pass dans les rapports agrégés DMARC. Cela s’explique par une limite de la donnée disponible plutôt que par une erreur de mesure.
Un rapport DMARC agrégé ne prouve pas qu’un chemin d’évaluation SPF est valide dans tous les cas. Un domaine peut afficher 12 lookups dans un vérificateur tout en montrant un résultat pass dans ses rapports. Ces rapports reflètent ce qu’un lot de receveurs a effectivement constaté. Ils ne couvrent pas l’ensemble des chemins d’évaluation possibles.
Selon les observations publiées par Suped en 2025, traiter un enregistrement au-delà de la limite comme cassé en production reste la bonne approche, même quand policy_evaluated affiche une disposition none et un résultat SPF favorable dans le parsedmarc du mois. Un receveur strict, différent de ceux qui ont généré le rapport, peut appliquer la limite à la lettre et rejeter.
Côté diagnostic opérationnel, un email rejeté pour cause de SPF génère généralement un code 550 5.7.1 (autorisation refusée) dans les journaux SMTP, parfois classé à tort comme un vrai hard bounce d’adresse invalide par des outils de suivi qui ne distinguent pas les sous-codes. Avant de retirer une adresse de la Suppression List sur la base de ce type de code, vérifiez si le rejet vient de l’adresse elle-même ou de l’authentification du domaine expéditeur : un nettoyage de liste fondé sur le mauvais motif abîme la donnée sans réduire le risque réel qui a déclenché le rejet.
Questions fréquentes
Un sous-domaine hérite-t-il de l’enregistrement SPF du domaine racine ?
Non. SPF ne s’hérite pas automatiquement entre domaine racine et sous-domaine. Chaque sous-domaine qui envoie du courrier a besoin de son propre enregistrement TXT v=spf1, sinon il échoue par défaut à la vérification.
Combien de temps avant qu’une correction SPF soit visible ?
Le TTL du record TXT détermine la propagation, généralement entre quelques minutes et 24 heures selon le registrar. Vérifiez avec dig avant de considérer la correction effective auprès de tous les receveurs.
Un enregistrement v=spf1 -all est-il valide pour un domaine qui n’envoie jamais de courrier ?
Oui, c’est même la configuration recommandée pour un domaine de parking. Elle refuse systématiquement toute tentative d’envoi en son nom et bloque une usurpation avant même qu’elle n’atteigne la boîte du destinataire.
SPF ne vérifie jamais qui vous êtes. Il vérifie seulement qui a le droit de parler en votre nom, pour combien de temps encore ce droit reste à jour.
