Les RFC* du protocole SPF (Sender Policy Framework) d’authentification des e-mails limite le nombre de consultations du DNS à dix. Nous souhaitions profiter de cet article pour vous exposer les conséquences de cette limite et comment s’y adapter.
* Les RFC (Request For Comments) sont un ensemble de documents qui font référence auprès de la Communauté Internet et qui décrivent, spécifient, aident à l'implémentation, standardisent et débattent de la majorité des normes, standards, technologies et protocoles liés à Internet et aux réseaux en général.
Qu’est qu’un SPF DNS lookup ?
Un DNS Lookup (une recherche DNS) est le processus par lequel les données d'un enregistrement DNS - celles du SPF en l'occurrence - sont renvoyées, par un serveur DNS, au demandeur. Pour chaque opération DNS imposée par votre enregistrement SPF, un DNS "lookup" est décompté. Les opérations présentent dans les autres SPF que vous avez éventuellement inclus (mécanisme "Include" ci-dessous) à votre SPF sont également décomptées.
Une redirection DNS est donc décomptée pour chaque mécanisme SPF utilisé dans votre enregistrement SPF :
- Include
- MX
- PTR
- A
- Redirect
- Exists
Par exemple, le SPF de microsoft.com comporte exactement 10 lookups DNS :
v=spf1 include:_spf-a.microsoft.com include:_spf-b.microsoft.com include:_spf-c.microsoft.com include:_spf-ssg-a.microsoft.com include:spf-a.hotmail.com include:_spf1-meo.microsoft.com -all
Que se passe-t-il si la limite des 10 lookups est dépassée ?
Si votre enregistrement SPF dépasse la limite des 10 "lookups", il se peut que votre enregistrement SPF ne soit pas analysé par les anti-spams de vos destinataires, ou qu'il ne le soit que partiellement seulement. Cela peut avoir un effet négatif sur la délivrabilité de vos e-mails qui ont de fortes chances d’être considérés comme du spam.
Que dois-je faire pour ne pas dépasser la limite des 10 lookup DNS ?
Plusieurs possibilités s’offrent à vous pour ne pas subir les désagréments d’un SPF dépassant la limite des 10 "lookups". Voici par ordre de préférence ce que nous préconisons à nos clients :
- Faites du ménage dans votre SPF. Servez-vous de notre outil d’analyse des rapports DMARC pour identifier les enregistrements SPF non utilisés et enlevez-les de votre SPF. Un SPF trop grand peut augmenter le score de spam chez google.
- Quand cela est possible, privilégiez l’utilisation d’adresses IPs dans votre SPF. La lecture de votre SPF par les anti-spams de vos destinataires sera beaucoup plus rapide, ce qui diminuera les erreurs DNS possibles (n’oublions pas que le protocole DNS est basé sur UDP, un protocole sujet au perte des paquets réseau!);
- Quand cela est possible, essayez au maximum de dédier des domaines ou sous-domaines à vos différentes solutions émettrices d’e-mails. Cela facilitera la gestion du SPF de votre domaine racine et de vos sous-domaines. Dédiez un sous domaine à chaque solution émettrice permet aussi de protéger la réputation e-mail de chacun de ces domaines. Contrainte dans son propre sous-domaine, votre solution d’e-mail marketing ne pourra pas dégrader la réputation e-mail de votre top domaine ou de vos domaines d’e-mails transactionnels.
Exemple de schéma ci-dessous : La réputation du domaine racine est bonne, tandis que celle du sous-domaine oscille entre bonne et moyenne. Les e-mails provenant du domaine racine sont transmis aux destinataires. En revanche, les e-mails issus du sous-domaine dédié à la newsletter sont périodiquement classés comme spam par Gmail.
Google évalue quotidiennement la réputation des domaines en fonction du ratio d'e-mails mauvais sur bons. Si une source peu fiable émet un nombre disproportionné d'e-mails un jour où les sources fiables sont moins actives, la réputation du domaine communément utilisé (généralement le domaine de messagerie de l'organisation) peut subir des dommages durables. Isoler une source d'e-mails peu fiable sur un sous-domaine dédié à son usage exclusif peut efficacement protéger le domaine principal de l'organisation contre la mauvaise réputation engendrée par cette source.
Avez-vous remarqué ?
Nous ne parlons pas d’aplatisseurs de SPF, ni de Macros SPF, gérés par un tiers et supposément boostés à l’intelligence artificielle.
Les bénéfices de recourir à ces solutions, promues et implémentées par des sociétés connues de ce marché, ne nous semblent pas évidents. Pour illustrer notre propos, nous énumérerons trois avantages avancés par ces sociétés et nous regarderons ce que les organisations les plus concernées par ces problématiques, et à la pointe de la technique, font pour leur propre SPF.
1/ L’utilisation de macros SPF permet de cacher aux pirates la liste des émetteurs autorisés :
La NSA ne semble pas s’en préoccuper.
D’autre part, l’utilisation de macros SPF cache la liste des émetteurs autorisés aux bons acteurs comme les équipes de réponse aux incidents. Aussi, dans de nombreux cas, ces macros SPF, aplatisseurs de SPF, ou hébergeurs de SPF ne permettent pas aux solutions "cloud" émettant des e-mails de vérifier que le SPF a bien été configuré, ce qui risque de créer des alertes dans les "Dashboard" de configuration de ces solutions, voir rendre impossible l'émission d'e-mail avec vos domaines.
2/ L’utilisation de macros SPF permet de contourner des limites des « include » SPF, et d’améliorer la performance des requêtes :
Google, Microsoft et Mailchimp émettent énormément d’e-mails et pourtant ils ne semblent pas utiliser ces solutions, alors pourquoi devriez-vous en avoir besoin ?
3/ L'utilisation des macros SPF permet de contrôler étroitement les autorisations de l'expéditeur
La NSA ne semble pas s’en préoccuper non plus.
D’autres part, en faisant confiance aveuglement à une solution semi-automatisée, vous prenez le risque d’autoriser la terre entière à émettre des e-mails en votre nom, en un clic seulement, sous les conseils d'un robot boosté à l’intelligence artificielle . De ce côté-là, les risques dépassent les avantages.
Enfin, ce mécanisme ne fonctionne que pour les solutions utilisant SPF pour authentifier les e-mails, et un enregistrement SPF que vous pouvez contrôler. Ces deux prérequis ne sont malheureusement pas disponibles chez la plupart des solutions cloud émettant des e-mails.
4/ Incompatibilité des macros SPF avec certains outils
Pour émettre des e-mails en votre nom, certains outils doivent au préalable vérifier par le mécanisme "Include" que leur SPF a bien était intégré à l'enregistrement SPF de votre nom de domaine. Cela n’est pas possible avec les macros SPF.
Par exemple, Oracle vérifie que les SPF sont correctement configurés.
Enfin, l’authentification SPF n’est pas toujours possible. Les aplatisseurs de SPF et autres Macros SPF ne vous aiderons pas à configurer DKIM sur un système mailchimp, sendgrid, amazonses, postfix, ironport, etc. Des interventions manuelles, en collaboration avec les équipes en charge de ces systèmes et des DNS, resteront obligatoires.
Pourquoi ajouter un second « point of failure / défaut de conception» à votre enregistrement, avec un outil supplémentaire qui possède ses propres risques intrinsèques : disponibilité, mises à jours des informations DNS, gestion de la connaissance et formation des utilisateurs, etc.?
Tout ce qui est fait pour moi, sans moi, est fait contre moi. - Un proverbe africain
Une solution souhaitant gérer (ou héberger), pour vous, votre SPF, est une solution qui tente peut-être de vous faire perdre le contrôle de votre SPF. C’est en tout cas une solution qui sera difficile à décommissionner si le besoin s’en fait sentir, nécessité souvent liée à des prix prohibitifs.
Nos recommandations ne vont pas dans le sens des solutions DMARC offrant un "easy SPF lookup reducer". En revanche, nos indications visent à préserver la réputation et la sécurité à long terme de vos flux e-mail et vous aideront à conserver un enregistrement SPF concis (Google n'aime pas les gros enregistrements SPF).
Enfin, voici quelques liens vers des articles en anglais, agnostiques commercialement, qui alimenteront votre réflexion sur le sujet :
https://www.proofpoint.com/us/blog/email-and-cloud-threats/proofpoint-discloses-valimail-spf-macro-vulnerability