Quelle est la différence entre SPF et DKIM ? [Mise à jour 2026]

Si votre domaine envoie 5 000 emails ou plus par jour aux utilisateurs Gmail, Yahoo ou Outlook, ces trois fournisseurs exigent désormais l'authentification SPF, DKIM et DMARC. Si l'une d'elles échoue, vos emails n'atterrissent pas en spam. Ils rebondissent. Selon le guide 2026 de MailOver pour les gros expéditeurs, les emails non conformes sont rejetés au niveau SMTP.

J'ai vu des équipes perdre des campagnes entières à cause d'un seul enregistrement DNS manquant. Un caractère erroné dans une entrée SPF, une clé DKIM expirée, et soudain chaque cold email renvoie une erreur 550. La solution est presque toujours la même : comprendre ce que SPF et DKIM font réellement, en quoi ils diffèrent, et les configurer correctement.

Dans cet article, je détaille le fonctionnement de SPF et DKIM, leurs différences techniques, pourquoi vous avez besoin des deux (surtout avec les règles 2026), et comment vérifier que vos enregistrements sont bien configurés.

Points clés

• •

  SPF valide le serveur qui envoie votre email. DKIM valide le contenu de l'email lui-même.

• •

  Les deux sont des enregistrements DNS, mais ils protègent contre des vecteurs d'attaque différents.

• •

  Gmail, Yahoo et Outlook exigent tous SPF et DKIM pour les gros expéditeurs (5 000+ emails/jour). Si l'un des deux manque, vos emails sont rejetés.

• •

  Selon PowerDMARC, les expéditeurs conformes atteignent en moyenne 89 % de placement en inbox en 2026, tandis que les non-conformes voient 22 à 34 % de leurs emails redirigés vers le spam.

Les différences clés entre SPF et DKIM

En résumé :

SPF garantit que seuls les serveurs autorisés peuvent envoyer des emails au nom de votre domaine. DKIM garantit que le contenu de l'email n'a pas été modifié en transit.

Ils agissent à des niveaux différents, protègent contre des menaces différentes et se configurent différemment. Voyons chacun en détail.

SPF expliqué

SPF, pour Sender Policy Framework, vous permet de spécifier quels serveurs sont autorisés à envoyer des emails depuis votre domaine.

Par exemple :

Si vous utilisez Salesforce pour envoyer des emails, vous ajouteriez leur serveur à votre enregistrement SPF.

L'enregistrement SPF ressemblerait à ceci :

v=spf1 include:_spf.salesforce.com ~all

Avec ce serveur autorisé, tout serveur autre que celui de Salesforce fera échouer l'authentification des emails.

Autrement dit, SPF bloque l'usurpation d'email (spoofing). Les cybercriminels utilisent le spoofing pour envoyer des emails en se faisant passer pour un domaine de confiance.

Avec les bons réglages, les emails provenant de serveurs non autorisés n'atteindront pas leurs destinataires, ce qui contribue à rendre Internet plus sûr.

Comme les emails authentifiés par SPF sont considérés comme plus fiables, ils peuvent améliorer votre réputation d'expéditeur et augmenter vos taux d'ouverture.

Soft fail vs. hard fail (et la limite des 10 résolutions)

Le ~all à la fin de l'enregistrement SPF ci-dessus est un soft fail. Il indique aux serveurs de réception « si l'expéditeur n'est pas listé, signalez-le mais ne le rejetez pas forcément ». Un hard fail (-all) indique aux serveurs de rejeter le message directement.

La plupart des configurations de délivrabilité utilisent ~all parce que c'est plus souple pendant les tests. Une fois que vous êtes sûr de votre enregistrement SPF, passer à -all vous offre une protection renforcée.

Un point à surveiller : les enregistrements SPF ont une limite de 10 résolutions DNS. Chaque mécanisme include:, a: ou mx: compte dans cette limite. Au-delà de 10, votre enregistrement SPF entier échoue silencieusement. J'ai débuggé ce problème pour des équipes qui avaient cinq outils différents dans leur enregistrement SPF et ne comprenaient pas pourquoi l'authentification cassait. Si vous utilisez plusieurs ESP, CRM et outils de prospection, comptez vos résolutions.

DKIM expliqué

Alors que SPF agit au niveau du serveur, DKIM s'intéresse au contenu de l'email.

Si un email échoue à l'authentification DKIM, cela signifie que son contenu a été modifié en transit. Cela peut signaler une altération, même si un transfert légitime ou le traitement par une liste de diffusion peuvent aussi casser DKIM.

DKIM empêche l'altération en utilisant des clés cryptographiques publiques et privées pour signer numériquement les emails.

Votre fournisseur de messagerie ou outil d'envoi fournit les deux clés. La clé publique va dans votre enregistrement DKIM, et la clé privée n'est accessible que par votre ESP.

C'est généralement l'ESP qui décide quoi inclure dans la signature DKIM. Selon votre ESP, la signature DKIM peut couvrir l'adresse d'expéditeur, l'objet et le corps du message, ou seulement une partie de ces éléments.

Si l'une de ces variables est modifiée en transit, l'email échouera à l'authentification.

Le domaine de signature et la longueur de clé

La signature DKIM inclut un tag d= qui spécifie le domaine de signature. Pour que DMARC passe, le domaine du tag d= doit correspondre au domaine de votre en-tête From. C'est ce qu'on appelle l'alignement DKIM. Avoir une signature DKIM valide ne suffit pas. Si le domaine de signature ne correspond pas à votre domaine From, DMARC échouera quand même côté DKIM.

La longueur de clé compte aussi. Une clé de 1024 bits est le minimum accepté par la plupart des fournisseurs, mais 2048 bits est recommandé. Yahoo exige explicitement des clés d'au moins 1024 bits et rejettera les messages signés avec des clés de 512 bits. Si vous configurez DKIM via Google Workspace, la documentation DKIM de Google détaille le processus de génération des clés.

Pourquoi vous avez besoin de SPF et DKIM (et plus encore)

En 2026, Gmail, Yahoo et Outlook appliquent l'authentification avant même que votre email atteigne le dossier spam. Il rebondit, tout simplement.

Selon MailOver, si un domaine envoie 5 000 emails ou plus par jour aux utilisateurs Gmail, Yahoo ou Outlook, ces trois fournisseurs exigent désormais l'authentification SPF, DKIM et DMARC, un taux de plaintes spam inférieur à 0,3 %, et un mécanisme de désinscription simple. Les conséquences sont réelles : PowerDMARC rapporte que les expéditeurs conformes atteignent en moyenne 89 % de placement en inbox en 2026, tandis que les non-conformes voient 22 à 34 % de leurs emails redirigés vers le spam.

Un bon taux d'ouverture s'obtient en ayant une config technique solide et en évitant tout contenu spammy.

SPF et DKIM font partie de votre config technique. Mais l'un sans l'autre ne suffit pas. Vous avez besoin des deux.

Et votre config technique ne s'arrête pas là. Vous avez aussi besoin de DMARC (qui couvre la règle des 5 000 emails/jour et les instructions complètes de configuration 2026) et d'un domaine de tracking personnalisé.

Quand vous connectez un domaine existant ou achetez un nouveau domaine d'envoi dans lemlist, la plateforme peut configurer l'authentification automatiquement via le Deliverability Hub. SPF, DKIM et DMARC, configurés correctement dès le départ. Cela élimine l'un des problèmes les plus fréquents que je constate : des erreurs de configuration DNS manuelles qui plombent silencieusement la délivrabilité pendant des semaines avant que quelqu'un ne s'en aperçoive.

Comment vérifier vos enregistrements SPF et DKIM

Configurer SPF et DKIM, c'est la moitié du travail. Vous devez aussi vérifier qu'ils fonctionnent. Voici un guide rapide.

1. Vérifiez votre enregistrement SPF. Utilisez un outil gratuit de résolution DNS comme MXToolbox (mxtoolbox.com) pour interroger les enregistrements TXT de votre domaine. Cherchez un enregistrement commençant par v=spf1. Vérifiez qu'il inclut tous les services depuis lesquels vous envoyez et que vous êtes en dessous de la limite des 10 résolutions.

2. Vérifiez votre enregistrement DKIM. Vous aurez besoin de votre sélecteur DKIM (votre ESP peut vous le fournir). Interrogez selector._domainkey.yourdomain.com en tant qu'enregistrement TXT. S'il renvoie une clé publique, DKIM est publié. S'il ne renvoie rien, votre enregistrement DKIM est manquant ou le sélecteur est incorrect.

3. Envoyez un email de test. Envoyez un message vers un compte Gmail, ouvrez-le, cliquez sur « Afficher l'original » et cherchez spf=pass et dkim=pass dans l'en-tête Authentication-Results. Si l'un des deux indique fail, vos enregistrements doivent être corrigés.

4. Utilisez un outil de délivrabilité. Des outils comme Google Postmaster Tools vous offrent une visibilité continue sur la façon dont Google perçoit l'authentification de votre domaine. Le vérificateur gratuit de configuration de délivrabilité de lemlist affiche vos statuts SPF, DKIM et DMARC en un coup d'œil.

SPF vs. DKIM en bref

• •

  SPF et DKIM sont tous deux implémentés via des enregistrements DNS

• •

  SPF assure l'authentification email au niveau du serveur

• •

  Si un email provient d'un serveur non autorisé, l'authentification échouera

• •

  DKIM assure l'authentification email au niveau du contenu

• •

  Si le contenu de l'une des variables prédéfinies diffère de ce qui figure dans la signature DKIM, l'authentification échouera

• •

  Dans l'enregistrement SPF, vous incluez le(s) serveur(s) autorisé(s) à envoyer des emails depuis votre domaine

• •

  L'enregistrement DKIM inclut la clé publique fournie par votre ESP ou outil d'envoi d'emails

• •

  SPF utilise ~all (soft fail) ou -all (hard fail) pour indiquer aux serveurs de réception comment traiter les expéditeurs non autorisés

• •

  DKIM utilise un domaine de signature d= qui doit correspondre à votre en-tête From pour que DMARC passe

• •

  DMARC décide ce qui arrive aux emails qui échouent. Selon la politique, ils peuvent passer normalement, atterrir en spam ou être rejetés. Vous configurez cela via DMARC, un autre enregistrement DNS d'authentification email.

Conclusion

SPF et DKIM font des choses différentes. SPF contrôle quels serveurs peuvent envoyer en votre nom. DKIM prouve que le message n'a pas été modifié. Vous avez besoin des deux, plus DMARC, et en 2026 ce n'est pas une recommandation. C'est une obligation appliquée par Gmail, Yahoo et Outlook avec des hard bounces.

Si vous faites du cold outbound, le plus rapide est de configurer l'authentification correctement avant que votre première campagne ne parte. Pas après une chute de délivrabilité.

Vous voulez que l'authentification soit gérée dès le jour 1 ? Démarrez l'essai gratuit de 14 jours.