Vérification SPF : contrôler un enregistrement v=spf1
La vérification SPF consiste à récupérer l'enregistrement TXT v=spf1 du domaine utilisé dans l'enveloppe SMTP, puis à confronter l'adresse IP du serveur qui se connecte aux mécanismes qu'il déclare. Elle tient en une commande dig côté administrateur, et se déroule automatiquement à chaque message côté récepteur, qui inscrit son verdict dans un en-tête Received-SPF.
Ce que la vérification SPF contrôle vraiment
Le serveur destinataire ne regarde pas l'adresse affichée dans votre logiciel de messagerie. Il retient le domaine passé dans la commande MAIL FROM du dialogue SMTP, ce qu'on appelle l'enveloppe ou le return-path, puis interroge le DNS de ce domaine à la recherche d'un enregistrement TXT commençant par v=spf1. Si l'IP qui vient d'ouvrir la connexion correspond à l'un des mécanismes autorisés, le verdict est pass.
La RFC 7208 prévoit une seconde identité : le nom annoncé dans HELO ou EHLO. Elle sert quand l'enveloppe est vide, cas des rapports de non-remise dont le MAIL FROM vaut la chaîne nulle. Certains serveurs vérifient les deux identités, d'autres se contentent de l'enveloppe.
La confusion classique porte sur l'en-tête From. Un message peut afficher From: service@votre-banque.fr, utiliser une enveloppe rebond@domaine-jetable.tld dont le SPF est parfaitement configuré, et obtenir spf=pass. La vérification n'a rien vu d'anormal parce qu'elle ne lit jamais cette ligne. C'est DMARC qui impose l'alignement entre les deux domaines.
Sept résultats sont définis par la RFC. Les connaître évite de lire un softfail comme une panne, ou un permerror comme un simple avertissement.
| Résultat | Qualificateur | Signification | Traitement courant |
|---|---|---|---|
| pass | + | IP autorisée par le domaine | Livraison normale |
| fail | - | IP explicitement rejetée | Rejet SMTP ou dossier indésirable |
| softfail | ~ | IP probablement non autorisée | Accepté puis marqué |
| neutral | ? | Le domaine ne se prononce pas | Équivalent à none |
| none | Aucun enregistrement, ou domaine inexistant | Aucun crédit d'authentification | |
| temperror | Panne DNS passagère | Report avec un code 4xx | |
| permerror | Syntaxe invalide ou limite dépassée | Souvent traité comme none |
Lire et tester l’enregistrement en ligne de commande
Une commande suffit pour l'inspection de base : dig +short TXT exemple.fr. La réponse ressemble à v=spf1 include:_spf.exemple.net ip4:203.0.113.25 -all. Sous Windows, Resolve-DnsName -Type TXT exemple.fr donne le même résultat sans installer dig.
Trois points se contrôlent à l'œil nu. L'enregistrement doit être unique : deux TXT commençant par v=spf1 sur le même nom produisent un permerror et l'authentification tombe pour tous vos envois. Il doit être publié sur le nom exact qui apparaît dans l'enveloppe, en général l'apex du domaine, jamais sur www. Il doit se terminer par un mécanisme all, sinon les IP non listées retombent en neutral.
Une chaîne TXT ne peut pas dépasser 255 octets. Un enregistrement plus long se publie en plusieurs chaînes que le résolveur concatène, et certaines interfaces de registrar gèrent mal cette découpe : vous obtenez deux enregistrements distincts au lieu d'un seul segmenté. La RFC 7208 recommande par ailleurs que la réponse tienne dans 512 octets. Le type d'enregistrement DNS 99, autrefois dédié à SPF, est abandonné depuis 2014 : publiez en TXT uniquement.
Pour un contrôle reproductible, checkdmarc (pip install checkdmarc, puis checkdmarc exemple.fr) renvoie un JSON contenant l'enregistrement, les inclusions résolues et le nombre de requêtes DNS consommées. Pour valider un envoi réel plutôt que la syntaxe, swaks permet de forcer une enveloppe précise et de relire les en-têtes ajoutés par le récepteur.
- Received-SPF: pass (mx.exemple.net: domain of alice@exemple.fr designates 203.0.113.25 as permitted sender)
- Authentication-Results: mx.exemple.net; spf=pass smtp.mailfrom=exemple.fr; dmarc=fail header.from=exemple.fr
- Le champ smtp.mailfrom donne le domaine réellement vérifié, à comparer avec header.from
La limite de dix requêtes DNS
C'est la panne silencieuse la plus courante. La RFC 7208 plafonne à dix le nombre de termes qui déclenchent une requête DNS pendant l'évaluation : les mécanismes include, a, mx, ptr, exists, et le modificateur redirect. Les mécanismes ip4, ip6 et all ne coûtent rien.
Le comptage est récursif, et c'est là que la plupart des administrateurs se trompent. Un include qui contient lui-même trois include consomme quatre unités, pas une. Développez chaque inclusion avec dig +short TXT _spf.exemple.net avant de conclure : les grandes plateformes d'envoi imbriquent volontiers deux niveaux de sous-enregistrements.
Deuxième plafond, moins connu : deux requêtes à vide. Une requête à vide est une résolution qui retourne NXDOMAIN ou aucune réponse, typiquement un include pointant vers un sous-domaine supprimé après un changement de prestataire. À la troisième, l'évaluation s'arrête en permerror.
Dépasser l'une de ces limites ne dégrade pas le résultat, elle l'annule. Le récepteur retourne permerror, que beaucoup traitent comme une absence d'enregistrement, et vos messages perdent le bénéfice de SPF. Si votre DMARC ne repose que sur lui, il échoue en cascade. La parade habituelle consiste à remplacer les include par les plages ip4 correspondantes, ce qu'on appelle l'aplatissement. Le prix à payer est réel : ces plages changent sans préavis, il faut donc un script qui régénère l'enregistrement, faute de quoi vous découvrez la panne plusieurs semaines après coup.
| Terme | Requête DNS | Remarque |
|---|---|---|
| ip4 / ip6 | Non | Coût nul, à privilégier |
| a / mx | Oui, 1 chacun | mx limité à 10 enregistrements d'adresse |
| include | Oui, 1 plus le contenu inclus | Comptage récursif |
| exists | Oui, 1 | Souvent couplé à des macros |
| ptr | Oui | Déconseillé par la RFC 7208, lent et peu fiable |
| redirect | Oui, 1 | Modificateur, compte dans les dix |
| all | Non | Doit terminer l'enregistrement |
Les causes d’échec les plus fréquentes
Quand un message part en indésirable, récupérez-le chez le destinataire, affichez la source du message et cherchez la ligne Authentication-Results. Elle donne le verdict SPF, le domaine d'enveloppe réellement utilisé et le domaine affiché. L'écart entre ces deux domaines explique une bonne partie des rejets.
Le reste tient à une poignée de configurations fautives, presque toujours les mêmes.
- Deux enregistrements v=spf1 sur le même nom, souvent après l'ajout d'un nouvel outil d'emailing. Résultat permerror : il faut fusionner les mécanismes dans un enregistrement unique.
- Un prestataire absent de la liste. Facturation, CRM, formulaire de contact envoient depuis leurs propres IP ; sans include ni ip4, tout finit en softfail ou en fail.
- Un sous-domaine oublié. SPF ne s'hérite pas : si vous envoyez depuis news.exemple.fr, ce nom doit porter son propre enregistrement, celui de exemple.fr ne s'applique pas.
- Un +all publié pour dépanner. Cela autorise n'importe quel serveur à écrire en votre nom et vide SPF de sa fonction.
- Le cache DNS. Après correction, les récepteurs servent l'ancien enregistrement jusqu'à expiration du TTL, de quelques minutes à plusieurs heures selon votre zone.
- Un -all confronté aux redirections. Un abonné qui fait suivre son courrier vers une autre boîte casse SPF, l'IP du relais n'étant pas la vôtre. DKIM survit à ce transfert, pas SPF, sauf si le relais réécrit l'enveloppe avec SRS.
Ce que la vérification SPF ne dit pas
Un pass signifie que le serveur avait le droit d'employer ce domaine d'enveloppe. Rien sur le contenu, rien sur l'expéditeur affiché, rien sur l'intégrité du message en transit. Un spammeur propriétaire de son domaine obtient un pass sans effort.
DKIM (RFC 6376) signe une partie des en-têtes et du corps avec une clé publiée dans le DNS, et cette signature résiste au transfert. DMARC (RFC 7489) fait la synthèse : il exige qu'au moins un des deux mécanismes passe et que le domaine validé s'aligne avec celui de l'en-tête From. En alignement relâché, le domaine organisationnel suffit, donc rebond.exemple.fr s'aligne avec exemple.fr. En alignement strict, la correspondance doit être exacte.
Conséquence pratique : un enregistrement SPF impeccable peut cohabiter avec un DMARC qui échoue, tout simplement parce que votre routeur utilise son propre domaine d'enveloppe. La correction passe par un sous-domaine de rebond personnalisé, proposé par la plupart des plateformes sous le nom de custom return-path ou de domaine de bounce dédié. Vérifiez-le avec la même commande dig, sur ce sous-domaine et pas sur l'apex.
Testez vos connaissances
Quelle identité la vérification SPF contrôle-t-elle par défaut ?
Score : 0 sur 3
Questions fréquentes
Comment savoir si mon domaine possède un enregistrement SPF ?
Lancez dig +short TXT exemple.fr et cherchez la ligne qui commence par v=spf1. Une réponse vide signifie qu'aucun enregistrement n'est publié, et la vérification côté récepteur retournera none. Attention à interroger le nom exact utilisé dans l'enveloppe de vos envois, pas systématiquement l'apex.
Faut-il terminer par ~all ou par -all ?
-all demande un rejet des IP non listées, ~all un simple marquage. Commencez par ~all le temps de vérifier dans les rapports DMARC agrégés que toutes vos sources légitimes sont couvertes, puis passez à -all. Un -all publié trop tôt bloque le prestataire que vous aviez oublié d'inclure.
Un domaine qui n’envoie aucun mail a-t-il besoin de SPF ?
Oui. Publiez v=spf1 -all sur les domaines parqués, les domaines de redirection et ceux réservés à la marque. Sans cet enregistrement, un usurpateur peut les employer comme enveloppe sans qu'aucun récepteur ait de raison technique de refuser.
Pourquoi mon SPF passe alors que mon DMARC échoue ?
Parce que DMARC ne se contente pas du verdict, il exige l'alignement. Si votre plateforme d'envoi utilise son propre domaine de rebond, SPF valide ce domaine, pas celui de votre en-tête From, et l'alignement échoue. Configurez un domaine de rebond à votre nom, ou faites reposer l'alignement sur DKIM.
Que faire quand l’enregistrement dépasse les dix requêtes DNS ?
Supprimez d'abord les include hérités d'anciens prestataires, ils représentent souvent la moitié du budget. Remplacez ensuite a et mx par les ip4 correspondantes quand ces IP sont stables. En dernier recours, aplatissez les inclusions restantes, mais prévoyez une régénération automatique : les plages des grands routeurs changent sans avertissement.