Points clés à retenir
- Le protocole DKIM (DomainKeys Identified Mail) ajoute une signature cryptographique à chaque e-mail sortant afin que les serveurs destinataires puissent vérifier que le message provient bien de votre domaine et qu'il n'a pas été altéré pendant son acheminement.
- Le protocole DKIM fonctionne grâce à une paire de clés : une clé privée qui signe les e-mails sur votre serveur, et une clé publique publiée dans votre DNS sous la forme d'un enregistrement DKIM.
- Un enregistrement DKIM enregistre est la clé publique statique dans le DNS ; une signature est l'en-tête propre à chaque message ajouté à chaque e-mail ; ce sont deux choses différentes.
- Contrairement SPF, les signatures DKIM ne sont pas altérées lors du transfert des e-mails, ce qui fait de DKIM la solution la plus résiliente des deux pour l'alignement DMARC.
- Depuis 2024-2025, Google, Yahoo et Microsoft exigent l'utilisation du protocole DKIM pour les domaines envoyant plus de 5 000 e-mails par jour.
- À lui seul, le protocole DKIM n'empêche pas l'usurpation de l'adresse d'expéditeur et n'impose pas de politique ; c'est là qu'intervient le protocole DMARC.
Le protocole DKIM (DomainKeys Identified Mail) est un protocole d'authentification des e-mails qui permet aux serveurs destinataires de vérifier qu'un message a bien été envoyé par le domaine dont il prétend provenir, et que son contenu n'a pas été modifié pendant le transfert. Il fonctionne en ajoutant une signature cryptographique à chaque e-mail sortant, que le serveur destinataire vérifie à l'aide d'une clé publique publiée dans le DNS de votre domaine.
Ce guide explique à quoi ressemble un enregistrement DKIM, décrit étape par étape le fonctionnement du processus de signature et de vérification, explique comment lire un en-tête « DKIM-Signature » réel et indique comment résoudre les problèmes les plus courants.
Qu'est-ce qu'un enregistrement DKIM ?
Un enregistrement DKIM est un ensemble d’instructions publiées sous la forme d’un enregistrement TXT dans le DNS de votre domaine. Il contient la clé publique correspondant à la clé privée que votre serveur de messagerie utilise pour signer les e-mails sortants. Lorsqu’un serveur destinataire souhaite vérifier une signature, il consulte cet enregistrement, récupère la clé publique et l’utilise pour confirmer que le message n’a pas été altéré et qu’il provient bien de votre domaine.
Le protocole DKIM a été créé en 2004 à la suite de la fusion entre DomainKeys de Yahoo et Identified Internet Mail de Cisco ; il est depuis devenu l'une des normes d'authentification des e-mails les plus largement adoptées.
Format des enregistrements DKIM et convention de nommage
Un enregistrement DKIM n'est pas publié sur votre domaine racine. Il se trouve sur un sous-domaine spécifique composé d'un sélecteur et du libellé fixe _domainkey. La convention de nommage est la suivante :
[selector]._domainkey.[domain]
Ainsi, un enregistrement associé au sélecteur « google » pour « yourdomain.com » serait publié à l'adresse suivante :
google._domainkey.yourdomain.com
La valeur de cet enregistrement TXT se présente comme suit :
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...
Chaque balise a un rôle spécifique :
| # | Étiquette | Signification |
|---|---|---|
| 1. | v | Version : toujours DKIM1 |
| 2. | k | Type de clé : presque toujours RSA |
| 3. | p | La clé publique elle-même (une longue chaîne de caractères au format Base64) |
Vous pouvez générer un enregistrement valide à l'aide de notre générateur DKIM et vérifier qu’il a bien été publié grâce à notre outil de vérification DKIM .
Qu'est-ce qu'un sélecteur DKIM ?
Un sélecteur DKIM est un identifiant unique qui indique au serveur destinataire quelle paire de clés a été utilisée pour signer un message donné. Il s'agit de la chaîne alphanumérique définie dans la balise « s= » de l'en-tête « DKIM-Signature », et elle permet à un domaine de gérer plusieurs clés à la fois (par exemple, un sélecteur pour votre plateforme de messagerie et un autre pour un service marketing). Chaque fournisseur par l'intermédiaire duquel vous envoyez des e-mails doit utiliser son propre sélecteur distinct.
Par exemple, Google Workspace utilise « google » comme sélecteur par défaut ; ainsi, la recherche DNS complète pour un message signé par Google serait google._domainkey.votredomaine.com. Si le nom de votre enregistrement était s1._domainkey.votredomaine.com, alors s1 serait votre sélecteur.
Pour en savoir plus sur les sélecteurs et comment les trouver, consultez notre guide détaillé guide détaillé sur les sélecteurs DKIM .
Enregistrement DKIM et signature DKIM : quelle est la différence ?
Ces deux termes sont souvent confondus, il est donc utile de les distinguer clairement. L’enregistrement DKIM est l’entrée TXT statique de votre DNS qui contient la clé publique ; vous la publiez une seule fois, et elle reste inchangée. La signature DKIM est l’en-tête « DKIM-Signature » ajouté à chaque e-mail au moment de son envoi, généré à l’aide de votre clé privée. L’un est une entrée DNS fixe ; l’autre est créé à chaque nouveau message. C’est l’enregistrement qui permet de vérifier la signature. Nous analyserons l'en-tête de signature champ par champ plus loin dans cet article.
Pour en savoir plus sur ce dernier point, consultez notre guide complet sur signatures DKIM.
Comment fonctionne DKIM ?
L'authentification DKIM se déroule en quatre étapes, depuis la génération des clés jusqu'à la décision finale de validation ou de rejet du côté du destinataire.
Étape 1 : Génération d'une paire de clés
Votre fournisseur de messagerie ou vous-même générez une paire de clés cryptographiques : une clé privée qui reste secrète sur le serveur de messagerie émetteur, et une clé publique qui est publiée dans le DNS sous la forme de l'enregistrement DKIM décrit ci-dessus. Les deux sont mathématiquement liées ; ainsi, tout élément signé avec la clé privée ne peut être vérifié qu'à l'aide de la clé publique correspondante.
Étape 2 : Signer l'e-mail sortant
Lorsque vous envoyez un message, le serveur d'envoi (l'agent de transfert de courrier) utilise la clé privée pour calculer un hachage de certaines parties spécifiques de l'e-mail (les en-têtes répertoriés dans la balise « h= » de la signature, ainsi que le corps du message) et joint le résultat sous la forme d'un en-tête « DKIM-Signature » au message sortant.
Étape 3 : Recherche DNS effectuée par le serveur destinataire
Le serveur destinataire lit l'en-tête « DKIM-Signature », en extrait le sélecteur (s=) et le domaine de signature (d=), puis interroge le DNS pour obtenir la clé publique à l'adresse [sélecteur]._domainkey.[domaine], conformément à la convention de nommage décrite dans la section « Enregistrement DKIM » ci-dessus. C'est à ce stade que la signature propre à chaque message et l'enregistrement DNS statique se rejoignent.
Étape 4 : Vérification
À l'aide de la clé publique récupérée, le serveur destinataire vérifie la signature et recalcule de manière indépendante la valeur de hachage à partir du message qu'il a effectivement reçu. Il compare ensuite les deux résultats. S'ils correspondent, la validation DKIM est réussie : le message est intact et autorisé par le domaine signataire. Dans le cas contraire, la validation DKIM échoue, et le message peut être signalé, mis en quarantaine ou rejeté, selon la politique DMARC du domaine.
Vous pouvez vérifier à tout moment la configuration de votre compte grâce à notre outil gratuit de vérification DKIM, accessible via le lien ci-dessus.
Contenu d'un en-tête « DKIM-Signature »
Voici à quoi ressemble un en-tête « DKIM-Signature » dans un e-mail reçu :
DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=google;
c=relaxed/relaxed; h=from:to:subject:date:message-id;
bh=abc123...; b=xyz789...
Chaque champ contient une partie des informations dont le destinataire a besoin pour vérifier le message :
| # | Champ | Signification |
|---|---|---|
| 1. | v | Version de la norme DKIM (toujours 1) |
| 2. | a | Algorithme de signature, généralement RSA-SHA-256 |
| 3. | d | Domaine de signature : doit correspondre à votre domaine « De » pour l'alignement DMARC |
| 4. | s | Sélecteur, utilisé pour générer la requête DNS relative à la clé publique |
| 5. | c | Mode de canonisation |
| 6. | h | Quels en-têtes figuraient dans la signature ? |
| 7. | bh | La valeur de hachage du corps du message |
| 8. | b | La signature elle-même |
Les deux champs qui jouent un rôle déterminant sont « bh » (le hachage du corps du message) et « b » (la signature cryptographique). Le champ « d= » est celui qui revêt la plus grande importance pour DMARC : s’il ne correspond pas au domaine « From » visible, DKIM peut être validé, mais DMARC peut tout de même échouer.
Que signifie le terme « canonicalisation » ? (assouplie vs stricte)
La balise « c= » définit dans quelle mesure la signature tolère les modifications mineures de mise en forme survenues lors du transfert.
Mode « Relaxed » (le choix habituel et recommandé) tolère les petits espaces et les différences de casse dans les en-têtes, qui sont presque inévitables lorsque les e-mails transitent par les serveurs.
Le mode strict (également appelé « simple ») exige une correspondance octet par octet et échoue au moindre changement. Ceci est important car les listes de diffusion et les serveurs de transfert effectuent fréquemment de minuscules modifications (un pied de page ajouté, une ligne réécrite) qui feraient échouer la canonicalisation stricte mais passeraient la canonicalisation assouplie. La valeur se présente sous la forme c=relaxed/relaxed, où la première partie s'applique aux en-têtes et la seconde au corps du message.
Pourquoi le protocole DKIM est-il important ?
Vérifie l'intégrité des e-mails (empêche toute altération)
La signature est un sceau anti-falsification. Si un message est intercepté et modifié pendant son acheminement, la valeur de hachage recalculée par le destinataire ne correspondra pas à la valeur de hachage signée ; la vérification échouera et l'e-mail sera rejeté ou signalé. C'est là la fonction principale du protocole DKIM : garantir que le contenu reçu est bien celui qui a été envoyé.
Protège la réputation de l'expéditeur et la délivrabilité
Les e-mails correctement signés inspirent confiance aux fournisseurs de messagerie. Un domaine d'envoi vérifié et systématiquement authentifié renforce votre réputation auprès des FAI, ce qui signifie que vos messages légitimes ont plus de chances d'arriver dans la boîte de réception plutôt que dans le dossier « spam », ce qui constitue un avantage direct tant pour les e-mails marketing que pour les e-mails transactionnels.
Résiste au transfert d'e-mails (contrairement SPF)
C'est là la distinction pratique la plus importante entre les deux protocoles, et elle passe facilement inaperçue. En effet, une signature DKIM est transmise avec le message, elle reste valide même après le transfert du message. SPF, en revanche, compare l’adresse IP du serveur expéditeur à SPF du domaine d’origine ; ainsi, lorsqu’un message est transféré, l’adresse IP du serveur de transfert ne figure pas sur cette liste et SPF . C’est pourquoi le protocole DKIM est le plus fiable des deux pour maintenir l’alignement DMARC sur les flux de messagerie transférés et indirects.
Obligatoire pour les expéditeurs en masse selon Google, Yahoo et Microsoft
Le protocole DKIM n'est plus facultatif pour les expéditeurs à fort volume. Conformément aux les exigences de Google et Yahoo entrées en vigueur en février 2024, ainsi que les règles équivalentes de Microsoft qui seront mises en place à partir de mai 2025, tout domaine envoyant environ 5 000 messages ou plus par jour à ces fournisseurs doit s’authentifier via DKIM (en plus de SPF DMARC), sous peine de voir ses e-mails rejetés ou filtrés comme spam. Même en dessous de ce seuil, DKIM est désormais la norme minimale pour garantir une bonne délivrabilité.
DKIM, SPF DMARC : comment ils fonctionnent ensemble
DKIM est l'une des trois normes d'authentification des e-mails conçues pour être utilisées conjointement, et non isolément. Voici comment elles se répartissent les tâches :
| # | Protocole | Ce que cela vérifie | Ce qui n'est pas couvert | Faiblesse intrinsèque |
|---|---|---|---|---|
| 1. | SPF | Que l'adresse IP du serveur émetteur soit autorisée pour le domaine | Le contenu du message, et si l'adresse « De » visible correspond au domaine du chemin de retour. | Interruptions dans la transmission ; intégrité du contenu non garantie |
| 2. | DKIM | Que le contenu du message soit intact et signé par le domaine | Si le domaine de signature correspond au champ « De » affiché | Aucune politique ; cela ne suffit pas à empêcher à lui seul l'usurpation de l'adresse d'expéditeur |
| 3. | DMARC | Que les validations SPF DKIM soient réussies et correspondent au domaine « De » | Cela dépend de la correspondance entre les domaines SPF | Nécessite la mise en place de SPF DKIM |
En termes simples : SPF vérifie le serveur d'envoi, DKIM vérifie l'intégrité du message, et DMARC relie ces deux éléments au domaine que vos destinataires voient réellement dans le champ « De », puis ajoute une politique indiquant aux destinataires comment réagir en cas d’échec d’une vérification. DKIM et SPF l’authentification ; DMARC assure l’alignement et l’application des règles. Vous avez besoin des trois.
Problèmes courants liés au DKIM et comment les résoudre
Aucune des pages les mieux classées sur le thème « Qu'est-ce que le DKIM ? » n'explique en détail ce qui ne fonctionne pas concrètement. Voici les quatre problèmes les plus courants que vous rencontrerez, ainsi que la manière de les résoudre.
Signature DKIM introuvable
Ce que cela signifie: cette erreur indique que le serveur destinataire n'a trouvé aucune signature DKIM. En général, cela signifie que le protocole DKIM n'est pas configuré pour le service d'envoi que vous avez utilisé, ou que l'enregistrement DNS n'a jamais été publié.
Comment résoudre ce problème: activez la signature DKIM sur tous les services qui envoient des e-mails au nom de votre domaine, puis vérifiez que l'enregistrement existe bien dans le DNS.
Échec de la vérification de la signature DKIM
Ce que cela signifie: une signature était présente mais n'a pas pu être vérifiée, ce qui signifie que le corps du message ou les en-têtes signés ont été modifiés après la signature. La cause la plus courante est l'ajout d'un pied de page, la réécriture de l'objet ou la suppression d'en-têtes par une liste de diffusion ou un serveur de transfert.
Comment y remédier: Une canonicalisation assouplie permet de réduire ce phénomène, et le protocole ARC (Authenticated Received Chain) a été spécialement conçu pour préserver les résultats d'authentification lors des sauts de transfert. Cependant, l'ARC sera bientôt obsolète, et le protocole DKIM2, une fois déployé, réduira considérablement les problèmes liés au transfert.
Clé publique introuvable dans le DNS
Ce que cela signifie: Le destinataire a recherché la clé publique, mais n'a rien trouvé. Cela est généralement dû à une incompatibilité entre le sélecteur ou le domaine de l'en-tête DKIM-Signature et le nom réel de l'enregistrement DNS, à un délai de propagation DNS suite à une modification récente, ou à une simple faute de frappe dans le nom de l'enregistrement, le plus souvent un trait de soulignement manquant dans _domainkey.
Comment y remédier: Passez votre domaine dans un outil de vérification DKIM pour passer en revue toutes les erreurs et les corriger une par une.
Clé trop courte / Clé trop faible
Ce que cela signifie: De nombreuses plateformes de messagerie et panneaux d’hébergement plus anciens génèrent encore par défaut des clés de 1 024 bits. La norme RFC 8301 considère la longueur de 1 024 bits comme le strict minimum, mais recommande au moins 2 048 bits pour la signature, et le NIST classe le RSA à 1 024 bits comme réservé à un usage obsolète. Les principaux destinataires, comme Google, acceptent toujours 1 024 bits comme minimum, mais recommandent 2 048 bits ; ainsi, une clé de 1 024 bits ne constitue pas aujourd’hui un échec total ; elle est simplement en deçà de la norme actuelle, et sa marge de sécurité ne cesse de diminuer.
Comment y remédier: utilisez une clé RSA de 2 048 bits avec rsa-sha256 comme valeur par défaut. Deux points à surveiller lors de la mise à jour : une clé publique de 2 048 bits est trop longue pour tenir dans une seule chaîne DNS TXT de 255 octets ; elle doit donc être divisée en plusieurs chaînes entre guillemets dans le même enregistrement, et vous devez renouveler vos clés tous les 6 à 12 mois.
Meilleures pratiques DKIM
- Utilisez des clés de 2048 bits, et non de 1024 bits : Les clés plus longues offrent une meilleure sécurité et sont de plus en plus souvent exigées par les principaux fournisseurs.
- Renouveler les clés au moins une fois par an: Publiez la nouvelle clé dans le DNS avant de désactiver l'ancienne afin d'éviter toute interruption de la vérification pendant la transition.
- Signer toutes les sources d'e-mails sortants : Chaque service tiers (CRM, plateforme d'e-mail marketing, service d'assistance) doit disposer de sa propre signature DKIM, configurée sous son propre sélecteur.
- Suivre les taux de réussite et d'échec: Consultez vos rapports agrégés DMARC afin de détecter tout sélecteur défectueux ou expéditeur non signé avant que cela ne nuise à la délivrabilité.
Limites du protocole DKIM
Le protocole DKIM est indispensable, mais il n'est pas suffisant à lui seul. Voici quelques limites réelles :
À lui seul, le protocole DKIM ne permet pas d'empêcher l'usurpation de l'adresse d'expéditeur.
Le protocole DKIM authentifie le domaine indiqué dans la balise « d= » de la signature et confirme que le message n’a pas été altéré, mais il ne vérifie pas si la valeur de « d= » correspond à l’adresse « De » que voit le destinataire. C’est au protocole DMARC qu’il revient d’effectuer cette vérification de cohérence. Et si un pirate parvient à accéder à un compte ou à un serveur légitime, il peut envoyer un e-mail muni d’une signature valide.
Le fonctionnement de DKIM dépend de la publication correcte des enregistrements DNS
Un enregistrement mal configuré, un retard de propagation ou un sélecteur erroné entraîneront l'échec de la validation DKIM, même pour des e-mails légitimes.
Le protocole DKIM n'impose aucune politique en soi
Le protocole DKIM ne fournit qu'un résultat « réussi » ou « échoué » et n'indique pas aux destinataires comment réagir en cas d'échec. C'est en l'associant au protocole DMARC, qui utilise les résultats de DKIM (et/ou SPF) pour appliquer une politique quarantine de rejet, que l'authentification se transforme en véritable protection.
La gestion des clés accroît la complexité opérationnelle
La gestion des clés sur plusieurs services d'envoi, leur rotation en toute sécurité et la coordination avec chaque expéditeur tiers nécessitent une attention constante et un suivi régulier. Effectuer ces tâches manuellement pour plusieurs domaines est non seulement chronophage, mais aussi très gourmand en ressources.
Activer DKIM avec PowerDMARC
PowerDMARC permet aux propriétaires de domaines de configurer DKIM en complément de SPF et DMARC, grâce à des fonctionnalités de surveillance et de génération de rapports en temps réel qui vous permettent de suivre les résultats d'authentification et de détecter les erreurs dès qu'elles surviennent, sans intervention manuelle.
La plateforme prend en charge plusieurs domaines et des volumes élevés d'e-mails, et intègre le DKIM hébergé aux autres protocoles d’authentification pour une protection complète contre la fraude par e-mail. Vous pouvez configurer DKIM et DMARC en quelques minutes, sans avoir à vous débattre manuellement avec le DNS.
Avec le service DKIM hébergé de PowerDMARC, vous bénéficiez des avantages suivants :
- Configuration CNAME unique, aucune modification DNS par la suite : Connectez votre domaine une seule fois, puis gérez tous les changements de sélecteur et de clé depuis un unique tableau de bord cloud, sans avoir à intervenir sur le DNS à chaque mise à jour.
- Rotation des clés sans accès au DNS : Planifiez et appliquez instantanément la rotation des clés depuis le tableau de bord, sans délai de propagation ni modification manuelle des enregistrements, ce qui évite tout temps d'arrêt et toute erreur de syntaxe.
- Flexibilité totale en matière de longueur de clé : choisissez des clés de 1 024, 2 048 ou 4 096 bits et renforcez la sécurité de vos clés sans interrompre l'authentification.
- Un tableau de bord dédié à l'analyse DKIM : Suivez en temps réel le volume d'e-mails, les taux de réussite DKIM et les performances par sélecteur pour bénéficier d'une visibilité immédiate et faciliter le dépannage.
- Contrôle multi-domaines et compatible MSP : Gérez DKIM sur des centaines de domaines et sous-domaines à partir d'un seul et même endroit, grâce à une vue multi-locataires conçue pour les entreprises et les fournisseurs de services.
- Une pile d'authentification complète sur une seule plateforme : DKIM côtoie DMARC, SPF, MTA-STS et BIMI, et s'intègre à des fournisseurs tels que Google Workspace et Microsoft 365.
Foire aux questions
1. Que signifie l'acronyme DKIM ?
DKIM signifie « DomainKeys Identified Mail ». Il s'agit d'un protocole d'authentification des e-mails qui utilise une signature cryptographique pour vérifier qu'un message provient bien du domaine indiqué et qu'il n'a pas été altéré pendant son acheminement.
2. Qu'est-ce que le DKIM, en termes simples ?
Vous pouvez considérer le DKIM comme un sceau inviolable apposé sur votre e-mail. Votre serveur signe chaque message à l'aide d'une clé privée, et le serveur destinataire vérifie ce sceau à l'aide d'une clé publique enregistrée dans votre DNS. Si le sceau est intact, cela signifie que l'e-mail est authentique et n'a pas été modifié.
3. Comment configurer DKIM pour mon domaine ?
Pour configurer DKIM, vous devez générer une paire de clés (via votre fournisseur de messagerie ou notre générateur DKIM), configurer votre serveur d'envoi pour qu'il signe les e-mails sortants à l'aide de la clé privée, puis publier la clé publique sous forme d'enregistrement TXT à l'adresse selector._domainkey.votredomaine.com. Vous pouvez consulter notre guide de configuration de DKIM pour obtenir des instructions étape par étape.
4. Le protocole DKIM est-il suffisant à lui seul ?
Non. Le protocole DKIM vérifie l'intégrité du message, mais ne contrôle pas l'adresse « De » visible et n'impose aucune politique. Pour bénéficier d'une protection complète contre l'usurpation d'identité, vous devez l'associer aux protocoles SPF DMARC.
5. Quelle est la différence entre DKIM et SPF?
SPF les serveurs autorisés à envoyer des e-mails au nom de votre domaine (vérification du chemin d'acheminement), tandis que le DKIM vérifie que le contenu du message n'a pas été modifié et qu'il a bien été signé par le domaine (vérification de l'intégrité et de l'origine). Les signatures DKIM sont souvent conservées lors du transfert d'e-mails, tandis que SPF est SPF invalidé lorsque l'e-mail est transféré.
6. Comment puis-je vérifier si DKIM est correctement configuré ?
Pour vérifier si votre enregistrement DKIM est correctement configuré, utilisez l'outil de vérification DKIM gratuit de PowerDMARC. Il vous suffit de saisir votre domaine et votre sélecteur : l'outil interroge alors le DNS pour confirmer que votre enregistrement est publié, correctement formé et accessible.
7. Que se passe-t-il en cas d'échec de la validation DKIM ?
Un échec DKIM signifie que le message a été altéré ou qu'il n'a pas été correctement signé. Les destinataires peuvent le signaler comme spam, et si une politique DMARC est en place et que SPF également, le message peut être mis en quarantaine ou rejeté purement et simplement.
8. À quelle fréquence faut-il renouveler les clés DKIM ?
Les clés DKIM doivent être renouvelées au moins une fois par an. Veillez à toujours publier la nouvelle clé dans le DNS avant de désactiver l'ancienne, afin d'éviter toute période pendant laquelle la vérification des e-mails ne serait pas possible.
9. Le protocole DKIM permet-il d'empêcher le phishing ?
Le protocole DKIM ne suffit pas à lui seul à empêcher le phishing. Il rend la falsification de vos e-mails plus difficile et empêche l'altération du contenu, mais il ne bloque pas l'usurpation de l'adresse d'expéditeur visible ; seul l'alignement DMARC permet cela. Le protocole DKIM constitue un élément indispensable d'une stratégie anti-phishing, mais il ne représente pas la solution complète.
10. Le protocole DKIM a-t-il une incidence sur la délivrabilité des e-mails ?
Le protocole DKIM a un impact positif sur la délivrabilité de vos e-mails. Un e-mail correctement signé renforce la réputation de l'expéditeur auprès des FAI, ce qui améliore son placement dans la boîte de réception. De plus, Google, Yahoo et Microsoft exigeant désormais le protocole DKIM pour les expéditeurs en masse, l'absence de cette signature peut entraîner le classement de votre e-mail dans le dossier « spam » ou son rejet.
- Qu'est-ce que la « fatigue MFA » (bombardement par poussée) ? - 21 juillet 2026
- Étude de cas DMARC MSP : comment Adoptive Technologies assure une sécurité centralisée des e-mails à ses clients grâce à PowerDMARC - 17 juillet 2026
- Comment configurer DMARC pour Google Workspace (Gmail) - 14 juillet 2026