Lorsqu'un courrier électronique est envoyé du serveur d'envoi, directement au serveur de réception, SPF et DKIM (s'ils sont configurés correctement) authentifient normalement le courrier électronique et le valident généralement comme étant légitime ou non autorisé. Toutefois, ce n'est pas le cas si le courrier électronique passe par un serveur de courrier intermédiaire avant d'être remis au destinataire, comme dans le cas des messages transférés. Ce blog est destiné à vous faire découvrir l'impact de la redirection de courrier électronique sur les résultats de l'authentification DMARC.

Comme nous le savons déjà, la DMARC utilise deux protocoles d'authentification de courrier électronique standard, à savoir SPF (Sender Policy Framework) et DKIM (DomainKeys Identified Mail), pour valider les messages entrants. Examinons-les brièvement pour mieux comprendre leur fonctionnement avant de passer à la question de savoir comment le transfert peut les affecter.

Cadre politique de l'expéditeur

Le SPF est présent dans votre DNS sous la forme d'un enregistrement TXT, affichant toutes les sources valides autorisées à envoyer des courriels à partir de votre domaine. Chaque courrier électronique qui quitte votre domaine possède une adresse IP qui identifie votre serveur et le fournisseur de services de courrier électronique utilisé par votre domaine qui est inscrit dans votre DNS comme un enregistrement SPF. Le serveur de messagerie du destinataire valide le courrier électronique par rapport à votre enregistrement SPF pour l'authentifier et, en conséquence, marque le courrier électronique comme SPF pass or fail.

Courrier identifié DomainKeys

DKIM est un protocole standard d'authentification du courrier électronique qui attribue une signature cryptographique, créée à l'aide d'une clé privée, pour valider les courriers électroniques dans le serveur de réception, dans lequel le récepteur peut récupérer la clé publique du DNS de l'expéditeur pour authentifier les messages. Tout comme le SPF, la clé publique DKIM existe également sous la forme d'un enregistrement TXT dans le DNS du propriétaire du domaine.

L'impact de la redirection de courrier électronique sur vos résultats d'authentification DMARC

Lors de la transmission du courrier électronique, le courrier passe par un serveur intermédiaire avant d'être finalement livré au serveur de réception. Tout d'abord, il est important de comprendre que la redirection de courrier électronique peut se faire de deux manières : soit les courriers électroniques peuvent être transmis manuellement, ce qui n'affecte pas les résultats de l'authentification, soit ils peuvent être transmis automatiquement, auquel cas la procédure d'authentification est perturbée si le domaine ne dispose pas de l'enregistrement de la source d'envoi intermédiaire dans son SPF.

Naturellement, la vérification du SPF échoue généralement lors de la transmission du courrier électronique, car l'adresse IP du serveur intermédiaire ne correspond pas à celle du serveur d'envoi, et cette nouvelle adresse IP n'est généralement pas incluse dans l'enregistrement SPF du serveur d'origine. Au contraire, la redirection de courriers électroniques n'a généralement pas d'incidence sur l'authentification DKIM, à moins que le serveur intermédiaire ou l'entité de redirection n'apporte certaines modifications au contenu du message.

Il est à noter que pour qu'un courriel passe l'authentification DMARC, il doit passer l'authentification et l'alignement SPF ou DKIM. Comme nous savons que le SPF échoue inévitablement lors de la transmission du courrier électronique, si la source d'envoi est neutre par rapport au DKIM et ne s'appuie que sur le SPF pour la validation, le courrier électronique transmis sera rendu illégitime lors de l'authentification DMARC.

La solution ? Simple. Vous devez immédiatement opter pour une conformité totale au DMARC dans votre organisation en alignant et en authentifiant tous les messages entrants à la fois sur SPF et DKIM !

Obtenir la conformité du DMARC avec PowerDMARC

Il est important de noter que pour être conformes aux normes DMARC, les courriers électroniques doivent être authentifiés soit par SPF, soit par DKIM, soit par les deux. Cependant, à moins que les messages transférés ne soient validés par rapport au DKIM, et ne reposent que sur le SPF pour l'authentification, le DMARC échouera inévitablement, comme nous l'avons vu dans la section précédente. C'est pourquoi PowerDMARC vous aide à atteindre une conformité complète avec DMARC en alignant et en authentifiant efficacement les courriers électroniques avec les protocoles d'authentification SPF et DKIM. De cette façon, même si les messages authentiques transférés échouent SPF, la signature DKIM peut être utilisée pour le valider comme légitime et le courriel passe l'authentification DMARC, pour ensuite atterrir dans la boîte de réception du destinataire.

Cas exceptionnels : L'échec de DKIM et comment le résoudre ?

Dans certains cas, l'entité de transmission peut modifier le corps du courrier en procédant à des ajustements dans les limites MIME, en mettant en œuvre des programmes antivirus ou en réencodant le message. Dans ce cas, l'authentification SPF et DKIM échoue et les courriels légitimes ne sont pas distribués.

En cas de défaillance des deux systèmes SPF et DKIM, PowerDMARC est en mesure d'identifier et d'afficher que dans nos vues globales détaillées et des protocoles comme Authenticated Received Chain peuvent être exploités par les serveurs de messagerie pour authentifier ces courriels. Dans ARC, l'en-tête Authentication-Results peut être transmis au prochain "saut" dans la ligne de livraison du message, afin d'atténuer efficacement les problèmes d'authentification lors de la transmission du courrier électronique.

Dans le cas d'un message transféré, lorsque le serveur de messagerie du destinataire reçoit un message dont l'authentification DMARC a échoué, il tente de valider le courrier électronique une seconde fois, par rapport à la chaîne de réception authentifiée fournie pour le courrier électronique en extrayant les résultats d'authentification ARC du saut initial, pour vérifier s'il a été validé comme étant légitime avant que le serveur intermédiaire ne le transmette au serveur de réception.

Alors, inscrivez-vous à PowerDMARC dès aujourd'hui, et obtenez la conformité au DMARC dans votre organisation !

 

ARC ou Authenticated Received Chain est un système d'authentification du courrier électronique qui affiche l'évaluation de l'authentification d'un courrier électronique à chaque étape du traitement. En termes plus simples, la chaîne de réception authentifiée peut être appelée "chaîne de garde" pour les messages électroniques qui permettent à chaque entité qui traite les messages de voir effectivement toutes les entités qui l'ont traité auparavant. En tant que protocole relativement nouveau publié et documenté comme "expérimental" dans la RFC 8617 en juillet 2019, ARC permet au serveur de réception de valider les courriels même lorsque SPF et DKIM sont rendus invalides par un serveur intermédiaire.

Comment une chaîne d'aide authentifiée peut-elle être reçue ?

Comme nous le savons déjà, le DMARC permet d'authentifier un courrier électronique selon les normes d'authentification SPF et DKIM, en précisant au destinataire comment traiter les courriers électroniques dont l'authentification est réussie ou échouée. Cependant, si vous appliquez la politique DMARC à votre organisation, il y a des chances que même des courriels légitimes, comme ceux envoyés par une liste de diffusion ou un expéditeur, échouent à l'authentification et ne soient pas livrés au destinataire ! La chaîne de réception authentifiée permet d'atténuer efficacement ce problème. Voyons comment dans la section suivante :

Situations dans lesquelles l'ARC peut aider

  • Listes de diffusion 

En tant que membre d'une liste de diffusion, vous avez le pouvoir d'envoyer des messages à tous les membres de la liste en une seule fois en vous adressant à la liste de diffusion elle-même. L'adresse de réception transmet ensuite votre message à tous les membres de la liste. Dans la situation actuelle, le DMARC ne parvient pas à valider ce type de messages et l'authentification échoue même si le courriel a été envoyé à partir d'une source légitime ! Cela est dû au fait que le SPF se brise lorsqu'un message est transféré. Comme la liste de diffusion intègre souvent des informations supplémentaires dans le corps du courriel, la signature DKIM peut également être invalidée en raison de changements dans le contenu du courriel.

  • Transmission des messages 

Lorsqu'il y a un flux de courrier indirect, par exemple lorsque vous recevez un courrier électronique d'un serveur intermédiaire et non directement du serveur d'envoi comme dans le cas des messages transférés, le SPF se brise et votre courrier électronique échoue automatiquement l'authentification DMARC. Certains expéditeurs modifient également le contenu du courrier électronique, c'est pourquoi les signatures DKIM sont également invalidées.

 

 

Dans de telles situations, la chaîne de réception authentifiée vient à la rescousse ! Comment ? Nous allons le découvrir :

Comment fonctionne l'ARC ?

Dans les situations énumérées ci-dessus, les expéditeurs avaient initialement reçu des courriels qui avaient été validés par rapport à la configuration du DMARC, d'une source autorisée. La chaîne Authenticated Received Chain est une spécification qui permet de transmettre l'en-tête Authentication-Results au prochain "saut" dans la ligne de livraison du message.

Dans le cas d'un message transféré, lorsque le serveur de messagerie du destinataire reçoit un message dont l'authentification DMARC a échoué, il tente de valider le courrier électronique une seconde fois, par rapport à la chaîne de réception authentifiée fournie pour le courrier électronique en extrayant les résultats d'authentification ARC du saut initial, pour vérifier s'il a été validé comme étant légitime avant que le serveur intermédiaire ne le transmette au serveur de réception.

Sur la base des informations extraites, le destinataire décide de permettre ou non aux résultats de l'ARC d'outrepasser la politique du DMARC, ce qui permet de faire passer le courriel pour authentique et valide et de le livrer normalement dans la boîte de réception du destinataire.

Avec la mise en œuvre de l'ARC, le destinataire peut effectivement authentifier le courrier électronique à l'aide des informations suivantes :

  • Les résultats de l'authentification, tels que constatés par le serveur intermédiaire, ainsi que l'historique complet des résultats de validation SPF et DKIM dans le saut initial.
  • Informations nécessaires pour authentifier les données envoyées.
  • Informations permettant de lier la signature envoyée au serveur intermédiaire afin que le courrier électronique soit validé dans le serveur de réception même si l'intermédiaire en modifie le contenu, à condition qu'il transmette une nouvelle signature DKIM valide.

Mise en œuvre de la chaîne de réception authentifiée

L'ARC définit trois nouveaux en-têtes de courrier :

  • ARC-Résultats d'authentification (AAR): Le premier des en-têtes de courrier est l'AAR qui encapsule les résultats d'authentification tels que SPF, DKIM et DMARC.

  • ARC-Seal (AS) - AS est une version plus simple d'une signature DKIM, qui contient des informations sur les résultats de l'en-tête d'authentification, et la signature ARC.

  • ARC-Message-Signature (AMS) - L'AMS est également similaire à une signature DKIM, qui prend une image de l'en-tête du message qui incorpore tout, sauf les en-têtes ARC-Seal tels que les champs To : et From :, l'objet et le corps entier du message.

Étapes effectuées par le serveur intermédiaire pour signer une modification :

Étape 1 : le serveur copie le champ "Authentication-Results" dans un nouveau champ AAR et le préfixe au message

Étape 2 : le serveur formule l'AMS pour le message (avec l'AAR) et le prépare au message.

Étape 3 : le serveur formule l'AS pour les en-têtes ARC-Seal précédents et l'ajoute au message.

Enfin, pour valider la chaîne de réception authentifiée et savoir si un message transmis est légitime ou non, le destinataire valide la chaîne ou les en-têtes de sceau ARC et la toute nouvelle signature de message ARC. Si les en-têtes ARC ont été modifiés de quelque manière que ce soit, le courrier électronique échoue par conséquent l'authentification DKIM. Cependant, si tous les serveurs de courrier électronique impliqués dans la transmission du message signent et transmettent correctement ARC, le courrier électronique conserve les résultats de l'authentification DKIM et passe l'authentification DMARC, ce qui permet la livraison du message dans la boîte de réception du destinataire !

La mise en œuvre de l'ARC soutient et appuie l'adoption de la DMARC dans les organisations afin de s'assurer que chaque courriel légitime est authentifié sans une seule défaillance. Inscrivez-vous à votre essai gratuit du DMARC dès aujourd'hui !

 

Mail Transfer Agent-Strict Transport Security (MTA-STS) est une nouvelle norme qui permet aux fournisseurs de services de courrier électronique ayant la capacité d'appliquer la sécurité de la couche transport (TLS) de sécuriser les connexions SMTP, et de spécifier si les serveurs SMTP d'envoi doivent refuser de délivrer des courriers électroniques aux hôtes MX qui n'offrent pas la TLS avec un certificat de serveur fiable. Il a été prouvé qu'il permettait d'atténuer avec succès les attaques de déclassement TLS et les attaques de type "Man-In-The-Middle" (MITM ).

En termes plus simples, MTA-STS est une norme Internet qui sécurise les connexions entre les serveurs de messagerie SMTP. Le problème le plus important du SMTP est que le cryptage est totalement optionnel et n'est pas appliqué pendant le transfert du courrier. C'est pourquoi le SMTP a adopté la commande STARTTLS pour passer du texte en clair au cryptage. Il s'agissait d'une étape importante pour atténuer les attaques passives, mais les attaques via les réseaux actifs et les attaques MITM n'ont toujours pas été traitées.

Par conséquent, le problème que le MTA-STS est en train de résoudre est que le SMTP utilise un cryptage opportuniste, c'est-à-dire que si un canal de communication crypté ne peut être établi, la connexion retombe en texte clair, ce qui permet de tenir le MITM et de repousser les attaques.

Qu'est-ce qu'une attaque de dégradation TLS ?

Comme nous le savons déjà, le SMTP n'était pas accompagné d'un protocole de chiffrement et le chiffrement a dû être ajouté ultérieurement pour renforcer la sécurité du protocole existant en ajoutant la commande STARTTLS. Si le client prend en charge le cryptage (TLS), il comprendra le verbe STARTTLS et initiera un échange TLS avant d'envoyer le courrier électronique pour s'assurer qu'il est crypté. Si le client ne connaît pas TLS, il ignorera simplement la commande STARTTLS et enverra le courrier électronique en clair.

Par conséquent, comme le cryptage a dû être intégré au protocole SMTP, la mise à niveau pour la livraison cryptée doit s'appuyer sur une commande STARTTLS envoyée en clair. Un attaquant MITM peut facilement exploiter cette fonctionnalité en effectuant une attaque de niveau inférieur sur la connexion SMTP en altérant la commande de mise à niveau. L'attaquant remplace simplement la commande STARTTLS par une chaîne de caractères de récupération que le client ne parvient pas à identifier. Par conséquent, le client se rabat facilement sur l'envoi d'un courrier électronique en texte clair.

L'attaquant remplace généralement la commande par la chaîne de caractères de la poubelle contenant le même nombre de caractères, plutôt que de la jeter, car cela préserve la taille du paquet et donc, facilite la tâche. Les huit lettres de la chaîne "garbage" de la commande optionnelle nous permettent de détecter et d'identifier qu'une attaque de niveau inférieur TLS a été exécutée par un cybercriminel, et nous pouvons en mesurer la prévalence.

En bref, une attaque de niveau inférieur est souvent lancée dans le cadre d'une attaque MITM, afin de créer une voie permettant une attaque cryptographique qui ne serait pas possible dans le cas d'une connexion cryptée sur la dernière version du protocole TLS, en remplaçant ou en supprimant la commande STARTTLS et en ramenant la communication en texte clair.

S'il est possible d'appliquer le TLS pour les communications client-serveur, nous savons que les applications et le serveur le prennent en charge pour ces connexions. Cependant, pour les communications de serveur à serveur, nous devons empêcher l'ouverture des serveurs existants pour permettre l'envoi de courriers électroniques. Le nœud du problème est que nous n'avons aucune idée si le serveur de l'autre côté supporte TLS ou non. MTA-STS permet aux serveurs d'indiquer qu'ils supportent le TLS, ce qui leur permettra de se fermer (c'est-à-dire de ne pas envoyer le courrier électronique) si la négociation de la mise à niveau n'a pas lieu, rendant ainsi impossible une attaque de dégradation du TLS.

rapport tls

Comment le MTA-STS vient-il à la rescousse ?

Le MTA-STS fonctionne en augmentant la sécurité du courrier électronique EXO ou Exchange Online et constitue la solution ultime à un large éventail d'inconvénients et de problèmes de sécurité SMTP. Il résout les problèmes de sécurité SMTP tels que le manque de prise en charge des protocoles sécurisés, les certificats TLS expirés et les certificats qui ne sont pas émis par des tiers fiables .

Lorsque les serveurs de messagerie procèdent à l'envoi de courriers électroniques, la connexion SMTP est vulnérable aux attaques cryptographiques telles que les attaques par déclassement et le MITM. Les attaques de niveau inférieur peuvent être lancées en supprimant la réponse STARTTLS, ce qui permet d'envoyer le message en texte clair. De même, les attaques MITM peuvent également être lancées en redirigeant le message vers un intrus sur un serveur via une connexion non sécurisée. MTA-STS permet à votre domaine de publier une politique qui rend obligatoire l'envoi d'un courriel avec TLS crypté. Si, pour une raison quelconque, le serveur de réception ne prend pas en charge STARTTLS, le courrier électronique ne sera pas envoyé du tout. Il est alors impossible de lancer une attaque TLS de niveau inférieur.

Ces derniers temps, la majorité des fournisseurs de services de courrier électronique ont adopté le MTA-STS, rendant ainsi les connexions entre les serveurs plus sûres et cryptées grâce au protocole TLS dans une version mise à jour, ce qui a permis d'atténuer les attaques de déclassement TLS et d'annuler les failles dans la communication des serveurs.

PowerDMARC vous apporte des services MTA-STS hébergés rapides et faciles qui vous facilitent la vie car nous nous occupons de toutes les spécifications requises par MTA-STS pendant et après la mise en œuvre, comme un serveur web compatible HTTPS avec un certificat valide, des enregistrements DNS et une maintenance constante. PowerDMARC gère tout cela complètement en arrière-plan, de sorte qu'après que nous vous ayons aidé à le mettre en place, vous n'avez même plus à y penser !

Avec l'aide de PowerDMARC, vous pouvez déployer le MTA-STS hébergé dans votre organisation sans tracas et à un rythme très rapide, à l'aide duquel vous pouvez faire en sorte que les courriels soient envoyés à votre domaine via une connexion cryptée TLS, ce qui sécurise votre connexion et tient à distance les attaques de niveau inférieur TLS.

 

Une norme Internet largement connue qui facilite en améliorant la sécurité des connexions entre les serveurs SMTP (Simple Mail Transfer Protocol) est le SMTP Mail Transfer Agent-Strict Transport Security (MTA-STS).

En 1982, le SMTP a été spécifié pour la première fois et il ne contenait aucun mécanisme permettant d'assurer la sécurité au niveau du transport pour sécuriser les communications entre les agents de transfert du courrier. Toutefois, en 1999, la commande STARTTLS a été ajoutée au SMTP qui, à son tour, a pris en charge le cryptage des courriers électroniques entre les serveurs, offrant la possibilité de convertir une connexion non sécurisée en une connexion sécurisée qui est cryptée à l'aide du protocole TLS.

Dans ce cas, vous devez vous demander pourquoi le passage au MTA-STS était nécessaire si le SMTP a adopté les STARTTLS pour sécuriser les connexions entre les serveurs. Voyons cela dans la section suivante de ce blog !

La nécessité de passer à la MTA-STS

STARTTLS n'était pas parfait, et il n'a pas réussi à résoudre deux problèmes majeurs : le premier étant qu'il s'agit d'une mesure facultative, donc STARTTLS ne parvient pas à prévenir les attaques de l'homme du milieu (MITM). En effet, un attaquant MITM peut facilement modifier une connexion et empêcher la mise à jour du cryptage. Le deuxième problème est que même si STARTTLS est mis en œuvre, il n'y a aucun moyen d'authentifier l'identité du serveur d'envoi car les serveurs de courrier SMTP ne valident pas les certificats.

Bien que la plupart des courriers électroniques sortants soient aujourd'hui sécurisés par le cryptage TLS (Transport Layer Security), une norme industrielle adoptée même par les courriers électroniques des consommateurs, les attaquants peuvent toujours faire obstruction et altérer votre courrier électronique avant même qu'il ne soit crypté. Si vous envoyez vos courriels par une connexion sécurisée, vos données pourraient être compromises ou même modifiées et altérées par un cyber-attaquant. C'est ici que MTA-STS intervient et résout ce problème, en garantissant un transit sûr de vos courriers électroniques et en atténuant avec succès les attaques MITM. En outre, les MTA stockent les fichiers de politique MTA-STS, ce qui rend plus difficile pour les attaquants de lancer une attaque de spoofing DNS.

Le MTA-STS offre une protection contre :

  • Les attaques de dégradation
  • Attaques de l'homme au milieu (MITM)
  • Il résout de nombreux problèmes de sécurité SMTP, notamment les certificats TLS expirés et le manque de prise en charge des protocoles sécurisés.

Comment fonctionne le MTA-STS ?

Le protocole MTA-STS est déployé en disposant d'un enregistrement DNS qui spécifie qu'un serveur de messagerie peut récupérer un fichier de politique à partir d'un sous-domaine spécifique. Ce fichier de politique est récupéré via HTTPS et authentifié par des certificats, ainsi que la liste des noms des serveurs de messagerie des destinataires. La mise en œuvre de MTA-STS est plus facile du côté du destinataire que du côté de l'expéditeur car elle nécessite d'être prise en charge par le logiciel du serveur de messagerie. Si certains serveurs de courrier électronique prennent en charge MTA-STS, comme PostFix, ce n'est pas le cas de tous.

MTA STS hébergé

Les principaux fournisseurs de services de courrier tels que Microsoft, Oath et Google prennent en charge MTA-STS. Le service Gmail de Google a déjà adopté les politiques MTA-STS ces derniers temps. MTA-STS a supprimé les inconvénients de la sécurité des connexions de messagerie en rendant le processus de sécurisation des connexions facile et accessible pour les serveurs de messagerie pris en charge.

Les connexions des utilisateurs aux serveurs de messagerie sont généralement protégées et cryptées avec le protocole TLS, mais il existait déjà un manque de sécurité dans les connexions entre les serveurs de messagerie avant la mise en œuvre de MTA-STS. Avec une prise de conscience accrue de la sécurité du courrier électronique ces derniers temps et le soutien des principaux fournisseurs de courrier électronique dans le monde, la majorité des connexions de serveurs devraient être cryptées dans un avenir récent. En outre, le MTA-STS garantit efficacement que les cybercriminels sur les réseaux ne peuvent pas lire le contenu du courrier électronique.

Déploiement facile et rapide des services MTA-STS hébergés par PowerDMARC

Le MTA-STS nécessite un serveur web compatible HTTPS avec un certificat valide, des enregistrements DNS et une maintenance constante. PowerDMARC vous facilite la vie en gérant tout cela pour vous, complètement en arrière-plan. Une fois que nous vous avons aidé à le mettre en place, vous n'avez même plus besoin d'y penser.

Avec l'aide de PowerDMARC, vous pouvez déployer le MTA-STS hébergé dans votre organisation sans tracas et à un rythme très rapide, à l'aide duquel vous pouvez faire en sorte que les courriels soient envoyés à votre domaine via une connexion cryptée TLS, ce qui sécurise votre connexion et tient les attaques MITM à distance.

 

 

Avec l'augmentation constante des attaques de phishing, des attaques d'usurpation de nom de domaine et de courrier électronique, du BEC et d'autres activités frauduleuses des cybercriminels, une couche supplémentaire de sécurité et de protection du courrier électronique est toujours une bonne idée ! Les destinataires de courriels sont de plus en plus méfiants à l'égard des messages qui atterrissent dans leur boîte de réception en raison de la montée des cyberattaques. La solution ? Une suite complète de sécurité du courrier électronique qui inclut la mise en œuvre de la BIMI.

Une récente enquête menée par des professionnels de la sécurité aux États-Unis a révélé que 60 % des citoyens américains affirment avoir été victimes d'une cyber-arnaque ou connaître quelqu'un qui en a été victime, dans leur entourage proche, après la pandémie. Par conséquent, afin de fournir à leurs courriels une couche de protection supplémentaire, les entreprises doivent mettre en œuvre une nouvelle norme comme les indicateurs de marque pour l'identification des messages (BIMI), car elle promet de faire passer la confiance des consommateurs à un niveau supérieur.

Qu'est-ce que le BIMI ?

BIMI signifie Brand Indicators for Message Identification, une nouvelle norme d'authentification des courriels qui appose le logo de votre marque sur tous les courriels que vous avez autorisés. Cela peut sembler un tout petit pas, mais la vérification visuelle peut en fait accroître la crédibilité de votre marque en permettant aux destinataires de reconnaître et de faire confiance aux courriels que vous envoyez à partir de votre domaine de messagerie professionnelle.

Vous vous demandez peut-être, si vous avez déjà mis en place dans votre organisation la DMARC, qui utilise les normes d'authentification SPF et DKIM, avez-vous même besoin de la BIMI ? Examinons brièvement comment chacune de ces normes fonctionne pour authentifier les courriers électroniques entrants :

  • LeSPF authentifie vos e-mails pour identifier les serveurs de messagerie qui sont autorisés à envoyer des e-mails à partir de votre domaine de messagerie, inscrit dans l'enregistrement SPF.
  • DKIM authentifie les courriels en y ajoutant une signature numérique, ce qui permet au destinataire de vérifier si un courriel prétendant provenir d'un domaine spécifique a bien été autorisé par le propriétaire de ce domaine.
  • LaDMARC spécifie aux fournisseurs de boîtes de réception comment répondre aux courriels qui échouent à l'authentification SPF et DKIM.
  •  LaBIMI appose le logo de votre marque sur les courriels que vous envoyez à vos employés, partenaires et clients afin qu'ils puissent rapidement identifier qu'il provient d'une source autorisée.

Il ressort donc clairement de la discussion ci-dessus que, parmi tous les protocoles d'authentification du courrier électronique, le BIMI est la seule norme qui permet une identification visuelle, offrant aux destinataires du courrier électronique un indice visuel pour identifier la source du courrier électronique et reconnaître son authenticité.

Logo PowerDMARC Mobile

Mise en œuvre du BIMI - Guide succinct

Bien que la BIMI soit une norme d'authentification émergente et en constante évolution, elle est encore relativement nouvelle. Jusqu'à présent, seul Yahoo ! Mail a officiellement adopté cette technologie. Pour cette raison, BIMI ne garantit pas l'affichage du logo de votre marque car il ne fonctionne qu'avec les clients de messagerie électronique pris en charge. Il y a quelques étapes essentielles à suivre, avant la mise en œuvre de BIMI, qui sont les suivantes

  • Afin de mettre en œuvre la BIMI dans votre organisation, votre domaine doit être authentifié par le DMARC à un niveau d'application politique, c'est-à-dire soit le rejet, soit la quarantaine.
  • Vous devez créer et télécharger un fichier SVG du logo de votre marque, conformément aux exigences du BIMI, sur un serveur afin qu'il soit accessible de partout.
  • Vous devez créer un enregistrement BIMI, qui, comme un enregistrement DMARC, est essentiellement une chaîne de caractères composée de plusieurs balises, séparées par des points-virgules.
  • Vous devez avoir accès au DNS de votre domaine pour publier ce nouvel enregistrement BIMI.
  • C'est une pratique plutôt utile de vérifier la validité de votre enregistrement BIMI après sa publication dans votre DNS.

Comment la mise en œuvre du BIMI peut-elle s'avérer avantageuse pour votre entreprise ?

BIMI est un protocole d'authentification du courrier électronique qui exerce une identification visuelle pour aider les destinataires du courrier électronique à reconnaître votre marque dans la boîte de réception et à lui faire confiance. Cette confiance empêche les clients et les partenaires de se désabonner de vos services et permet également d'éviter les plaintes pour spam, ce qui peut par la suite améliorer la délivrabilité du courrier électronique.

Sans le BIMI, un logo générique avec les initiales de la marque est affiché par les clients de messagerie électronique. Pour cette raison, le destinataire peut avoir du mal à reconnaître votre marque sans avoir recours au nom de celle-ci. Cependant, avec l'implémentation de BIMI, le logo de la marque est affiché à côté de votre message électronique, ce qui renforce la notoriété de la marque.

En outre, il s'agit d'une couche supplémentaire de sécurité du courrier électronique contre les attaques d'usurpation de domaine, les attaques de phishing et autres tentatives d'usurpation d'identité, car les destinataires se méfieraient davantage des cybercriminels se faisant passer pour vous.

De plus, le BIMI vous permet de commercialiser votre marque. Oui, vous m'avez bien entendu ! Parfois, les destinataires n'ont pas beaucoup de temps à disposition et il se peut que votre sujet ne soit pas assez convaincant pour qu'on clique dessus en ce moment. Quoi qu'il en soit, vos destinataires feront le lien entre votre adresse d'expéditeur, l'objet de votre message et le texte de l'en-tête et votre logo, ce qui contribuera à renforcer votre marque.

Enfin, la mise en œuvre du BIMI a également un impact très positif sur le taux de délivrabilité de votre courrier électronique ! Pour les fournisseurs de boîtes aux lettres qui prennent en charge la BIMI, cela ajoutera une autre couche d'authentification à vos messages, augmentant ainsi les chances qu'ils livrent votre courrier électronique plus rapidement. En outre, vos destinataires de courrier électronique peuvent identifier et reconnaître visuellement votre marque, grâce au logo affiché, ce qui diminue les chances qu'ils la marquent comme spam.

Facilitez votre processus de mise en œuvre de la BIMI avec PowerBIMI

Avec PowerBIMI, nous rendons l'édition de disques BIMI très rapide et simple pour vous ! Il vous suffit de télécharger votre image SVG, nous l'hébergerons en toute sécurité et vous fournirons un enregistrement DNS instantanément, afin que vous puissiez le publier dans votre DNS. Nous vous enlevons de l'épaule la douleur d'héberger l'image et de la sécuriser.

Avec PowerBIMI, vous pouvez mettre à jour, supprimer ou modifier votre image, à tout moment, sans avoir besoin de mettre à jour à nouveau vos enregistrements DNS. PowerBIMI vous offre une procédure de mise en œuvre très rapide et facile en un seul clic pour télécharger votre logo et passer avec succès à l'authentification BIMI, en l'ajoutant à votre suite de sécurité du courrier électronique après avoir souscrit à un enregistrement BIMI gratuit.