Par : Yves Lacombe
De nombreuses personnes utilisent le FPS (Sender Policy Framework) comme mesure anti-usurpation d’identité. Ils créent un enregistrement SPF dans leur zone DNS pour leur domaine. De temps en temps, certains clients font des affaires ou utilisent des services tiers qui envoient des courriels au nom de leurs domaines, ce qui malheureusement fait en sorte que les MTA des destinataires échouent ou échouent progressivement ces messages.
Exemple typique : widget.com dispose d’un enregistrement SPF identifiant les MTA qui peuvent envoyer des courriels au nom dudit domaine. L’entreprise décide d’utiliser SalesForce (solution CRM hébergée) pour son équipe de vente. Étant donné que les MTA de SalesForces ne sont pas déclarés dans widget.com enregistrement SPF, les MTA destinataires rejetteront les messages avec @widget.com dans l’e-mail de l’expéditeur, car ces courriels ne proviennent d’aucune des adresses IP autorisées.
La solution de rechange
Ajoutez des MTA SalesForces à l’enregistrement SPF de widget.coms.
La plupart des services tiers auront leur propre enregistrement SPF, donc tout ce que vous avez à faire est d’utiliser le … inclure des directives pour inclure les renseignements de leur dossier FPS dans le vôtre.
Disons que l’enregistrement SPF de widget.com ressemble à ceci :
v=spf1 ip4:10.10.10.0/24 -all
Tout ce que l’administrateur de widget.com ferait est quelque chose comme ceci :
v=spf1 ip4:10.10.10.0/24 include:salesforce.com -all
En supposant que le MTA que salesforce.com utilise pour envoyer des courriels OUT avec @widget.com à l’adresse de l’expéditeur est couvert par l’enregistrement SPF salesforce.com existant, cela devrait fonctionner.
Références :
Cadre stratégique de l’expéditeur : http://www.openspf.org/
