SPF et DKIM : quelle différence ?
SPF (Sender Policy Framework, RFC 7208) répond à la question « ce serveur a-t-il le droit d'envoyer pour ce domaine ? ». Il porte sur le domaine de l'adresse d'enveloppe, le Return-Path, que le destinataire ne voit pas. DKIM (DomainKeys Identified Mail, RFC 6376) répond à la question « ce message a-t-il été signé par ce domaine et est-il resté intact ? ». La signature survit au transfert d'un message, là où SPF échoue souvent quand un e-mail est redirigé, puisque le serveur qui relaie n'est pas autorisé. Les deux sont complémentaires, et DMARC exige qu'au moins l'un des deux réussisse avec un domaine aligné sur le champ « De ».
L'enregistrement SPF : syntaxe et exemple
SPF se publie en enregistrement TXT à la racine du domaine (ou du sous-domaine qui sert d'adresse d'enveloppe). Il commence par v=spf1, liste les sources autorisées et se termine par une règle pour tout le reste. Exemple : v=spf1 include:_spf.google.com include:spf.prestataire-emailing.com ip4:203.0.113.10 ~all. Ici, include: autorise les serveurs déclarés par un autre domaine (votre messagerie, votre outil d'emailing), ip4: autorise une adresse IP précise, et ~all qualifie tout autre serveur. Chaque prestataire fournit sa propre valeur include: dans sa documentation.
La limite de 10 recherches DNS
La norme SPF limite à 10 le nombre de mécanismes qui déclenchent une recherche DNS lors de l'évaluation : include, a, mx, ptr, exists et le modificateur redirect. Les include imbriqués comptent aussi : un seul include de prestataire peut en consommer plusieurs. Au-delà de 10, le résultat est une erreur permanente (permerror), que la plupart des messageries traitent comme un échec. Les mécanismes ip4, ip6 et all ne comptent pas. Pour rester sous la limite : retirer les prestataires que vous n'utilisez plus, faire envoyer certains outils depuis un sous-domaine qui a son propre SPF, ou remplacer des include par des plages IP quand le prestataire les publie et s'engage à les maintenir.
~all ou -all : que choisir ?
- -all (fail) : tout serveur non listé échoue. Le plus strict.
- ~all (softfail) : tout serveur non listé est suspect, sans échec franc. Le plus répandu.
- ?all (neutral) : aucune indication, sans intérêt pour un domaine qui envoie.
- +all : autorise n'importe quel serveur du monde. À ne jamais utiliser.
- En pratique, avec DMARC en place, ~all suffit généralement : c'est DMARC qui porte la consigne de rejet. -all peut faire rejeter un message transféré avant même que sa signature DKIM soit prise en compte par certains serveurs.
- Pour un domaine qui n'envoie aucun e-mail, publiez v=spf1 -all.
DKIM : sélecteur, clé et signature
Le serveur d'envoi signe chaque message avec une clé privée et ajoute un en-tête DKIM-Signature. Celui-ci contient notamment le domaine signataire (d=) et un sélecteur (s=), qui indique où trouver la clé publique : à l'adresse selecteur._domainkey.exemple.fr, en enregistrement TXT ou, chez beaucoup de prestataires, en CNAME qui pointe vers une clé qu'ils gèrent. Le sélecteur permet d'avoir plusieurs clés actives à la fois, une par outil d'envoi. Google recommande une clé RSA de 2 048 bits ; 1 024 bits reste accepté mais n'est plus recommandé. Point clé pour DMARC : le domaine d= doit être le vôtre, pas celui de l'outil d'emailing, sinon la signature réussit mais ne s'aligne pas.
La rotation des clés DKIM
Une clé DKIM utilisée pendant des années finit par représenter un risque : fuite, longueur devenue insuffisante. La rotation se fait sans coupure grâce aux sélecteurs : publier une nouvelle clé sous un nouveau sélecteur, basculer la signature sur celle-ci, conserver l'ancienne clé publiée quelques jours le temps que les messages en transit soient vérifiés, puis la retirer. Les prestataires qui publient leur clé derrière un CNAME font souvent cette rotation eux-mêmes. Le groupe professionnel M3AAWG recommande une rotation régulière dans ses bonnes pratiques.
Comment vérifier SPF et DKIM sur un vrai message
Envoyez un e-mail depuis l'outil à tester vers une boîte Gmail, ouvrez-le, puis menu « ⋮ » et « Afficher l'original ». Gmail affiche en tête le résultat de SPF, DKIM et DMARC (PASS ou FAIL) et le domaine concerné. Dans l'en-tête complet, la ligne Authentication-Results donne le détail, par exemple : spf=pass smtp.mailfrom=news.exemple.fr ; dkim=pass header.i=@exemple.fr ; dmarc=pass header.from=exemple.fr. Vérifiez trois choses : SPF à pass, DKIM à pass, et des domaines qui appartiennent bien à votre domaine du champ « De ». Faites le test pour chaque outil qui envoie en votre nom, pas seulement pour la messagerie.
Les erreurs SPF et DKIM fréquentes
- Deux enregistrements SPF sur le même domaine : la norme impose un seul enregistrement v=spf1, sinon SPF renvoie une erreur. Fusionnez-les en un seul.
- Un prestataire oublié : l'outil de facturation, le CRM ou le site e-commerce envoie avec votre domaine sans être autorisé ni signer.
- Plus de 10 recherches DNS après l'ajout d'un nouvel outil.
- DKIM activé avec le domaine du prestataire au lieu du vôtre : signature valide, mais pas d'alignement DMARC.
- Enregistrement DKIM mal collé : clé tronquée, guillemets ou espaces en trop, chaîne de plus de 255 caractères non découpée.
- Ancien prestataire laissé dans le SPF après son départ : il peut toujours envoyer en votre nom.
Ce que fait Vandolo
Vandolo ne configure ni SPF ni DKIM et ne vérifie pas leurs résultats : ces réglages se font chez votre hébergeur DNS et dans chacun de vos outils d'envoi. Le volet newsletter du module Croissance & acquisition (95 € HT par mois) lit les résultats de vos campagnes depuis votre outil d'emailing connecté — délivrés, clics, désinscriptions, rebonds si l'outil les fournit.