SPF : la première ligne de défense contre le spoofing
Le Sender Policy Framework (SPF) est un mécanisme d'authentification e-mail qui permet au propriétaire d'un domaine de spécifier quels serveurs sont autorisés à envoyer des e-mails en son nom. Sans SPF, n'importe qui peut envoyer des e-mails en faisant apparaître votre domaine comme expéditeur — une technique appelée spoofing qui est à la base de la plupart des attaques de phishing. SPF a été standardisé dans la RFC 7208 et représente le premier des trois piliers de l'authentification e-mail moderne, aux côtés de DKIM et DMARC.
Lorsqu'un serveur reçoit un e-mail, il vérifie l'enregistrement SPF du domaine expéditeur. Si l'IP du serveur qui a envoyé l'e-mail figure dans la liste des IP autorisées par l'enregistrement SPF, la vérification réussit. Dans le cas contraire, l'e-mail est signalé comme potentiellement frauduleux. La décision finale (accepter, rejeter ou signaler) dépend de la politique spécifiée dans l'enregistrement et de la configuration DMARC du domaine.
Anatomie d'un enregistrement SPF
Un enregistrement SPF est un enregistrement TXT dans le DNS du domaine qui commence par v=spf1 suivi d'une série de mécanismes et de qualificateurs. Les mécanismes définissent qui est autorisé à envoyer, tandis que le qualificateur final (typiquement ~all ou -all) définit ce qu'il faut faire des e-mails qui ne correspondent à aucun mécanisme autorisé.
La limite des 10 résolutions DNS
L'un des aspects les plus critiques et les moins compris de SPF est la limite des 10 résolutions DNS. Chaque fois que l'enregistrement SPF utilise un mécanisme nécessitant une requête DNS supplémentaire (include, a, mx, redirect, exists), cela compte comme une résolution. Dépasser la limite de 10 provoque un permerror : l'enregistrement SPF est considéré comme invalide et l'authentification échoue pour tous les e-mails.
Cette limite devient problématique lorsqu'on utilise de nombreux services tiers pour l'envoi d'e-mails. Un seul include peut contenir à son tour d'autres includes imbriqués, et chacun compte dans la limite. Par exemple, include:_spf.google.com consomme à lui seul déjà 3 à 4 résolutions. Ajoutez Mailchimp, SendGrid, HubSpot et la limite est rapidement atteinte. Notre SPF Lookup analyse votre enregistrement SPF et compte automatiquement les résolutions DNS, vous avertissant si vous approchez de la limite.
Comment résoudre les problèmes SPF les plus courants
Le problème le plus fréquent est le dépassement de la limite de 10 résolutions. Les solutions incluent : remplacer les mécanismes include par des entrées directes ip4/ip6 (qui ne comptent pas comme des résolutions), utiliser des services de SPF flattening qui résolvent les includes en IP statiques, ou consolider les services de messagerie pour réduire le nombre d'includes nécessaires. Une autre stratégie consiste à utiliser des sous-domaines dédiés pour différents services : marketing@news.exemple.com peut disposer de son propre enregistrement SPF indépendant.
Une autre erreur courante est d'avoir plusieurs enregistrements SPF pour le même domaine. Les RFC spécifient clairement qu'un domaine ne doit avoir qu'un seul enregistrement TXT commençant par v=spf1. Des enregistrements multiples provoquent un permerror. Si vous devez autoriser plusieurs sources, combinez le tout en un seul enregistrement. Vérifiez la présence d'enregistrements dupliqués avec le TXT Lookup, qui liste tous les enregistrements TXT du domaine.
SPF seul ne suffit pas : le trio SPF + DKIM + DMARC
SPF présente une limitation importante : il ne vérifie que l'IP du serveur expéditeur, pas le contenu de l'en-tête From que l'utilisateur voit. Un attaquant pourrait utiliser un serveur autorisé par son propre SPF pour envoyer des e-mails avec votre domaine dans l'en-tête From. C'est pourquoi SPF doit être accompagné de DKIM et DMARC. DKIM signe cryptographiquement l'e-mail, tandis que DMARC vérifie que le domaine dans l'en-tête From est aligné avec le domaine authentifié par SPF ou DKIM.
Utilisez le DMARC Lookup pour vérifier que votre domaine dispose d'une politique DMARC active. Sans DMARC, même un SPF parfait n'empêche pas les e-mails usurpés d'être livrés. La combinaison des trois protocoles crée une défense en profondeur qui rend l'usurpation de votre domaine extrêmement difficile, protégeant votre réputation et vos destinataires.
La configuration idéale comprend : SPF avec ~all ou -all pour n'autoriser que les serveurs légitimes, DKIM avec une clé de 2048 bits pour signer tous les e-mails sortants, et DMARC avec une politique progressive (de p=none pour la surveillance à p=reject pour le blocage total). Ce trio est aujourd'hui considéré comme le minimum requis pour tout domaine qui envoie des e-mails.