En 2014, une petite entreprise d’e-commerce s’est réveillée en découvrant que quelqu’un avait envoyé 50 000 emails de phishing à ses clients — tous semblant provenir de leur domaine officiel. Les emails paraissaient légitimes. L’adresse de l’expéditeur était correcte. Les clients ont cliqué, saisi leurs coordonnées de carte bancaire, et l’entreprise a passé les six mois suivants à reconstruire la confiance qu’elle avait mis des années à gagner.
L’attaque a été rendue possible par un seul enregistrement DNS manquant : SPF.
SPF — Sender Policy Framework — est l’un de ces trucs qui sonnent techniques et ennuyeux jusqu’à ce qu’on comprenne ce que ça fait vraiment. C’est la différence entre « n’importe qui peut envoyer des emails en se faisant passer pour vous » et « seuls vos serveurs autorisés ont ce privilège ». C’est l’équivalent numérique d’un videur qui vérifie les pièces d’identité à l’entrée.
Le problème que SPF résout
Voici une vérité inconfortable sur l’email : l’adresse 'From' que vous voyez est essentiellement auto-déclarée. Quand vous recevez un email de [email protected], il n’y a rien, dans le protocole email, qui prouve qu’il provient réellement des serveurs de Big Company. L’expéditeur… affirme simplement que c’est le cas.
C’est comme si n’importe qui pouvait écrire n’importe quelle adresse de retour sur une lettre physique. Vous pourriez envoyer une lettre en prétendant provenir de la Maison-Blanche, et le service postal la livrerait sans poser de questions. C’est exactement comme cela que l’email a fonctionné pendant des décennies, et c’est pourquoi le phishing est devenu un problème massif.
SPF change cela en permettant aux propriétaires de domaines de publier une liste d’expéditeurs autorisés. Lorsqu’un email arrive en prétendant provenir de votre domaine, le serveur destinataire peut vérifier : « Est-ce que cela vient réellement d’un serveur autorisé à envoyer pour ce domaine ? » Si ce n’est pas le cas, l’email est signalé ou rejeté.
Comment ça fonctionne réellement
Voyons ce qui se passe lorsque vous envoyez un email depuis le domaine de votre entreprise, en supposant que SPF soit correctement configuré.
Vous rédigez un email dans Gmail ou votre client mail et vous cliquez sur Envoyer. Votre email arrive sur le serveur de messagerie de votre entreprise (ou le serveur de votre fournisseur d’email), qui se connecte au serveur de messagerie du destinataire. À ce stade, le serveur du destinataire voit deux choses : l’adresse IP du serveur qui tente de livrer l’email, et le domaine dans l’adresse 'From'.
Le serveur du destinataire effectue ensuite une requête DNS pour l’enregistrement SPF de votre domaine. Cet enregistrement contient une liste d’adresses IP et de domaines autorisés à envoyer des emails en votre nom. Si l’IP du serveur qui se connecte correspond à quelque chose dans cette liste, l’email passe SPF. Sinon, il échoue.
La vérification entière prend quelques millisecondes. L’expéditeur ne se rend même pas compte qu’elle a eu lieu. Mais cette simple requête fait la différence entre votre email qui arrive en boîte de réception et celui qui est signalé comme fraude potentielle.
Lire un enregistrement SPF
Les enregistrements SPF vivent dans votre DNS sous forme d’enregistrements TXT. Voici un exemple réel :
Cela semble cryptique, mais c’est en fait simple une fois que vous connaissez la syntaxe. Décomposons-le morceau par morceau.
Le 'v=spf1' au début déclare qu’il s’agit d’un enregistrement SPF (version 1 — il n’y a jamais eu qu’une seule version). Tout ce qui suit est une liste de ceux qui sont autorisés à envoyer.
'include:_spf.google.com' signifie « regarder l’enregistrement SPF de Google et faire confiance aux serveurs qu’ils y listent ». C’est ainsi que vous autorisez Google Workspace à envoyer des emails pour votre domaine sans avoir à lister chaque adresse IP de Google (ce qui représenterait des centaines d’entrées).
'include:amazonses.com' fait la même chose pour Amazon SES. Si vous utilisez SES pour des emails transactionnels, cela autorise leurs serveurs.
'ip4:203.0.113.42' autorise directement une adresse IP spécifique. Peut-être s’agit-il de votre propre serveur mail, ou d’un système legacy qui envoie des rapports.
Le '-all' à la fin est crucial. Cela signifie « rejeter tout ce qui ne correspond pas aux règles ci-dessus ». C’est ce qu’on appelle un 'hard fail'. Vous pouvez aussi voir '~all' (soft fail, qui marque les échecs comme suspects mais ne les rejette pas) ou '?all' (neutral, qui signifie essentiellement « Je ne sais pas, faites comme vous voulez »). Pour une vraie sécurité, vous voulez '-all'.
La limite des 10 recherches DNS
C’est là que SPF devient délicat, et où beaucoup d’entreprises rencontrent des problèmes.
Chaque instruction 'include' déclenche une requête DNS. Et SPF a une limite stricte de 10 requêtes DNS par vérification. Si vous dépassez cette limite, votre enregistrement SPF devient invalide — ce qui signifie que tous vos emails échouent SPF, même ceux provenant de serveurs légitimes.
Cette limite existe parce que les vérifications SPF se produisent en temps réel pendant la livraison des emails. Si un acteur malveillant pouvait créer un enregistrement SPF qui déclenche des centaines de requêtes DNS, il pourrait l’utiliser comme une attaque par déni de service contre l’infrastructure DNS. La limite de 10 requêtes empêche cela.
Le problème, c’est que les entreprises modernes utilisent de nombreux services qui envoient des emails : Google Workspace, une plateforme marketing, un service d’emails transactionnels, un outil de support client, peut-être un système RH. Chacun a besoin d’une instruction 'include', et chaque 'include' peut lui-même contenir d’autres 'include'. L’enregistrement SPF de Google à lui seul peut consommer 3 à 4 requêtes.
Si vous atteignez la limite, vous avez quelques options. Vous pouvez utiliser des services de 'SPF flattening' qui résolvent tous les include en adresses IP directes (bien que cela demande de la maintenance puisque les IP changent). Vous pouvez consolider l’envoi d’emails via moins de fournisseurs. Ou vous pouvez utiliser des sous-domaines — marketing.yourcompany.com pour les emails marketing, support.yourcompany.com pour le support — chacun avec son propre enregistrement SPF.
Les limites de SPF
SPF est essentiel, mais ce n’est pas une solution complète. Comprendre ses limites vous aide à construire une stratégie d’authentification email adéquate.
Premièrement, SPF vérifie l’adresse 'envelope from' (l’adresse de retour technique), et non l’adresse 'header from' (celle que les destinataires voient). Un attaquant peut passer SPF tout en affichant une adresse usurpée au destinataire. C’est pour cela que DMARC existe — il relie les résultats SPF et DKIM à l’adresse 'From' visible.
Deuxièmement, SPF pose problème lorsque les emails sont transférés. Si quelqu’un transfère votre email vers une autre adresse, l’IP du serveur de transfert ne figurera pas dans votre enregistrement SPF, donc l’email transféré échouera SPF. C’est une limitation fondamentale du protocole, et c’est pourquoi DKIM (qui signe le contenu de l’email) est important en complément.
Troisièmement, SPF n’indique aux serveurs récepteurs quoi faire des échecs que si vous utilisez '-all'. Beaucoup de domaines utilisent '~all' ou '?all' parce qu’ils ont peur de bloquer des emails légitimes. Mais cela signifie que les attaquants peuvent toujours envoyer des emails spoofés — ils seront simplement marqués comme suspects plutôt que rejetés.
Bien configurer SPF
Configurer SPF n’est pas difficile, mais bien le faire demande un peu de réflexion. Voici une approche qui fonctionne.
Commencez par auditer chaque service qui envoie des emails depuis votre domaine. C’est généralement plus nombreux que vous ne le pensez. Votre fournisseur d’email, évidemment. Mais aussi votre outil d’automatisation marketing, votre service d’emails transactionnels, votre CRM, votre helpdesk, votre système de facturation, voire votre imprimante (certaines envoient du scan-to-email). Faites une liste complète.
Pour chaque service, trouvez leur instruction d’include SPF. Elle figure généralement dans leur documentation sous « authentification email » ou « configuration DNS ». Ajoutez chacune à votre enregistrement SPF.
Commencez avec '~all' (soft fail) plutôt que '-all' (hard fail). Cela vous permet de surveiller les problèmes sans bloquer des emails légitimes. Surveillez vos rapports DMARC (vous collectez des rapports DMARC, n’est-ce pas ?) pour les échecs SPF. Si vous voyez des services légitimes échouer, ajoutez-les à votre enregistrement.
Une fois que vous avez passé quelques semaines sans échecs inattendus, passez à '-all'. C’est là que SPF commence réellement à vous protéger. Jusque-là, il n’est que consultatif.
Enfin, programmez un rappel dans votre calendrier pour revoir votre enregistrement SPF chaque trimestre. Les services évoluent, vous ajoutez de nouveaux outils, les IP tournent. Un enregistrement SPF obsolète est presque aussi mauvais que pas d’enregistrement SPF.
Frequently asked questions
Mon enregistrement SPF est correct mais les emails vont quand même dans le spam. Pourquoi ?
SPF n'est qu'un des facteurs de la délivrabilité. Les filtres anti-spam prennent aussi en compte la réputation de votre domaine, celle de votre IP, le contenu de l'email, les taux d'engagement, et le fait que vous ayez configuré DKIM et DMARC. Le fait de passer SPF ne garantit pas l'arrivée en boîte de réception — cela signifie simplement que vous avez franchi une étape.
Puis-je avoir plusieurs enregistrements SPF pour un même domaine ?
Non, et c'est une erreur courante. Si vous avez plusieurs enregistrements TXT qui commencent par 'v=spf1', les vérifications SPF échoueront. Vous devez avoir exactement un enregistrement SPF qui inclut tous vos expéditeurs autorisés.
Que se passe-t-il si je dépasse la limite de 10 recherches DNS ?
Votre enregistrement SPF devient invalide, et toutes les vérifications SPF renvoient 'permerror'. La plupart des serveurs récepteurs traitent cela comme un échec SPF, ce qui peut nuire à votre délivrabilité. Utilisez un outil de vérification SPF pour compter vos requêtes avant de publier des changements.
Dois-je utiliser -all ou ~all ?
Utilisez ~all pendant la configuration et les tests. Une fois que vous êtes certain que votre enregistrement SPF inclut tous les expéditeurs légitimes, passez à -all. Le soft fail (~all) ne vous protège pas réellement du spoofing — il se contente de signaler les emails suspects sans les rejeter.