Dans la continuité de mon premier article sur « Qu’est-ce que SPF ? », je vous propose un second article toujours dédié à SPF.
En analysant les enregistrements SPF des entreprises TOP 100 E-commerce & du CAC40, je me suis aperçu que certains SPF comportaient des erreurs et que celles-ci pouvaient engendrer des problématiques majeures sur la sécurité des domaines ou sur la bonne livraison des e-mails (si ceux-ci sont utilisés pour envoyer des e-mails).
Et quand on connait l’importance de bien protéger son infrastructure contre les menaces venant de l’extérieur (comprenez ici le spam et le phishing), il est important de rappeler certaines règles de paramétrage ou d’utilisation. C’est ainsi que naquit l’idée de cette article… Vous lister 10 conseils à mettre en place sur le paramétrage et l’utilisation de SPF sur vos domaines.
Conseil #1 : On a TOUS besoin de SPF…
Il ne faut pas oublier que tout domaine qui n’est pas correctement protégé avec les systèmes d’authentification disponibles (SPF, DKIM, DMARC, BIMI) est du pain béni pour tout pirate (ou personne mal intentionnée). Ce dernier pourra l’utiliser à votre insu pour lancer une campagne de spam ou de phishing sur vos clients, vos employés et/ou vos prestataires.
Conseil : Même si votre domaine n’est pas utilisé pour l’envoi d’e-mails (et encore plus s’il y est), pensez à le protéger pour réduire au maximum ces risques d’utilisation abusive qui peuvent nuire gravement à votre réputation et à votre marque?!
Conseil #2 : Éviter d’utiliser un mécanisme obsolète…
D’après la RFC 4408 (cf. Request For Comments – documents officiels décrivant les aspects et spécifications techniques d’Internet), le mécanisme PTR (cf. Pointer Record – enregistrement qui permet de relier une IP à un nom de domaine) est devenu obsolète et son utilisation est déconseillée car il ralentit la lecture de SPF. De plus, il n’est pas aussi fiable que les autres mécanismes en cas d’erreurs DNS (cf. Domain Name Server).
Conseil : Évitez toute intégration du mécanisme “ptr” dans votre enregistrement SPF. Si cela est nécessaire, privilégiez plutôt l’ajout en dur de l’IP associée (en utilisant IP4 ou IP6).
Conseil #3 : Déclarer SPF dans un enregistrement TXT…
Depuis 2014, il n’y a plus qu’une seule façon de publier un enregistrement SPF, à savoir via un enregistrement TXT du domaine (cf. enregistrement texte qui permet de relayer des informations à des tiers comme SPF, code Google Postmaster Tools, …), celui-ci étant plus facile et plus pratique.
Conseil : Vérifier dès à présent la méthode qui a été utilisée pour la publication de votre enregistrement SPF afin d’être sûr qu’il soit bien conforme. Si ce n’est pas le cas, il suffira de faire un copier/coller du code dans un nouvel enregistrement TXT de votre domaine via votre hébergeur.
Conseil #4 : Limiter le nombre de mécanismes…
Là encore, la RFC 7208 indiquent que le nombre de mécanismes (et de modifieurs) ne doit pas excéder 10 recherches sous peine de voir les FAI/Webmails ignorés votre enregistrement SPF. Les mécanismes concernés sont :
- Include
- MX
- A
- PTR (ce mécanisme étant obsolète, il ne devrait plus être utilisé)
- Exist
À noter que les mécanismes IP4, IP6, All ne compteront pas dans les recherches car il ne nécessite pas de recherche sur un nom de domaine. BadExemple avec le domaine “manomano.fr”. Celui-ci comporte un total de 12 recherches :
Conseil : N’hésitez pas à vérifier dès à présent votre enregistrement SPF afin de voir si le nombre de mécanisme est correct. Si ce n’est pas le cas, il ne vous restera plus qu’à le simplifier.
Conseil #5 : Ne pas déclarer trop de ressources MX…
(Toujours) Notre chère RFC 7208 indique que l’évaluation de chaque enregistrement MX ne doit pas aboutir à plus de 10 enregistrements de type “A” (cf. qui relie un nom de domaine à une ou plusieurs IPv4) ou “AAAA” (cf. qui relie un nom de domaine à une ou plusieurs IPv6). Si la limite est dépassée, le mécanisme MX doit produire un résultat “permerror” et donc SPF sera en échec.
L’enregistrement MX renvoie vers 19 enregistrements de type A :
Conseil : Si vous ajoutez le mécanisme MX dans l’enregistrement SPF, pensez à vérifier que celui-ci ne renvoie pas vers trop de recherche (le cas échéant le simplifier).
Conseil #6 : Mettre un et un seul enregistrement SPF par domaine…
Il ne peut y avoir qu’un seul enregistrement SPF par domaine (toujours en le déclarant dans l’enregistrement TXT). Si vous en avez un 2ème, il ne sera pas lu et donc interprété. À contrario, un domaine peut avoir plusieurs clés DKIM déclarées dans son enregistrement TXT (on verra cela en détail dans un prochain article).
— Pas de BadExemple sur les entreprises du TOP 100 E-Commerce, ni sur celles du CAC40 mais j’ai déjà eu affaire à ce problème sur un audit. Le client utilisait 2 routeurs et avait créé 2 enregistrements SPF (au lieu d’un seul regroupant 2 mécanismes “include”).
Conseil : Si vous avez plusieurs sources externes à déclarer dans votre enregistrement SPF, deux solutions s’offrent à vous : soit ajouter toutes les IPs en dur (attention à ne pas dépasser 255 caractères), soit ajouter plusieurs « include » (attention à ne pas en imbriquer trop) renvoyant vers les IP de votre routeur (par exemple : spf.splio.com => renvoie vers toutes les IP utilisées par Splio) mais en aucun cas vous ne devrez créer un enregistrement SPF par source externe sur votre domaine.
Conseil #7 : Déclarer au moins un mécanisme dans SPF…
Un des objectifs de SPF est de protéger un nom de domaine contre des abus venant de tiers. Pour vous aider à bloquer ce trafic illégitime, il faudra déclarer dans l’enregistrement TXT du domaine tous les mécanismes (d’une simple IP au SPF de votre routeur) qui seront autorisés à envoyer des e-mails avec votre nom de domaine.
Besoin d'aide ?
Lire du contenu ne fait pas tout. Le mieux, c’est d’en parler avec nous.
Même si je comprends la démarche de verrouiller un domaine qui ne serait pas utilisé en interdisant tout trafic, il est quand même risqué de se dire que l’on est sûr à 100% qu’il ne sera jamais utilisé car si demain Airbnb décidait d’envoyer des e-mails (même interne) avec ce domaine, tous les FAI/Webmails vérifiant SPF bloqueraient tous leurs e-mails.
Conseil : Même si vous n’envoyez pas d’e-mails avec un domaine qui vous appartient, pensez à ajouter au minimum quelques mécanismes à votre enregistrement SPF, ceci afin d’éviter tout changement de stratégie de routage qui aurait un impact (à moins de s’appeler Airbnb).
Conseil #8 : Oublier le mécanisme/qualifieur « +all »…
L’utilisation du mécanisme/qualifieurs (+all) permettra à n’importe qui finalement d’utiliser votre domaine puisque vous autorisez toutes IP à émettre avec votre domaine (c’est cadeau !). Pour rappel, SPF doit être paramétré en mode “restriction” pour être réellement efficace.
À la rigueur, ce mécanisme (+all) peut “potentiellement” (je dis potentiellement) être utilisé au tout début de l’implémentation de SPF si votre infrastructure est lourde mais doit forcément être couplé à DMARC. En tout cas, il ne devra être utilisé qu’à très très très court terme et un passage en “~all” devra prendre le pas rapidement avant le passage en “-all”.
Tous les mécanismes “All” (y compris ceux compris dans les “include”) sont en “+all”, ce qui signifie que tous les e-mails seront acceptés par les FAI/Webmails (sans aucune restriction – donc peu importe si l’IP utilisée avec le domaine laredoute.fr soit déclaré dans SPF ou non…). Je rajouterai qu’aucun enregistrement DMARC est présent sur le domaine principal, ce qui le rend “incroyablement” vulnérable. Et SPF a ici aucun intérêt !!!
Conseil : Privilégier de base le mécanisme/qualifieur “~all” par défaut si vous n’êtes pas prêt à passer en mode “strict” (“-all”).
Conseil #9 : Vérifier sa configuration après toute modification…
Quand votre enregistrement SPF est en place (ou si vous le modifiez à un instant T), il est important d’utiliser un outil externe (comme Mxtoobox ou Dmarcanalyzer) qui vous permettra en une fraction de seconde de vérifier que votre enregistrement SPF est correct. Sachez que si celui-ci renvoie une erreur, vous risquez d’être tagué comme «suspect» par le FAI / Webmail et donc voir vos e-mails ne pas être délivrés ou délivrés en courrier indésirable.
— Pas de BadExemple sur les entreprises du TOP 100 E-Commerce et du CAC40. Un cas client pour lequel nous faisons du monitoring avait fait des modifications sur nos recommandations mais avait malheureusement fait une erreur de syntaxe qui rendait SPF invalide.
Conseil : Pensez TOUJOURS à vérifier votre enregistrement SPF après toute création ou modification pour vous assurer que tout est ok (surtout que ça ne vous prendra que quelques secondes). Durant cette étape, dites à toutes vos équipes de ne réaliser aucun envoi d’e-mails.
Conseil #10 : Monitorer SPF via DMARC…
Paramétrer SPF sur votre domaine est bien, ajouter DMARC en plus c’est mieux! Grâce aux rapports agrégés fournis par DMARC, vous pourrez monitorer les flux SPF et identifier :
- Les IP non légitimes qui envoient des e-mails avec votre domaine et à votre insu !
- Les IP légitimes mais oubliées dans le paramétrage de SPF (et rend le trafic non conforme).
Vous n’aurez pas d’autre façon de savoir si une IP non légitime utilise votre domaine (à moins de recevoir directement un spam sur son adresse professionnelle ou personnelle).
— Pas de BadExemple pour ce point 10 même si encore aujourd’hui, 42 entreprises du TOP100 E-Commerce ayant un enregistrement SPF n’ont pas encore déployé DMARC sur leur domaine principal contre 14 entreprises du CAC40.
Conseil : Si vous n’avez pas encore franchi le cap avec l’implémentation de DMARC sur votre domaine principal, lancez-vous. L’avantage de DMARC est que vous pourrez avoir une visibilité détaillée du trafic IP passant via votre domaine. Et comme je l’ai dit en début d’article, aucune entreprise n’est à l’abri du spam et du phishing.
Conclusion
Maintenant à vous de jouer, vous avez toutes les cartes en main pour produire ou optimiser votre enregistrement SPF. Je me répète encore une fois mais aucune entreprise est à l’abri un jour de subir une attaque de phishing, ainsi l’implémentation des systèmes d’authentification (SPF/DKIM/DMARC/BIMI) est limite “obligatoire”. Pensez-y si 🙂
P.S : J’espère que les entreprises mentionnées en exemple en profiteront pour corriger le leur (si vous me lisez :p)
Vous pouvez également consulter nos derniers articles sur l’authentification e-mails:
- Qu’est-ce que SPF??
- Etat des lieux de l’usage de DMARC dans les entreprises du CAC40 en Juillet 2020
- BIMI c’est bon, mangez-en !
- Délivrabilité : SPF, DKIM, DMARC, … ce qu’il faut savoir sur l’authentification de vos emails !
Badsender, agitateur d’expertise emailing ! Badsender, c’est une équipe d’artisans spécialistes des différentes disciplines qui entourent l’email marketing ! Notre agence emailing intervient sur des questions des stratégie, de conception, d’orchestration et de délivrabilité. Cette expertise, nous vous la proposons sous forme de coaching, d’audits, ou d’intervention en tant que force de production externalisée.
