SPF DKIM : quelle est la différence et faut-il utiliser les deux ?

Introduction

De nombreux SPF ne sont pas dus à un enregistrement mal configuré, mais au fait que l'e-mail a été transféré.

Un administrateur informatique configure SPF , vérifie que la validation est réussie et considère que le travail est terminé ; puis, un utilisateur transfère un message via un relais tiers. Le serveur destinataire détecte une adresse IP qui ne figure pas sur la liste autorisée, la validation échoue, l'administrateur vérifie l'enregistrement et constate qu'il semble correct. Le problème ne vient pas de l'enregistrement, mais SPF .

SPF ne suffit pas SPF pour l'authentification des e-mails, et SPF le DKIM ne remplissent pas la même fonction. Chaque protocole protège une couche différente du processus de distribution des e-mails. Si l'on supprime l'un ou l'autre, on laisse des failles que les infrastructures de transfert et les pirates peuvent exploiter, chacun à leur manière et pour des raisons différentes.

Dans cet article, vous découvrirez ce qui distingue SPF DKIM, pourquoi le transfert de messages perturbe le fonctionnement de l'un mais pas de l'autre, et pourquoi ces deux protocoles sont indispensables au bon fonctionnement du DMARC.

Qu'est-ce que SPF comment fonctionne-t-il ?

SPF Sender Policy Framework) est un protocole d'authentification des e-mails qui permet au propriétaire d'un domaine de spécifier quels serveurs de messagerie sont autorisés à envoyer des e-mails au nom de ce domaine.

Le domaine publie un SPF dans son DNS sous la forme d'une entrée TXT répertoriant les adresses IP et les serveurs approuvés. Lorsqu’un serveur de messagerie destinataire reçoit un message, il vérifie le domaine de l’expéditeur par rapport à cet enregistrement publié afin de confirmer que le serveur d’envoi est autorisé. 

En fonction du résultat, le destinataire décide d'accepter, de signaler ou de rejeter le message. SPF d'empêcher les spammeurs et les pirates de falsifier l'adresse de l'expéditeur, ce qui permet de réduire l'usurpation d'adresse e-mail et le phishing. Il fonctionne en tandem avec DKIM et DMARC pour vérifier la légitimité des messages. 

Quels sont SPF ?

SPF si le serveur qui envoie un message est autorisé à envoyer des e-mails pour le domaine dont il prétend provenir. Cette vérification a lieu dès qu'un serveur destinataire accepte la connexion entrante, avant même qu'il ne traite le corps du message.

Cependant, SPF vérifie SPF l'adresse d'expéditeur que vos destinataires voient réellement. Il vérifie uniquement l'expéditeur de l'enveloppe, également appelé « Return-Path » ou « MAIL FROM », qui est l'adresse utilisée en arrière-plan lors de la transaction SMTP. 

Un pirate peut donc passer SPF le domaine de l'enveloppe tout en affichant une fausse adresse d'expéditeur dans la boîte de réception. DMARC permet de combler cette lacune en associant le SPF au domaine d'expéditeur visible.

Le serveur récepteur prend deux entrées : 

1. L'adresse IP d'origine
2. Le domaine de l'expéditeur de l'enveloppe

Il recherche ensuite SPF de ce domaine dans le DNS. Il suit les mécanismes de l'enregistrement dans l'ordre, notamment ip4, ip6, a, mx, et inclure. Si l'adresse IP de l'expéditeur correspond à une source autorisée, SPF . S'il se poursuit jusqu'à la balise de fermeture tous sans avoir trouvé de correspondance, le résultat dépend de la façon dont vous avez configuré ce mécanisme.

SPF renvoie SPF simplement « oui » ou « non ». Il renvoie l'un des résultats suivants :

• Accès: Le serveur est autorisé.
• Échec (-all) : Non autorisé. Vous souhaitez que ce message soit rejeté.
• SoftFail (~tout) : Probablement non autorisé. Acceptez-le, mais signalez-le comme suspect.
• Neutre (?tout) : Vous ne prenez pas position dans un sens ou dans l'autre.
• Aucun: Il n'existe aucun SPF pour ce domaine.
• PermError / TempError: L'enregistrement est corrompu ou un problème DNS a bloqué la recherche.

Le serveur destinataire considère ce résultat comme un indicateur supplémentaire, au même titre que DKIM et DMARC, pour déterminer la légitimité de l'e-mail avant que votre message ne soit remis, signalé ou rejeté. 

Qu'est-ce que le DKIM et comment fonctionne-t-il ?

DKIM (DomainKeys Identified Mail) est un protocole d'authentification des e-mails qui ajoute une signature cryptographique à chaque message envoyé par un domaine. Le serveur émetteur signe le message à l'aide d'une clé privée et ajoute cette signature à l'en-tête de l'e-mail. Le domaine publie la clé publique correspondante dans son DNS sous la forme d'un enregistrement TXT. 

Lorsqu'un serveur destinataire reçoit le message, il récupère cette clé publique et vérifie la signature. Une signature valide confirme deux choses : 

1. Le message provenait bien du domaine indiqué
2. Son contenu n'a pas été modifié pendant le transport. 

Le protocole DKIM a pour but d'empêcher la falsification et l'usurpation d'identité de l'expéditeur ; il fonctionne en complément des SPF DMARC pour vérifier l'authenticité des messages. 

Ce que certifie le DKIM

Le protocole DKIM signe deux parties de chaque message : un ensemble sélectionné de champs d'en-tête et le corps du message. Il ne signe pas l'enveloppe, l'adresse IP de connexion ni aucun autre élément en dehors de ces deux zones. C'est là que réside la différence entre les deux protocoles : SPF l'enveloppe et le serveur d'envoi, tandis que le DKIM signe le message lui-même.

La signature n'est pas appliquée au texte brut. Le serveur émetteur calcule une valeur de hachage du corps du message et des en-têtes sélectionnés, puis chiffre cette valeur de hachage à l'aide de sa clé privée. Le résultat est placé dans l'en-tête DKIM-Signature, que le serveur ajoute au message. À l'intérieur de cet en-tête, plusieurs balises indiquent précisément au destinataire ce qui a été signé :

• h= répertorie les champs d'en-tête inclus dans la signature, tels que De, À, Objet et Date.
• bh= contient le hachage du corps du message.
• b= contient la signature elle-même, c'est-à-dire le hachage chiffré des en-têtes signés.
• c= définit la normalisation, qui détermine le degré de rigueur requis pour la correspondance des espaces et de la mise en forme.

L'en-tête « From » est toujours signé. Le protocole DKIM l'exige, car l'objectif est de lier la signature au domaine que le destinataire voit réellement.

Tout élément ne figurant pas dans la liste h= n'est pas protégé. Si un en-tête ne figure pas dans cette liste, il peut être modifié pendant le transfert sans compromettre la signature. Le corps est entièrement couvert, sauf si la balise facultative l= limite la signature à sa première partie, raison pour laquelle l'utilisation de l= est généralement déconseillée. Tout contenu ajouté après la longueur signée passerait inaperçu et ne serait pas signé.

Lorsqu'un serveur destinataire vérifie le DKIM, il recalcule le hachage du corps et celui de l'en-tête, déchiffre b= à l'aide de votre clé publique publiée, puis compare les deux. Si les deux correspondent, la signature est valide et les parties signées du message sont arrivées intactes.

SPF DKIM

SPF DKIM répondent à deux problèmes distincts. SPF quels serveurs sont autorisés à envoyer des e-mails au nom de votre domaine, tandis que DKIM prouve, à l'aide d'une signature cryptographique, qu'un message n'a pas été altéré et provient bien de votre domaine. Voici un bref aperçu des différences SPF DKIM.

Aucun des deux protocoles ne sait ce que l'autre sait.

SPF vérifier qu'un message provient bien d'un serveur autorisé, mais une fois que ce message a quitté le serveur, SPF plus aucune visibilité sur ce qu'il est advenu de celui-ci. 

De la même manière, le protocole DKIM permet de vérifier que le contenu est parvenu à destination intact et que le domaine signataire contrôlait bien la clé privée, mais il ne permet pas de déterminer si ce serveur était autorisé à envoyer le message en premier lieu.

Voici ce que cela signifie lorsque le serveur destinataire analyse les deux résultats :

DMARC analyse les deux résultats et applique la politique que vous avez publiée en fonction de la conformité avec la domaine . C'est pourquoi ces deux protocoles sont conçus pour se compléter, et non pour se faire concurrence.

Pourquoi SPF -t-il lors du transfert, contrairement au DKIM ?

Le problème de la SPF

SPF lorsqu'un e-mail est transféré. C'est l'une des raisons les plus courantes pour lesquelles un message légitime échoue SPF, et cela tient directement au fonctionnement du protocole.

SPF l'adresse IP du serveur qui se connecte à SPF du domaine de l'expéditeur de l'enveloppe. Le transfert rompt cette correspondance. Lorsqu'un serveur transfère un message, trois choses se produisent :

1. Le serveur de redirection devient la nouvelle adresse IP de connexion.
2. L'expéditeur de l'enveloppe indique toujours le domaine de l'expéditeur d'origine.
3. SPF du domaine d'origine ne mentionne pas le serveur de redirection ; la vérification renvoie donc un échec.

Par exemple, un message provenant de votre domaine passe SPF premier saut. Le serveur du destinataire le transfère ensuite vers une deuxième adresse, comme un compte d'anciens élèves ou une liste de diffusion. À cette deuxième destination, l'adresse IP connectée est désormais celle du serveur de transfert, mais le champ « Return-Path » indique toujours votre domaine. Votre SPF n'ayant jamais autorisé ce serveur, SPF même si le message est authentique.

Cela se manifeste le plus souvent par :

• Listes de diffusion
• Règles de transfert automatique au niveau du compte dans Gmail ou Outlook
• Anciens élèves ou adresses de redirection basées sur un rôle
• Filtres anti-spam et passerelles qui transfèrent les e-mails

Deux éléments empêchent le rejet des e-mails transférés :

1. SRS (Sender Rewriting Scheme) : Le serveur de transfert réécrit le champ Return-Path en indiquant son propre domaine avant de relayer le message. SPF vérifie SPF le domaine du serveur de transfert, qui autorise bien ce serveur, de sorte que la vérification est réussie. La plupart des services de transfert réputés appliquent automatiquement le SRS.
2. DKIM et DMARC : Une signature DKIM reste valide après un transfert tant que le destinataire du transfert ne modifie pas le contenu signé. Ainsi, même lorsque SPF sur un message transféré, le DKIM peut toujours passer, et le DMARC n'a besoin que de l'un des deux pour être conforme. C'est la principale raison pour laquelle vous ne devriez pas vous fier SPF au SPF .

Pourquoi le protocole DKIM résiste au transfert

Le protocole DKIM résiste au transfert car il signe le message lui-même, et non le chemin qu'il emprunte. La signature se trouve dans l'en-tête « DKIM-Signature » ; elle accompagne donc le courriel à chaque étape de son acheminement. Peu importe le nombre de serveurs qui relaient le message, la signature est toujours présente lorsqu'il atteint sa destination finale.

La vérification ne dépend pas non plus du serveur de connexion. Le destinataire récupère la clé publique du domaine signataire à partir du DNS de ce domaine et l'utilise pour vérifier la signature. L'adresse IP à l'origine du message n'a aucune importance. C'est le contraire du SPF, qui échoue lors d'un transfert précisément parce qu'il vérifie l'adresse IP de connexion, et que le transfert modifie cette adresse IP.

Tant que le relais transmet le message sans modifier le contenu signé, le hachage du corps et celui de l'en-tête continuent de correspondre, et le contrôle DKIM est validé.

Le protocole DKIM résiste au simple transfert, mais il n'est pas à l'abri de tout. La signature est compromise lorsqu'un intermédiaire modifie le contenu signé. Les principaux responsables sont les listes de diffusion, qui ont souvent tendance à :

• Ajouter un pied de page ou un lien de désabonnement au corps du message
• Ajoutez une balise telle que [nom-de-la-liste] dans l'objet
• Réécrire ou insérer les en-têtes qui se trouvent à l'intérieur de la signature

Toute modification de ce type modifie la valeur de hachage, et la signature n'est alors plus valide. ARC (Authenticated Received Chain) a été créé précisément pour ce cas de figure, afin de préserver les résultats d'authentification d'origine lorsqu'un message transite par des intermédiaires qui le modifient.

C'est pourquoi DKIM est important pour les e-mails transférés dans le cadre de DMARC. DMARC est validé dès lors que soit SPF DKIM est validé et s'aligne avec le domaine « De ». Sur les messages transférés, SPF échoue SPF ; c'est donc DKIM qui fait la différence l'alignement DMARC . Le domaine de signature reste le même lors du transfert, ce qui permet de conserver l'alignement. Si vous vous fiez SPF à SPF et que des e-mails sont transférés depuis votre domaine, le test DMARC peut échouer et les messages risquent d'atterrir dans le dossier spam.

Comment SPF, DKIM et DMARC fonctionnent-ils ensemble ?

SPF le DKIM résolvent chacun un problème différent, mais aucun des deux n'impose quoi que ce soit à lui seul. Le DMARC relie leurs résultats à une action et associe ces deux vérifications au domaine que vos destinataires voient réellement.

Voici ce qui se passe lorsqu'un serveur récepteur analyse un message entrant :

1. SPF en premier : Le serveur lit l'expéditeur de l'enveloppe, le adresse MAIL FROM échangée pendant la session SMTP, et non l'en-tête « From » que voit le destinataire, et vérifie l'adresse IP de l'expéditeur par rapport à votre SPF . Si l'adresse IP est autorisée, SPF . Sinon, il échoue.
2. DKIM s'exécute ensuite : Le serveur lit le en-tête DKIM-Signature , recherche votre clé publique dans le DNS à l'aide des balises de sélection et de domaine, puis vérifie la signature cryptographique par rapport au contenu du message. Une signature valide confirme que le message provient d'un domaine contrôlant la clé privée et qu'il n'a pas été altéré pendant le transit.
3. DMARC est évalué en dernier : Il récupère les données de votre police et vérifie leur cohérence :
   1. Le domaine qui a passé SPF -il SPF votre domaine d'expédition ? 
   2. Est-ce que le balise d= de la signature DKIM correspond-elle à votre domaine « De » ? 

Si l'un ou l'autre correspond, le test DMARC est réussi. C'est alors votre politique publiée qui détermine le sort du message.

Ce que signifie concrètement l'alignement

SPF tout domaine figurant dans l'expéditeur de l'enveloppe. Le DKIM autorise tout domaine disposant d'une clé de signature valide. Aucun de ces deux contrôles ne suffit à lui seul à valider l'en-tête « From », le champ indiquant [email protected] dans la boîte de réception du destinataire, est légitime. DMARC ajoute cette vérification en comparant le domaine authentifié au domaine « De ».

L'alignement fonctionne selon deux modes :

1. En mode « détendu » (mode par défaut), il suffit qu'il y ait une correspondance avec le domaine de l'entreprise, où mail.votreentreprise.com correspond à votresociété.com. 
2. En mode strict, les domaines doivent correspondre exactement. La plupart des entreprises optent pour un alignement souple, car le mode strict entraîne des problèmes de livraison pour les sous-domaines, à moins que chaque source d'envoi ne soit configurée avec précision.

Les conséquences de l'opposition entre les e-mails légitimes et les e-mails usurpés

Pour un message légitime correctement configuré :

• L'adresse IP de l'expéditeur correspond à votre SPF → SPF
• La signature DKIM est valide, d= correspond à votre domaine « De » → DKIM validé
• Ces deux résultats correspondent à votre domaine d'expédition → DMARC : validé
• Votre p = rejeter → le message est transmis

Dans le cas d'un message falsifié envoyé depuis un serveur non autorisé et ne disposant pas de clé de signature valide :

• Adresse IP non autorisée → SPF
• Signature non valide → Échec de la validation DKIM
• Aucun de ces résultats ne correspond à votre domaine d'expédition → Échec DMARC
• Votre p=rejet → le message est rejeté avant d'atteindre une boîte de réception

C'est pourquoi, dans le cadre de DMARC, l'association SPF DKIM s'avère plus efficace que l'utilisation de l'un ou de l'autre seul. DMARC peut valider les messages en fonction du résultat le plus favorable : ainsi, lorsque SPF sur un message transféré, la conformité DKIM permet à DMARC de valider les messages légitimes. Lorsque les deux échouent sur un message falsifié, DMARC applique votre politique.

Une fois que votre domaine atteint quarantine ou p=reject avec SPF DKIM validés et alignés, vous remplissez également les conditions préalables à l'application de BIMI, la norme qui affiche le logo vérifié de votre marque dans les boîtes de réception compatibles telles que Gmail et Apple Mail.

Avez-vous besoin à la fois de SPF de DKIM ?

Oui, vous avez besoin à la fois de SPF de DKIM. 

Un domaine utilisant SPF DKIM ne dispose d'aucune vérification de l'intégrité au niveau du message. Il n'y a aucun moyen de confirmer que le contenu n'a pas été altéré pendant le transit. L'absence d'alignement DKIM empêche l'utilisation de DMARC, ce qui signifie que si SPF (ce qui sera le cas pour tout e-mail transféré), DMARC n'a aucun mécanisme de secours. Il suffit d'une seule règle de transfert entre la boîte de réception professionnelle d'un utilisateur et son compte personnel pour que l'authentification échoue sur un e-mail pourtant tout à fait légitime.

Google et Yahoo ont rendu ces deux mesures obligatoires en février 2024.

Google exige la mise en place d'enregistrements SPF, DKIM et DMARC pour tous les expéditeurs en masse envoyant 5 000 messages ou plus par jour. Yahoo exige au moins l'un des SPF DKIM, ainsi que DMARC ; toutefois, le fait de n'en déployer qu'un seul entraîne le non-respect simultané des exigences de Google. Si vous envoyez des messages à des destinataires sur ces deux plateformes, la configuration des deux protocoles est le seul moyen de satisfaire à toutes les exigences à la fois.

Même en dessous du seuil des 5 000 messages, ces exigences sont désormais la norme en matière de délivrabilité chez les principaux fournisseurs de messagerie. 

Ce que l'un couvre et que l'autre ne couvre pas :

Conformément à la norme RFC 7208, SPF pour les e-mails transférés. L'adresse IP du serveur de transfert remplace celle d'origine ; comme cette adresse IP ne figure pas sur votre liste d'adresses autorisées, la vérification échoue, même si tout s'est déroulé normalement. Le DKIM, quant à lui, ne tient pas compte des changements d'adresse IP. La signature accompagne le message et est validée quel que soit le serveur par lequel il est passé, à condition que le contenu n'ait pas été modifié.

Le protocole DKIM vérifie que le message est intact et que le domaine signataire contrôle bien la clé privée, mais il ne permet pas de déterminer si le serveur qui l'a envoyé disposait des autorisations nécessaires au niveau du réseau pour le faire. C'est SPF cette vérification.

Aucun des deux ne sait ce que l'autre sait. En exécutant les deux, le serveur de réception qui traite votre courrier dispose d'une vue d'ensemble complète, du chemin d'accès autorisé et d'un contenu intact, plutôt que d'une information partielle.

Comment configurer SPF DKIM : guide étape par étape

Si SPF DKIM ne sont pas encore configurés sur votre domaine, la procédure est très simple. Les étapes ci-dessous vous expliquent comment configurer et valider ces deux protocoles. 

Étape 1 : Créez votre SPF

Commencez par dresser la liste de tous les services autorisés à envoyer des e-mails depuis votre domaine, tels que :

1. Votre serveur de messagerie principal
2. Plateforme marketing
3. CRM
4. Outil d'assistance
5. Fournisseur de services de messagerie transactionnelle, ainsi que tout autre service qui envoie des e-mails en votre nom.

Chaque service agréé reçoit un include : un mécanisme dans votre SPF , ou une plage d'adresses IP directe utilisant ip4: ou ip6:. Terminez l'enregistrement par -all pour indiquer aux serveurs destinataires que toute adresse IP ne figurant pas dans la liste n'est pas autorisée.

Avant d'ajouter des plages d'adresses IP directement avec ip4: ou ip6:, vérifiez que ces plages appartiennent bien au service d'envoi concerné. La recherche d'IP WHOIS de PowerDMARC de PowerDMARC vous permet de vérifier la propriété de l'adresse IP avant qu'elle ne soit enregistrée dans votre dossier. 

SPF de base se présente comme suit :

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all

Surveillez le nombre de requêtes DNS à mesure que vous ajoutez des services. La RFC 7208 limite SPF à 10 requêtes. Chacune mécanisme d'inclusion consomme au moins une recherche, et les inclusions imbriquées sont comptabilisées dans cette même limite. La plupart des domaines atteignent cette limite plus rapidement que prévu dès qu’ils exploitent simultanément quatre ou cinq expéditeurs tiers.

Utilisez le générateur gratuit de PowerDMARC SPF pour créer votre enregistrement sans avoir à écrire la syntaxe manuellement, et PowerSPF pour le maintenir automatiquement sous la limite de 10 requêtes à mesure que votre infrastructure d'envoi évolue.

Étape 2 : Générer et publier vos clés DKIM

Pour chaque service qui envoie des e-mails en votre nom, vous avez besoin d'une paire de clés DKIM : 

1. Une clé privée que le serveur expéditeur utilise pour signer les e-mails sortants
2. Une clé publique correspondante publiée dans votre DNS afin que les serveurs destinataires puissent la vérifier.

Si un service tel que Google Workspace ou Microsoft 365 gère la signature DKIM, il fournit l'enregistrement de clé publique et le nom du sélecteur. Publiez l'enregistrement dans le DNS à l'adresse selector._domainkey.votredomaine.com et activez la signature dans la console d'administration du service.

Dans les environnements où vous générez vous-même vos clés, utilisez au moins un algorithme RSA de 2048 bits ; un algorithme de 1024 bits n'est plus considéré comme suffisant. Le générateur gratuit de PowerDMARC générateur DKIM génère un enregistrement DNS prêt à être publié sans nécessiter d'outils en ligne de commande.

Si vous gérez DKIM sur plusieurs services d'envoi, Hosted DKIM gère la génération des clés, la publication DNS et la rotation depuis un seul endroit, sans modification manuelle du DNS à chaque fois qu’une clé doit être changée.

Étape 3 : Ajouter un enregistrement DMARC

Une fois que SPF DKIM sont configurés, ajoutez un enregistrement DMARC à votre DNS. Commencez par p=none pour collecter des données de rapport agrégées sans affecter la distribution du courrier.

Un enregistrement de base minimal :

v=DMARC1 ; p=none ; rua=mailto:[email protected] ;

p=none ne bloque pas les messages usurpés. Cela place DMARC en mode surveillance, de sorte que vous recevez des rapports agrégés indiquant quelles sources réussissent ou échouent à l'authentification, mais aucun courrier n'est mis en quarantaine ni rejeté. 

Utilisez ces données pour identifier les erreurs de configuration et les problèmes d'alignement, puis passez à mettrequarantine et, le cas échéant, p=rejet.

Un domaine situé à l'adresse p=none indéfiniment n'est pas protégé contre l'usurpation d'identité. La phase de surveillance nécessite un point final défini, et non une durée indéterminée.

Étape 4 : Vérifiez votre configuration

Une fois vos enregistrements publiés, vérifiez que chacun d'entre eux fonctionne correctement avant de considérer la configuration comme terminée.

Bien qu'il soit indispensable que les enregistrements soient correctement résolus, cela ne suffit pas à lui seul. Effectuez un test en conditions réelles pour vérifier que les en-têtes d'authentification sont bien transmis de bout en bout. L'outil de test SMTP de PowerDMARC vous permet de tester la connexion de votre serveur de messagerie et de vérifier que les en-têtesSPF, DKIM et DMARC passent bien sur les e-mails sortants réels, et pas seulement dans le DNS. 

Erreurs courantes

Les deux erreurs les plus courantes à l'origine d'échecs d'authentification en production sont les suivantes : 

SPF - Limite SPF

SPF un maximum de 10 requêtes DNS lorsqu'un serveur destinataire évalue votre enregistrement, une limite fixée par la RFC 7208. Les mécanismes tels que « include », « a » et « mx » déclenchent chacun une recherche, et ils s'imbriquent. 

La plupart des domaines dépassent largement la limite de 10 en cumulant les expéditeurs tiers, car chaque service que vous autorisez via une inclusion consomme des requêtes de vérification. Une fois cette limite dépassée, SPF une PermError, et les serveurs destinataires le traitent comme un enregistrement corrompu qui n'autorise plus votre courrier. 

Aplatissement résout le problème en remplaçant vos mécanismes d'inclusion par les plages IPv4 et IPv6 réelles auxquelles ils renvoient, ce qui ramène votre nombre de recherches à zéro.

Rotation des clés DKIM

La rotation des clés DKIM consiste à remplacer régulièrement votre paire de clés DKIM, en retirant l'ancienne clé privée de signature et en publiant une nouvelle clé publique à sa place. La rotation limite la durée d'exposition d'une clé donnée ; ainsi, si une clé venait à être compromise, l'ampleur des dégâts resterait limitée. La plupart des équipes procèdent à une rotation tous les trimestres ou deux fois par an, et certains fournisseurs effectuent automatiquement la rotation de leurs propres clés.

La plupart des problèmes liés à la rotation proviennent des étapes entourant le remplacement. Voici ce que les administrateurs négligent le plus souvent.

Supprimer l'ancienne clé publique trop tôt

Les messages déjà en cours d'acheminement ont été signés avec l'ancienne clé, et le destinataire a besoin de la clé publique correspondante dans le DNS pour les vérifier. Supprimez l'ancien enregistrement dès que vous effectuez la transition, car les e-mails en cours d'acheminement échoueront au contrôle DKIM. Maintenez l'ancienne clé publiée pendant une période de transition jusqu'à ce que tous les e-mails signés avec celle-ci aient été traités.

Réutiliser le même sélecteur

Utilisez la rotation des sélecteurs, ne les remplacez pas. Publiez la nouvelle clé sous un nouveau sélecteur, transférez-y la signature, puis retirez l’ancien sélecteur une fois la période de chevauchement terminée. Le remplacement de l’enregistrement d’un seul sélecteur crée une lacune pendant laquelle les e-mails signés avec l’ancienne clé ne peuvent plus être validés.

Changement avant la propagation du DNS

Si vous effectuez une signature inversée avec la nouvelle clé avant que nouvelle clé publique se soit propagée, les destinataires ne pourront pas la trouver et DKIM échouera. Publiez d'abord le nouvel enregistrement, attendez que le TTL de l'enregistrement expire, puis effectuez la transition vers la nouvelle signature.

Oublier les expéditeurs tiers

Chaque service d'envoi, tel que votre ESP ou votre CRM, gère ses propres clés et sélecteurs DKIM. La rotation de la clé de votre domaine principal n'a aucune incidence sur ceux-ci. Veuillez effectuer la rotation de la clé de chaque service séparément, ou assurez-vous que le fournisseur s'en charge pour vous.

Fractionnement incorrect d'un enregistrement de 2048 bits

Une clé publique de 2048 bits, qui constitue la norme actuelle et vers laquelle il est recommandé de migrer si vous utilisez encore une clé de 1024 bits, dépasse souvent la limite de 255 caractères imposée pour une seule chaîne DNS TXT et doit donc être divisée en plusieurs chaînes entre guillemets. Un mauvais découpage endommage l'enregistrement, et la clé ne sera pas validée même si elle semble bien présente.

Fonctionnement sans surveillance

Les rapports agrégés DMARC vous permettent de vérifier que la nouvelle clé est valide. Sans eux, une rotation défaillante se traduirait par une baisse du taux de délivrabilité plutôt que par une alerte. Vérifiez vos rapports après chaque rotation.

Ces deux échecs sont dus à des enregistrements qui évoluent trop rapidement pour que vous puissiez les mettre à jour manuellement. PowerDMARC maintient votre SPF en dessous de la limite de 10 requêtes et assure une rotation fluide de vos clés DKIM, puis vous alerte dès qu'un problème survient, avant que cela ne nuise à votre délivrabilité.

Commencez votre essai gratuit pour voir où en est votre domaine aujourd'hui.

FAQ

Le protocole DKIM remplace-t-il SPF?

Non. Le protocole DKIM vérifie l'intégrité du message à l'aide d'une signature cryptographique, mais il ne garantit pas que le serveur d'envoi était autorisé. C'est SPF cette vérification ; les deux sont donc nécessaires pour une protection complète. 

Pourquoi mon e-mail échoue-t-il SPF avoir été transféré ?

SPF l'adresse IP du serveur émetteur figure dans votre liste d'adresses autorisées, tandis que le transfert remplace l'adresse IP d'origine par celle du serveur de transfert, qui ne figure pas dans votre liste. Il s'agit d'un comportement normal conformément à la norme RFC 7208, et le protocole DKIM est conçu pour fonctionner malgré cela, car il valide le contenu et non le chemin d'accès. 

Qu'est-ce qui est le plus important : SPF DKIM ?

Ni l'un ni l'autre. SPF au niveau du serveur, tandis que le DKIM effectue la vérification au niveau du message ; les deux sont indispensables pour garantir un alignement DMARC fiable. Le fait de disposer des deux permet à votre courrier de passer même si l'un des deux échoue lors du transfert. 

Combien de sélecteurs DKIM puis-je avoir ?

Il n'y a pas de limite. Publiez-en autant que nécessaire, généralement un par service d'envoi ou par cycle de rotation des clés. Chacun d'entre eux existe sous la forme d'un enregistrement DNS TXT distinct à l'adresse selector._domainkey.votredomaine.com. 

Que se passe-t-il si je dispose uniquement SPF pas du protocole DKIM ?

Vous perdez l'intégrité au niveau du message et ne disposez d'aucune solution de secours pour l'alignement DKIM ; par conséquent, DMARC peut échouer sur des e-mails transférés légitimes lorsque SPF . Les règles de Google relatives aux expéditeurs de masse imposent également l'utilisation de DKIM, ce qui met les expéditeurs à fort volume en situation de non-conformité.