En février 2024, Google a rendu DKIM obligatoire pour les expéditeurs en volume : tout domaine envoyant plus de 5 000 messages par jour vers Gmail. Beaucoup d’équipes ont réagi en vérifiant leur enregistrement SPF puis ont considéré le sujet clos. C’est précisément dans cet écart que la délivrabilité s’effondre. SPF et DKIM authentifient des objets différents à des points différents de la chaîne de livraison. L’un qui passe sans l’autre produit une authentification partielle et l’authentification partielle est ce que DMARC sanctionne. Ce guide répond aux questions les plus fréquentes sur ces deux protocoles avec la syntaxe exacte, des scénarios de panne réels et les règles d’alignement qui les gouvernent.
Qu’est-ce que SPF authentifie réellement ?
SPF, défini dans la RFC 7208, authentifie le serveur d’envoi, pas le message. Il répond à une seule question : cette adresse IP est-elle autorisée à envoyer du courrier pour le compte de ce domaine ?
Le domaine concerné est l’adresse Return-Path (appelée aussi envelope sender ou RFC5321.MailFrom), pas l’en-tête From que le destinataire voit. Quand un serveur de réception reçoit un message, il extrait le domaine du Return-Path, interroge son enregistrement DNS TXT puis vérifie si l’IP connectée figure dans la liste.
Un enregistrement SPF standard ressemble à ceci :
v=spf1 a mx include:_spf.google.com include:sendgrid.net ~all
Les mécanismes sont évalués de gauche à droite. a autorise l’enregistrement A du domaine. mx autorise ses serveurs de messagerie. include: délègue à un enregistrement SPF tiers. Le qualificateur final contrôle la gestion des échecs : ~all (softfail) indique aux serveurs de réception d’accepter mais de signaler les IP non reconnues, tandis que -all (hardfail) leur demande de rejeter.
Pour inspecter un enregistrement SPF en direct depuis la ligne de commande :
dig TXT example.com +short
Une contrainte structurelle compte ici : les enregistrements SPF sont limités à 10 résolutions DNS. Chaque directive include: compte pour une résolution. Les chaînes qui imbriquent des include à travers plusieurs ESP atteignent souvent ce plafond ; SPF renvoie alors un permerror, qui compte comme un échec et non comme une validation.
Qu’est-ce que DKIM authentifie et pourquoi c’est différent ?
DKIM, défini dans la RFC 6376, authentifie le message lui-même. Il utilise la cryptographie asymétrique pour créer une signature numérique sur certains en-têtes et le corps du message. La clé privée reste sur le serveur d’envoi. La clé publique correspondante est publiée en DNS sous la forme d’un enregistrement TXT sur un sous-domaine sélecteur.
Quand un message arrive sur un serveur de réception, ce serveur lit l’en-tête DKIM-Signature, extrait les valeurs d= (domaine) et s= (sélecteur), interroge le DNS, récupère la clé publique puis vérifie la signature. Si les en-têtes et le corps correspondent à la signature, DKIM passe.
Un en-tête DKIM-Signature dans un message réel ressemble à :
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type; bh=UErATeHehIIPIXPeUAfZWiKo0w2cSsOhb9XM9ulqTX0=; b=NaHRSJOb...
Les champs clés : d= est le domaine signataire, s= est le sélecteur, bh= est le hash du corps, b= est la signature elle-même. Le paramètre c= spécifie la canonicalisation : relaxed/relaxed tolère les variations mineures d’espaces ; simple/simple ne les tolère pas.
Pour vérifier la clé publique d’un domaine et d’un sélecteur donnés :
dig TXT selector1._domainkey.example.com +short
La réponse contiendra un enregistrement commençant par v=DKIM1; k=rsa; p= suivi de la clé publique encodée en base64. Une réponse vide ou un NXDOMAIN signifie que la clé publique n’est pas publiée ; la vérification DKIM échoue alors pour tous les messages signés avec ce sélecteur.
Quelle est la différence fondamentale entre SPF et DKIM ?
| Critère | SPF | DKIM |
|---|---|---|
| Ce qu’il authentifie | Serveur d’envoi (adresse IP) | Contenu du message et domaine signataire |
| Type d’enregistrement DNS | TXT sur le domaine racine | TXT sur le sous-domaine selector._domainkey |
| Domaine vérifié | Return-Path (envelope sender) | Valeur d= dans l’en-tête DKIM-Signature |
| Survit au forwarding | Non : l’IP change en transit | Oui : la signature voyage avec le message |
| Détecte l’altération du contenu | Non | Oui : un hash qui ne correspond pas casse la signature |
| Domaine d’alignement DMARC | Doit correspondre au domaine From: | Doit correspondre au domaine From: |
L’échec sur le forwarding est la faille la plus lourde en exploitation. Quand le serveur d’un destinataire transfère automatiquement un message vers une autre adresse, l’IP du serveur qui relaie ne figure pas dans le SPF de l’expéditeur d’origine. SPF échoue. DKIM voyage dans les en-têtes du message et survit, à condition que le serveur qui relaie ne modifie pas les portions signées du message.
Pourquoi faut-il les deux, SPF et DKIM ?
Les bulk sender guidelines de Google, effectives depuis le 1er février 2024, imposent aux domaines envoyant 5 000 messages ou plus par jour vers Gmail d’avoir à la fois SPF et DKIM configurés ; pas l’un ou l’autre. Yahoo Mail applique la même exigence. Depuis mai 2025, Microsoft impose la même pile aux expéditeurs à fort volume vers Outlook.
La raison s’appelle DMARC. Sans les deux méthodes d’authentification, un expéditeur n’a aucune redondance. Si SPF échoue à cause du forwarding, DKIM peut encore satisfaire DMARC. Si DKIM est absent, l’échec de SPF laisse le message sans aucun signal d’authentification valide.
« Vous devriez toujours implémenter à la fois SPF et DKIM. » Valimail, DKIM vs SPF: What’s the difference and do you need both?
L’argument de la couverture est pragmatique. SPF couvre l’authentification au niveau serveur ; DKIM couvre l’intégrité du message. Un message peut passer SPF (le bon serveur l’a envoyé) tout en transportant un contenu altéré. DKIM attrape ce cas. Un message peut porter une signature DKIM valide mais provenir d’un serveur non autorisé. SPF attrape ce cas. Ils couvrent des surfaces d’attaque différentes.
Qu’est-ce que l’alignement DMARC et comment relie-t-il SPF et DKIM ?
DMARC n’ajoute pas une troisième méthode d’authentification. Il ajoute une couche d’alignement par-dessus SPF et DKIM. Pour qu’un message passe DMARC, l’une de ces conditions au moins doit être remplie :
- SPF passe et le domaine Return-Path s’aligne avec le domaine From:
- DKIM passe et le domaine signataire d= s’aligne avec le domaine From:
L’alignement fonctionne selon deux modes : relaxed (par défaut) et strict. En mode relaxed, les domaines d’organisation doivent correspondre : mail.example.com s’aligne avec example.com. En mode strict, les domaines doivent être identiques. L’enregistrement DMARC pilote ce comportement :
v=DMARC1; p=quarantine; aspf=r; adkim=r; rua=mailto:dmarc@example.com
Ici, aspf=r active l’alignement SPF relaxed, adkim=r active l’alignement DKIM relaxed et p=quarantine envoie les messages en échec vers le spam au lieu de les rejeter d’emblée. Passer à p=reject est la cible pour les domaines qui appliquent une politique stricte.
C’est la partie que la plupart des équipes ratent : un SPF qui passe sans alignement échoue quand même DMARC. Authentification et alignement sont des contrôles distincts. Un message où SPF passe sur le domaine Return-Path de l’ESP (em.mailchimp.com) alors que le From: affiche votre domaine de marque (company.com) échoue l’alignement SPF de DMARC. DKIM doit alors passer avec d=company.com pour rattraper la situation.
Pourquoi les envois via ESP cassent-ils l’alignement SPF ?
C’est le scénario d’échec le plus fréquent pour les équipes marketing qui utilisent Mailchimp, Brevo, HubSpot ou SendGrid. Le problème vient du Return-Path.
Quand vous envoyez via un ESP tiers, la plateforme injecte son propre domaine dans le Return-Path : par exemple bounce-123@em123.mailchimp.com. C’est ainsi que fonctionne la gestion des bounces ; l’ESP a besoin de recevoir les NDR (non-delivery reports) pour tracer les hard bounces. Le SPF qui passe est celui de l’ESP, pas le vôtre. L’en-tête From: affiche votre domaine. L’alignement SPF échoue.
Comme le précise la documentation de Valimail sur l’alignement, l’alignement SPF se produit quand le domaine d’organisation du Return-Path correspond au domaine d’organisation de l’adresse From visible par l’utilisateur. Quand un ESP détient le Return-Path, cette correspondance n’existe pas par défaut.
Deux correctifs existent. Premier : utiliser un sous-domaine de Return-Path personnalisé sur votre propre domaine, par exemple bounce.example.com, que l’ESP utilise pour router les NDR ; ajoutez ce sous-domaine à votre enregistrement SPF. Second : s’appuyer sur l’alignement DKIM à la place. Configurez la signature DKIM avec votre propre domaine dans l’ESP (toutes les grandes plateformes proposent cela sous l’étiquette « domain authentication » ou « custom DKIM »). Votre domaine From: devient le domaine signataire d=. L’alignement DKIM passe. DMARC passe même quand l’alignement SPF ne passe pas.
La plupart des praticiens de délivrabilité retiennent la seconde option. Elle est plus propre, n’impose pas de modifier le routage des bounces de l’ESP et ne consomme pas le budget de résolution SPF.
Qu’est-ce qui casse DKIM précisément ?
DKIM échoue quand les portions signées du message sont modifiées entre l’envoi et la réception. Trois causes expliquent la majorité des pannes en production.
Les logiciels de mailing list qui ajoutent un footer au corps du message invalident le hash du corps (bh=). La signature ne correspond plus au contenu que le destinataire voit. Du point de vue de DKIM, c’est identique à une altération de contenu ; il ne peut pas distinguer une réécriture malveillante d’un footer ajouté de bonne foi.
Les passerelles de sécurité de contenu (outils de réécriture de liens déployés par les entreprises, y compris la réécriture d’URL de Microsoft Defender for Office 365) peuvent casser DKIM si elles modifient des en-têtes couverts par la signature. Le tag h= dans la DKIM-Signature liste exactement les en-têtes signés. Toute modification de ces en-têtes invalide la signature quelle que soit l’intention.
La canonicalisation joue sur la résilience. Le paramètre c=relaxed/relaxed tolère une normalisation mineure des espaces. Le paramètre c=simple/simple échoue au moindre reformatage. La plupart des infrastructures d’envoi modernes utilisent relaxed/relaxed pour survivre à la normalisation des sauts de routage. Si vous constatez des échecs DKIM intermittents sans cause évidente, vérifiez que la configuration de signature n’utilise pas la canonicalisation simple.
La taille de clé est une question à part. Une clé RSA de 1024 bits fonctionne mais est considérée comme faible par les standards actuels. Une clé de 2048 bits est le minimum recommandé. Microsoft 365, depuis son format DKIM mis à jour en mai 2025, supporte la rotation vers 2048 bits via Rotate-DkimSigningConfig -Identity contoso.com -KeySize 2048.
Comment vérifier SPF et DKIM en ligne de commande ?
Pour SPF, interrogez directement les enregistrements TXT du domaine :
dig TXT example.com +short | grep spf
Pour compter la profondeur de résolution SPF sur toute la chaîne d’include, des outils comme MXToolbox SPF Checker acceptent un domaine et renvoient le parcours complet, y compris le mécanisme qui a matché et le nombre total de résolutions. Au-dessus de 9, c’est un risque.
Pour DKIM, il faut d’abord le sélecteur. Il se trouve dans l’en-tête DKIM-Signature de n’importe quel message sortant. Extrayez-le des en-têtes bruts d’un message envoyé puis interrogez :
dig TXT selector1._domainkey.example.com +short
Une réponse valide ressemble à :
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ...
Si vous voyez un enregistrement mais que DKIM échoue toujours dans les en-têtes Authentication-Results, la désynchronisation vient de la clé privée utilisée par l’expéditeur par rapport à la clé publique publiée en DNS. Cela arrive typiquement après une rotation de clé où le TTL DNS n’a pas encore expiré sur l’ancien enregistrement.
Que se passe-t-il quand SPF et DKIM échouent tous les deux ?
La politique DMARC détermine l’issue. Sous p=none, le message passe quand même ; le mode none est purement de monitoring et génère des rapports sans action. Sous p=quarantine, le message est routé vers le spam. Sous p=reject, le serveur de réception refuse le message au niveau SMTP avec un 5xx permanent failure.
Le seuil de taux de spam de Google ajoute une seconde couche. Les domaines qui dépassent 0,10 % de plaintes pour spam commencent à voir leur inbox placement se dégrader selon les guidelines publiées par Google. Au-dessus de 0,30 %, Gmail commence à throttler ou rejeter les messages indépendamment de l’état d’authentification. Le taux de spam est visible dans Google Postmaster Tools au niveau du domaine et son suivi n’est pas optionnel pour les domaines qui envoient à grande échelle.
Un message qui passe les trois contrôles d’authentification produit un en-tête Authentication-Results comme celui-ci :
Authentication-Results: mx.google.com; dkim=pass header.i=@example.com header.s=selector1; spf=pass smtp.mailfrom=example.com; dmarc=pass action=none header.from=example.com
Un message qui échoue sur les deux avec une politique quarantine produit :
Authentication-Results: mx.google.com; dkim=fail; spf=fail smtp.mailfrom=em123.mailchimp.com; dmarc=fail action=quarantine header.from=example.com
Quel est l’ordre de mise en place recommandé pour les expéditeurs en volume ?
La séquence compte. Passer directement à l’enforcement sans données de référence revient à rejeter du trafic légitime dont vous ignoriez l’existence.
Commencez par publier SPF avec ~all puis vérifiez que le compte de résolutions reste sous 10. Configurez ensuite la signature DKIM sur chaque source d’envoi : votre MTA principal, votre ESP, les services transactionnels comme Postmark ou Amazon SES. Chaque source d’envoi a besoin de son propre sélecteur et de sa propre paire de clés publiée en DNS.
Une fois les deux en place, publiez DMARC en p=none avec une adresse de reporting agrégé rua=. Les rapports montrent, par source d’envoi, quelle fraction de messages passe l’alignement SPF et l’alignement DKIM. Travaillez à partir de ces données. Passez à p=quarantine uniquement quand les rapports confirment des taux de passage cohérents au-dessus de 95 % sur toutes les sources légitimes, puis à p=reject quand le taux d’échec résiduel s’explique entièrement par des sources que vous ne contrôlez pas.
Le sujet suivant que les équipes rencontrent après avoir stabilisé l’authentification est la rotation de clés. Les clés privées DKIM ne sont pas limitées dans le temps par défaut ; plus une clé vit longtemps, plus la fenêtre d’exposition est large en cas de compromission. Microsoft 365 demande 96 heures pour propager une rotation. Ces 4 jours de latence sont la raison pour laquelle les calendriers de rotation existent avant les incidents, pas à cause d’eux.
