Ajout d'un enregistrement SPF pour un tiers, mais n'en ai pas pour mon propre domaine

Nous avons un service tiers envoyant des e-mails en notre nom. Ils utilisent notre nom de domaine dans leurs e-mails sortants. Ils nous ont demandé de configurer un enregistrement SPF pour eux.

Nous n'avons actuellement aucun enregistrement SPF défini pour notre propre domaine, qui est le même que le tiers "usurpe".

Ma préoccupation est que si nous ajoutons un enregistrement pour un tiers sans définir le nôtre également, le courrier provenant de nos serveurs pourrait être rejeté.

Ma préoccupation est-elle valable?

email spf

— k1DBLITZ
source

À quel point sera-t-il difficile pour vous d'en créer un?

— Michael Hampton

Pas difficile. Le problème potentiel, à mon avis, est qu'il existe plusieurs services tiers que nous utilisons qui usurpent actuellement notre domaine et si je n'ajoute pas d'enregistrements SPF pour tous, qu'en ajoutant 1 seul, je pourrais invalider les autres lorsque les serveurs de messagerie à réception aléatoire recherchent l'enregistrement SPF pour notre domaine et voient que les noms / IP ne correspondent pas.

— k1DBLITZ

Réponses:

Si vous n'avez pas d'enregistrement SPF, les récepteurs échoueront généralement en toute sécurité et accepteront votre e-mail (bien que cela commence à changer). Dès que vous fournissez un enregistrement SPF, vous devez inclure tous les expéditeurs de courrier légitimes, car sinon ceux qui ne sont pas répertoriés pourraient être traités comme de possibles sources de contrefaçon.

À strictement parler, vous pouvez inclure ~allou ?alléviter de répertorier tous vos expéditeurs de courrier, mais si vous le faites, vous n'obtiendrez aucun avantage de l'enregistrement SPF autre que pour tester qu'il est par ailleurs exact.

Idéalement, vos tiers auront déjà un enregistrement SPF générique et vous pouvez simplement ajouter l' include:spf.thirdparty.domélément à votre enregistrement. S'ils ne le font pas, vous voudrez peut-être créer votre propre enregistrement pour eux et l'enchaîner vous-même de toute façon, afin que cela soit facile pour vous à administrer.

Par exemple, si vous êtes contoso.com:

thirdparty1.spf.contoso.com txt 'v=spf1 ... -all' # list their mail senders for you
thirdparty2.spf.contoso.com txt 'v=spf1 ... -all' # list their mail senders for you
spf.contoso.com txt 'v=spf1 ... -all'             # list your mail senders
contoso.com txt 'v=spf1 include:spf.contoso.com include:thirdpart1.spf.contoso.com include:thirdparty2.spf.contoso.com -all'

Quelques ressources utiles:

DMARC subsume SPF et DKIM, et mérite d'être considéré. Il est activement utilisé par Google, Yahoo et autres pour valider les e-mails entrants, https://dmarc.org/overview/
Une liste des meilleures pratiques lors de la configuration d'un enregistrement SPF, http://www.openspf.org/Best_Practices
Malgré son nom, une recette utile pour configurer un enregistrement SPF, http://www.openspf.org/FAQ/Common_mistakes

— roaima
source

Avez-vous une source à ce sujet?

— Aaron Hall

@AaronHall ces liens de ressources sont-ils suffisants? Sinon, pouvez-vous préciser ce que vous cherchez

— roaima

Vous pouvez placer votre service tiers dans un enregistrement SPF avec une règle neutre pour les autres serveurs:

?all

Et incluez au moins vos propres serveurs de messagerie avec:

+mx

C'est une bonne chose d'avoir un enregistrement SPF sur votre domaine. Commencez à ajouter une liste blanche et neutre pour les autres, et lorsque vous aurez un enregistrement SPF à jour avec tous vos serveurs, vous pouvez modifier la valeur par défaut en échec (-all) ou softfail (~ all).

Il y a une bonne documentation ici et beaucoup d'autres informations utiles sur openspf.org

— Mick
source

Une partie du problème auquel je suis confronté est que je n'ai pas de liste à jour de toutes les autres sociétés qui envoient des e-mails en notre nom. Dites-vous que si j'utilise votre approche, je peux les ajouter aux enregistrements SPF au fur et à mesure qu'ils sont découverts sans affecter notre flux de messagerie de production? Pouvez-vous fournir un exemple de syntaxe spécifique avec des domaines fictifs? J'ai passé en revue les informations que vous avez liées et c'est très utile, mais je ne peux pas me permettre de me tromper.

— k1DBLITZ

Vous pouvez le faire par étapes: ajoutez d'abord votre service tiers, votre mx, et neutre pour tous les autres: "a: your3rppart mx? All". Mettez ensuite à jour votre SPF avec d'autres serveurs. Nous pensons que vous les avez tous changé la politique par défaut en softfail ou fail

— mick

Sérieusement, SPF sans -allest non seulement complètement inutile, mais certains administrateurs l'utilisent comme un signe actif de spammeurs. Ne le fais pas.

— MadHatter

"tout va mieux alors -tout si vous ne savez pas ce que vous faites, les politiques DMARC s'appliquent toujours" tout de même que -all et beaucoup de gros ESP ne se soucient plus de -all à cause de la première déclaration

— Jacob Evans

Sérieusement, SPF sans -all n'est pas seulement complètement inutile, mais certains administrateurs l'utilisent comme signe actif de spammeurs. Ne le faites pas - alors ils devraient corriger leurs systèmes cassés qui ne suivent pas la spécification SPF; " Si les propriétaires de domaine choisissent de publier des enregistrements SPF, il est RECOMMANDÉ qu'ils se terminent par" -all " " - ietf.org/rfc/rfc4408.txt - Ce n'est pas obligatoire. SoftFail est un état distinct.

— TessellatingHeckler