Lorsque vous ajoutez une IP, un "include" ou tout autres mécanismes SPF dans l’enregistrement DNS SPF d’un domaine, vous autorisez des systèmes à émettre des e-mails avec un « Return Path/SMTP From/Envelope From » utilisant ce même domaine.
Ces systèmes peuvent ainsi émettre des e-mails avec votre nom de domaine de manière authentifiée et donc de manière légitime aux yeux des anti-spams des destinataires.
Qui est vraiment autorisé à émettre des e-mails lorsqu'un un Outlook, un Sendgrid.com, un Mailchimp, un Salesforces ou tout autre solution d’envoi d’e-mails est ajoutée dans un enregistrement SPF ?
Techniquement, vous autorisez les IPs de ces solutions à émettre des e-mails en votre nom. Et ces solutions peuvent ajouter des sécurités pour s’assurer que seules les personnes autorisées à émettre des e-mails avec votre nom de domaine peuvent le faire au travers de leurs solutions.
Mais ces sécurités sont à géométrie variable…
Par exemple :
- Pour envoyer un e-mail avec un tenant office 365 il faut au préalable que l’administrateur du domaine prouve qu’il dispose du contrôle du domaine et inscrive cette instance. Ce niveau de contrôle est fort car il empêche les instances émettrices de se multiplier sans le contrôle du service informatique.
- Pour envoyer un e-mail avec un compte mailchimp l’utilisateur doit prouver qu’il a le contrôle de l’adresse e-mail désirée. Ce niveau de contrôle est faible car dès lors que les enregistrements SPF/DKIM génériques permettant d’authentifier les e-mails émis par mailchimp ont été publiés dans le domaine, n’importe quel utilisateur de l’entreprise pourra envoyer des e-mails avec mailchimp.
- Pour envoyer un e-mail avec turboSMTP l’utilisateur n’est pas obligé de prouver qu’il dispose du contrôle de l’adresse e-mail ou du domaine d’émission. Ajouter turboSMTP dans son SPF relève du sabotage involontaire. En effet, se faisant, n’importe qui sur terre pourra utiliser turboSMTP pour envoyer des e-mails authentifiés avec SPF avec votre nom de domaine et n’importe quelles adresses e-mails.
En conclusion, ajouter un enregistrement SPF peut dans certains cas être :
- Inutile, si la solution d’envoi d’e-mail n’utilise pas votre domaine dans le champs « Return Path/SMTP From/Envelope From » d’un e-mail;
- Inoffensif, si les sécurités incluses dans les solutions émettrices, couplés à une possible stratégie de cloisonnement par sous domaines des solutions émettrices, sont en place;
- Très dangereux, dans les cas ou les solutions émettrices n’intègrent aucune sécurité, c’est-à-dire, dans le cas ou les solutions émettrices autorisent leurs clients à émettre des e-mails avec des noms de domaines sur lesquels ils n’ont aucun contrôle, pas même la possession d’une adresse e-mail.
Vous l’aurez compris, la décision de rajouter un tier dans son SPF doit être faite de manière éclairée et réfléchie. L’offre de service gérée que nous proposons avec dmarc.fr permet aux administrateurs de messagerie ou de sécurité de déléguer ces questions à des professionnels ayant une connaissance poussée des questions ayant trait à la bonne mise en place des protocoles d’authentification des e-mails SPF/DKIM/DMARC.