“Sender Policy Framework” est une norme de vérification du nom de domaine de l'expéditeur d'un courrier électronique, normalisée dans la RFC 7208. L'adoption de cette norme est de nature à réduire le spam¹⁾

Sa mise en œuvre est assez simple, il suffit de créer un enregistrement TXT dans la zone DNS du domaine expéditeur, cet enregistrement indiquant les adresses IP (v4 comme v6) des serveurs SMTP “officiels” pour ce domaine, ainsi que les restrictions à appliquer si l'IP émettrice n'est pas dans la liste. Il est également possible pour un domaine donné, d'inclure le champ SPF d'un autre serveur.

L'idée de base est de vérifier que l'émetteur du message a utilisé un serveur smtp sortant légitime pour le domaine annoncé dans l'adresse de l'émetteur. Celle qui est inscrite dans le champ Return-Path: et qui correspond à celle donnée dans le «RCPT TO» du dialogue smtp.

1. l'émetteur du message a une adresse @exemple.tld. Il envoie ce message @autrexemple.tld
2. Il utilise un smtp sortant légitime pour le domaine exemple.tld.
3. le smtp qui gère autrexemple.tld, lorsqu'il reçoit ce message va vérifier que le smtp que l'émetteur a utilisé pour envoyer son message est bien légitime pour le domaine exemple.tld. Par la suite, le paramètre “RCPT TO” indiquera l'adresse du destinataire. Tout ceci constitue l'enveloppe du message.

Un petit schéma ? Voici l'essentiel des en-têtes du message reçu par «untel@gmail.com» (seul les parties gauche des adresses ont été modifiées. Le reste est véridique):

Delivered-To: untel@gmail.com
...
Return-Path: <untel@nain-t.net>
Received: from smtp.nain-t.net (smtp.nain-t.net. [51.68.121.59])
       by mx.google.com with ESMTP id 4fb4d7f45d1cf-6005ae5205dsi257113a12.540.2025.05.15.11.51.10
        for <untel@gmail.com>;
...
Received-SPF: pass (google.com: domain of untel@nain-t.net designates 51.68.121.59 as permitted sender) client-ip=51.68.121.59;
...
Received: from [192.168.60.47] ([82.65.67.204])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	by smtp.nain-t.net (Postfix) with ESMTPSA id A879425237
Reply-To: untel@nain-t.net
Content-Language: fr
To: untel <untel@gmail.com>
From: untel <untel@nain-t.net>

Rappelons également que la chronologie des étapes du relai est inversée dans l'en-tête. Il faut la suivre de bas en haut. Ainsi, les lignes surlignées orange représentent l'itinéraire du message depuis le MUA situé sur 192.168.60.47, transmis via le routeur NAT à smtp.nain-t.net en utilisant TLSv1, ce qui sous-entend que le client a été authentifié par «smtp.nain-t.net», puisque ce dernier accepte de le transmettre à «mx.google.com».

Ici «Return-Path:», «From:» et «Reply-to» pointent sur la même adresse. Avec un MUA «propre» «Return-Path:» et «From:» pointent la même adresse. «Reply-to» peut en revanche présenter légitimement une adresse différente.

Le MTA de Google recherche via DNS le champ SPF du domaine «nain-t.net» et constate que l'adresse du MTA qui lui a relayé le message est bien légitimée par SPF.

Du moins la plus fondamentale, car elle est assez riche. SPF identifie des nœuds légitimes de diverses manières:

• leur adresse IP v4 comme v6;
• les nœuds référencés dans son domaine comme étant des MX;
• les nœuds référencés dans son domaine référencés par un champ A ou AAAA. Autrement dit, pas de CNAME.

Pour les autres, ne retenons que «all» qui signifie «tous les autres». (Pour étudier toutes les autres possibilités, voir Le site officiel du projet SPF)

«all» représente donc le reste du monde et que faire avec ?

1. ?all signifie que l'on ne se prononce pas («lavabo» en latin);
2. ~all signifie qu'ils ne sons pas autorisés, mais que l'on peut se tromper. Pratiquement, le message devrait passer, mais en étant marqué comme suspicieux.
3. -all veut dire que personne d'autre n'a le droit de relayer pour ce domaine. Autrement dit, il faut rejeter le message.
4. enfin, le + indique que ce qui suit est valide. Autrement dit, ce signe n'apparaît jamais devant le «all» ou alors, mieux vaut bloquer complètement ce domaine ! Pratiquement, ce signe peut être omis, puisqu'il ne peut apparaître que devant des nœuds autorisés.

Exemple: v=spf1 +a +mx -all, qui peut tout aussi bien s'écrire v=spf1 a mx -all, ce qui veut dire que seuls les nœuds référencés dans un champ «A» ou «MX» sont autorisés à l'exclusion de tout autre.

Pas vraiment. C'est certes mieux que rien puisqu'un spammeur doit théoriquement disposer d'une adresse dans le domaine dont le champ SPF valide le MTA qu'il utilise.

Sauf que:

• des erreurs de syntaxe dans la formulation du texte,
• la permissivité plus ou moins relative («?all»,« ~all»

sont autant de portes d'entrées qui permettent, en utilisant un «MAIL FROM» avec une adresse forgée à partir d'un domaine compromis, de passer plus ou moins librement le filtrage SPF.

Le problème qui demeure, concernant la tromperie du destinataire est la suivante: MAIL FROM: Fait partie de l'enveloppe du message. Dans ce message, il y a le champ FROM:. Normalement, ces deux adresses devraient être identiques, c'est ce que produit un MUA convenablement éduqué. Mais rien n'empêche une personne mal intentionnée de forger un message où les deux adresses seraient différentes.