Le fait d'avoir un champ "Sender Policy Framework" sur les enregistrements DNS de son domaine préserve efficacement de l'usurpation d'identité (email spoofing).
Cependant la technique du SPF a ses limites puisqu'elle oblige le serveur de messagerie destinataire à contrôler les enregistrements DNS, or ce contrôle ne sera valide que si ce serveur est en réception directe et n'utilise pas de relais de messagerie. Un contrôle SPF ne peut donc pas être valide derrière un relais entrant.
Le SPF est compatible avec un relais sortant (comme par exemple un relais de filtrage Vade), mais il faut impérativement déclarer les informations de ce relais dans le champ SPF du domaine expéditeur (un champ texte à modifier sur les enregistrements DNS).
Vade conseille l'usage d'enregistrements SPF sur les domaines de ses clients, puisque cette technique préserve efficacement de l'usurpation d'identité.
Mais nous constatons malheureusement que nombre de serveurs de messagerie paramétrés pour effectuer un contrôle SPF se trouvent derrière un relais. Le cas le plus fréquent concerne une messagerie prise en charge chez un hébergeur qui applique le contrôle SPF, empêche l'usage d'un relais entrant (un relais de filtrage Vade par exemple), et cette contrainte n'est pas forcément explicite sur les conditions d'utilisation déclarées par l'hébergeur.
En conclusion, la déclaration de champs SPF est compatible avec les relais Vade (c'est pourquoi le diagnostic Vade Cloud le précise si détection d'un enregistrement de cet type au niveau DNS). Mais l'activation du contrôle SPF est proscrite pour toute messagerie se trouvant derrière un relais en réception.
