SPF : déclarer qui a le droit d'envoyer pour un domaine

SPF (Sender Policy Framework) permet au propriétaire d'un domaine de publier, dans un enregistrement DNS, la liste des adresses IP et des serveurs autorisés à envoyer des messages en se réclamant de ce domaine. Le serveur de réception compare l'adresse IP du serveur qui lui parle à cette liste et en déduit un résultat (pass, fail, softfail, neutral…). SPF est normalisé par la RFC 7208.

Ce que SPF vérifie réellement#

SPF ne regarde pas l'adresse affichée dans le champ From: du message. Il s'applique à deux identités de la session SMTP :

• l'adresse de l'enveloppe, dite MAIL FROM ou Return-Path, c'est-à-dire l'adresse à laquelle les notifications de non-remise sont renvoyées ;
• le nom annoncé dans la commande HELO / EHLO du serveur émetteur, utilisé notamment quand le MAIL FROM est vide (messages de bounce).

Cette distinction est importante : un message peut passer SPF avec un MAIL FROM sur un domaine technique d'un prestataire tout en affichant un From: sur votre domaine. C'est DMARC qui exige ensuite un alignement entre les deux.

Syntaxe d'un enregistrement#

L'enregistrement est un TXT publié à la racine du domaine (ou du sous-domaine) utilisé dans le MAIL FROM. Il commence obligatoirement par v=spf1 et se lit de gauche à droite : le premier mécanisme qui correspond à l'adresse IP détermine le résultat.

example.com.  IN TXT  "v=spf1 ip4:192.0.2.0/24 ip6:2001:db8::/32 mx include:_spf.example.net -all"

Les mécanismes les plus courants :

• ip4: et ip6: : une adresse ou un préfixe réseau. C'est le mécanisme le plus économique, il ne coûte aucune requête DNS.
• a et mx : les adresses des enregistrements A/AAAA ou MX du domaine (ou d'un domaine indiqué, par exemple mx:mail.example.org).
• include: : évalue l'enregistrement SPF d'un autre domaine, typiquement celui d'un prestataire d'envoi. Le include n'est pas une inclusion de texte mais une évaluation récursive.
• exists: : teste l'existence d'un nom DNS, utile pour des macros avancées.
• all : correspond à tout, placé en fin de chaîne.

Chaque mécanisme peut être préfixé d'un qualificateur : + (pass, valeur par défaut), - (fail), ~ (softfail), ? (neutral). La terminaison -all indique que tout serveur non listé doit échouer ; ~all est une version adoucie, historiquement utilisée pendant les phases de transition. Le modificateur redirect= remplace l'intégralité de l'évaluation par celle d'un autre domaine.

La limite des dix lookups#

La RFC 7208 impose une limite : l'évaluation d'un enregistrement ne doit pas déclencher plus de dix requêtes DNS pour les mécanismes include, a, mx, ptr, exists et le modificateur redirect. Au-delà, le résultat est permerror, ce qui équivaut à l'absence d'authentification. Deux requêtes supplémentaires qui ne renvoient rien (void lookups) suffisent aussi à provoquer une erreur.

C'est la cause d'échec la plus fréquente : chaque prestataire ajouté par include apporte ses propres include imbriqués, et un domaine qui utilise une suite bureautique, un outil marketing, un CRM et une plateforme de support dépasse rapidement la limite sans s'en rendre compte. Les remèdes sont de remplacer des include par des préfixes ip4: / ip6: stables, de retirer les prestataires qui n'envoient plus, et de dédier des sous-domaines à certains flux (voir sous-domaines et wildcard).

Déployer SPF#

1. Inventorier tous les systèmes qui émettent du courrier avec le domaine en MAIL FROM : serveurs internes, prestataires marketing, outils transactionnels, applications métier, imprimantes et équipements qui envoient des alertes.
2. Pour chaque source, relever soit les préfixes IP, soit le include documenté par le prestataire.
3. Publier un seul enregistrement TXT commençant par v=spf1, en terminant par ~all le temps de valider, puis par -all.
4. Vérifier le nombre de lookups et la taille de la réponse DNS : une chaîne TXT est limitée à 255 caractères, un enregistrement plus long doit être découpé en plusieurs chaînes dans le même enregistrement.
5. Publier v=spf1 -all sur les domaines et sous-domaines qui n'envoient jamais de courrier.
6. Surveiller les rapports DMARC pour détecter les sources oubliées avant de durcir la politique.

Erreurs fréquentes#

• Plusieurs enregistrements SPF sur le même nom : la RFC impose un seul enregistrement commençant par v=spf1, sinon permerror.
• +all ou ?all en fin de chaîne : l'enregistrement n'interdit rien et n'apporte aucune protection.
• Mécanisme ptr : déconseillé par la RFC, lent et peu fiable.
• Enregistrement de type SPF (type DNS 99) : obsolète, seul le TXT est évalué.
• Oublier le HELO : le nom annoncé par vos serveurs sortants doit lui aussi disposer d'un enregistrement SPF, sinon les bounces et notifications échouent.
• Confondre SPF et DMARC : un SPF valide sur le domaine du prestataire ne protège pas le From: visible. Sans DKIM aligné ou sans MAIL FROM sur le domaine, DMARC échouera.
• Ne jamais réviser l'enregistrement : les prestataires changent d'adresses, les include évoluent, et un enregistrement non maintenu finit par dépasser la limite ou par autoriser des plages qui ne vous appartiennent plus.

Ce que SenderRadar en montre#

Dans la cartographie d'un domaine, SenderRadar affiche l'enregistrement SPF publié, sa décomposition mécanisme par mécanisme, le nombre de requêtes DNS consommées par rapport à la limite de dix, la politique de terminaison (-all, ~all, autre) et les anomalies de syntaxe détectées. SenderRadar s'appuie sur sa propre base d'analyse pour situer ces éléments par rapport aux pratiques courantes des domaines comparables.

Références#

• RFC 7208 – Sender Policy Framework (SPF)
• RFC 7489 – DMARC, pour l'alignement entre MAIL FROM et From:
• RFC 5321 – SMTP, pour les identités MAIL FROM et HELO