Article

Le guide ultime de la délivrabilité

Jul 18, 2024

Article

Le guide ultime de la délivrabilité

Jul 18, 2024

You can build the best content strategy; if your message is not delivered, you will not achieve any results. So how can you be sure to deliver your messages? What are the good (and bad) practices around email?

To help you better understand how your daily tool works, the Sigilium team shares with you today a good dose of knowledge about email!

Summary

In this guide, we will see together:
- How sending and receiving an email works: the protocols that validate (or not) the delivery of a message
- How the display of images works

1. Mandatory Security

In 1971, shortly after the invention of Arpanet (the ancestor of the internet), an American engineer named Ray Tomlinson developed a messaging system using "@" as an address. At that moment, he had no idea that he had just invented one of the most popular means of communication in the world: emails.

Initially intended for restricted use, it was implemented with little to no security. It is possible to impersonate any sender, and the servers that relay emails have access to their content. A bit like if a letter were never placed in an envelope.

Today, in 2024, 53 years later, email is the most widely used means of communication in the world, and authenticating the identity of a sender and securing sent elements has become a major issue. To move in this direction, three protocols are essential: DKIM, SPF, and DMARC. These are the various protocols I will discuss today, explaining their operation.

Definitions

First of all, what is the purpose of each of them?

DKIM allows for the assured authentication of the sender of an email.
SPF lists the authorized mail servers allowed to send emails to your domain.
DMARC aims to reduce email abuse.

To continue and delve into the details of each of these protocols, one must understand the basics of encryption systems.

Basics of Encryption Systems

Let’s take a very simple example: you want to send a secret message to a friend, but this message will be carried by a third party (who should not understand the message).

Imagine you want to say HELLO to your friend. Instead of sending this message directly, you will encrypt it by shifting each letter 1 position in the alphabet.

HELLO will become: H⇒I E⇒F L⇒M L⇒M O⇒P.

Which is IFMMP, this encrypted message is called a “hash”.

The third party, who carries the message, will not understand the hash.

To encrypt the message, one must shift each letter 1 position to the right in the alphabet. ⇒ this is the private key.
To decrypt the message, one must shift 1 position to the left ⇒ this is the public key.

This encryption system used in the example is very simple (not robust at all). Furthermore, deducing the private key is instantaneous when one knows the public key.

A real encryption system will present different properties:

The private key cannot be guessed from the public key.
Trying to deduce the public or private key is completely impossible.

How Hash Works

To better understand the encryption of a message, let's take a closer look at what a hash is:

A hash is the output produced by a hashing function (encryption algorithm), which takes an input (like a password or a file) and generates a fixed-length string of characters. This string is unique for each distinct input, and even a slight modification of the input produces a completely different hash. Hashes are used in cryptography to verify data integrity, secure passwords, and identify files. In our example, the encryption of an email by the private key.

A key property of a hash is that it is practically impossible to retrieve the original input from the hash.

There are several types of hashing functions, such as MD5, which produces a 32-character hash but is no longer considered secure. SHA-1, which produces a 40-character hash and has also been deprecated. And finally, SHA-256, which produces a 64-character hash and is widely used today for its high security. These different types of hashes offer varying levels of security and are chosen based on the specific requirements of the application.

Now, imagine you want to send an encrypted message to a friend and ensure that they can be certain that this message truly comes from you. For this, you have two keys: - a private key (which you alone possess) and a public key that everyone can access.

Process
You write your message and encrypt it with your private key. This encryption marks your message with a unique signature, which only your private key can generate. The message is then sent to your friend. Upon receipt, they use the public key to verify the signature and decrypt the message. If the message decrypts, then they know that the message indeed came from you, because only a message encrypted with your private key can be decrypted with your public key.

Here, we are looking to authenticate the sender of the message, the decryption key (the public key) being visible to all, the content of the message is not secret.

DKIM

First, let’s talk about the DKIM protocol (DomainKeys Identified Mail), which allows for the identification of the sender of an email by digitally signing it with a private key that cannot be revealed to everyone. This key is unique to the sending company. In addition to being sent with the email, the signature also has a second key, this time public, which can be shown to everyone. The public key is sent to the receiver's DNS server, and then the mail server compares the two keys, and if they match, then the email arrives in the receiver's inbox. Otherwise, the email is sent to spam. This very practical protocol serves as the first line of defense. But unfortunately, it is not sufficient because attackers can also use it.

1. Une sécurité devenue obligatoire

1971, peu après l’invention d’Arpanet (l’ancêtre d’internet) un ingénieur américain du nom de Ray Tomlinson met au point un système de messagerie utilisant le « @ » en guise d’adresse, à ce moment il ne se doutait pas qu’il venait d’inventer l’un des moyens de communication parmi les plus populaires au monde : les e-mails.

À la base prévu pour un usage restreint il ne se vit implémenter d’aucune sécurité ou presque. Il est possible de se faire passer pour n’importe quel expéditeur et les serveurs qui relaient les emails ont accès à leur contenu. Un peu comme si une lettre n’était jamais mise sous enveloppe.

Aujourd’hui en 2024, 53 ans plus tard, l’e-mail est le moyen de communication le plus utilisé dans le monde, l’authentification de l’identité d’un expéditeur et la sécurité des éléments envoyés est devenu un enjeu majeur. Pour aller dans ce sens 3 protocoles s’imposent : DKIM, SPF et DMARC. Ce sont de ces différents protocoles dont je vais vous parler aujourd’hui, en vous explicitant leur fonctionnement.

Définitions

Tout d’abord quel est le but de chacun d’entre eux ?

DKIM permet d’authentifier avec certitude l’expéditeur d’un email.
SPF répertorie les serveurs de messagerie autorisés à envoyer de mails à votre domaine
DMARC sert à diminuer les abus en matière d’e-mails.

Pour continuer et rentrer dans le détail du fonctionnement de chacun de ces protocoles, il faut comprendre les bases des systèmes de cryptage.

Bases des systèmes de cryptage

Prenons un exemple très simple, vous souhaitez envoyer un message secret à un ami, mais ce message va être porté par un tiers (qui ne doit pas comprendre le message)

Imaginons que vous souhaitiez dire BONJOUR à votre ami. Plutôt que d’envoyer directement ce message, vous allez le chiffrer en décalant chaque lettre de 1 position dans l’alphabet.

BONJOUR deviendra : B⇒C O⇒ P N⇒ O J⇒ K O⇒ P U⇒ V R⇒ Q.

Soit CPOKPVQ, ce message chiffré est appelé un “hash”.

Le tiers, qui porte le message, ne comprendra pas le hash.

Pour chiffrer le message il faut décaler chaque lettre de 1 position vers la droite dans l’alphabet. ⇒ c’est la clef privée.
Pour déchiffrer le message il faut décaler de une position vers la gauche ⇒ c’est la clef publique.

Ce système de cryptage utilisé dans l’exemple est très simple, (pas du tout robuste). Par ailleurs la déduction de la clef privée est instantanée quand on connait la clef publique.

Un vrai système de cryptage va présenter des propriétés différentes :

La clef privée ne peut pas être devinée à partir de la clef publique.
Essayer de trouver par déduction la clef publique ou privée est totalement impossible.

Fonctionnement du Hash

Afin de mieux comprendre le chiffrement d’un message regardons plus précisément ce qu’est un hash :

Un hash est le résultat produit par une fonction de hachage (algorithme de chiffrement), qui prend une donnée d'entrée (comme un mot de passe ou un fichier) et génère une chaîne de caractères de longueur fixe. Cette chaîne est unique pour chaque entrée distincte et même une petite modification de l'entrée produit un hash complètement différent. Les hashs sont utilisés en cryptographie pour vérifier l'intégrité des données, sécuriser les mots de passe et identifier les fichiers. Dans notre exemple, le chiffrement d’un email par la clef privée.

Une propriété clé d'un hash est qu'il est pratiquement impossible de retrouver l'entrée originale à partir du hash.

Il existe plusieurs types de fonctions de hachage, comme MD5, qui produit un hash de 32 caractères mais n'est plus considéré comme sécurisé. SHA-1, qui produit un hash de 40 caractères et a également été déprécié. Et enfin SHA-256, qui produit un hash de 64 caractères et est largement utilisé aujourd'hui pour sa sécurité élevée. Ces différents types de hashes offrent des niveaux de sécurité variés et sont choisis en fonction des exigences spécifiques de l'application.

Maintenant imaginons que vous vouliez envoyer un message chiffré à un ami et qu’il puisse avoir la certitude que ce message vient bien de vous. Pour cela vous avez deux clés : - une clé privée (dont vous êtes le seul détenteur) et une clé publique auquel que tout le monde peut accéder.

Process
Vous écrivez votre message et vous le chiffrez avec votre clé privée. Ce chiffrement marque votre message d’une signature unique, que seul votre clé privée peut générer. Le message est ensuite envoyé à votre ami. À sa réception, il utilise la clé publique pour vérifier la signature et déchiffrer le message. Si le message se déchiffre, alors il sait que le message provient bien de vous, car seul un message chiffré de votre clé privée peut être déchiffré avec votre clé publique.

Ici on cherche à authentifier l’expéditeur du message, la clef de déchiffrement (la clef publique) étant visible par tous, le contenu du message n’est pas secret.

DKIM

Tout d’abord, parlons du protocole DKIM (DomainKeys Identified Mail), il permet d’identifier l’expéditeur d’un e-mail en le signant numériquement grâce à une clé privée, qui ne peut pas être montrée à tous. Cette clé est unique à l’entreprise expéditrice. En plus d’être envoyé avec l’email, le chiffre a aussi une seconde clé, cette fois publique, qui peut être montrée à tous. La clé publique est envoyé au serveur DNS du receveur, puis le serveur de messagerie compare les deux clés et si elles correspondent alors l’e-mail arrive dans la boîte de réception du receveur. Sinon l'email est envoyé dans les spams. Ce protocole très pratique sert de première barrière de défense. Mais elle ne suffit pas malheureusement, car des attaquants peuvent eux aussi l’utiliser.

SPF

That is why the DKIM protocol is often associated with an SPF (Sender Policy Framework), which can be defined as a sort of list that specifies the mail servers authorized to send emails to your domain by verifying that they come from the authorized sender.

SPF

DMARC

Finally, DMARC (Domain-based Message Authentication, Reporting and Conformance) is a security policy that builds on the DKIM and SPF specifications by providing instructions to the mail server on what to do if at least one of the two protocols is not followed, whether to send it to the spam folder or delete it outright.

DMARC

You're wondering what an email signature is exactly? It's simply a block of text, images, and links that you place at the bottom of your emails. Basically, it's like a virtual professional business card that appears with every email sent!

Generally, it contains the sender's contact details, who signs the message, and thus confirms their identity. These typically include the name, position, company name, address, phone number, and email address. These details allow your contacts to quickly identify and reach out to you if needed.

☝️ But be aware, an email signature is much more than just contact information! It's a genuine communication and marketing tool.

With a well-thought-out signature, you can:

Enhance your brand image by including your logo and colors, similar to a well-crafted business card
Drive qualified traffic to your website or social media with just one click
Showcase your latest content (blog articles, white papers, webinars...) directly in the email inboxes of your clients and prospects
Promote special offers, enticing discounts, or can't-miss events
Facilitate interaction and engagement from your correspondents through simple actions, like scheduling appointments, inviting them to contact or follow you with ease
Share legal information, always in a professional manner

In short, the email signature offers you valuable space to convey key messages systematically and on a large scale. It's an opportunity to deliver targeted and relevant content in every email exchange. It's like automatically distributing a personalized business card along with a tailored message to each of your contacts! When used effectively, it becomes a powerful lever for enhancing your visibility, generating leads, and strengthening trust and relationships.

How does image display work in emails?

Mail has become the most used means of communication in the world today, with nearly 360 billion emails sent per day, and knowing that nearly 90% of cyberattacks start with a simple email, security is a real necessity. Originally only text-based due to technological constraints between 1980 and 1990. Then in 1991, thanks to the introduction of the MIME standard (Multipurpose Internet Mail Extensions), which allowed various files to be attached, images could then be attached to the sent emails. This advancement was a turning point, allowing not only text to be sent but also multimedia files (images, videos, files…). Modern email clients have continued to evolve, improving support for HTML emails and embedded images with the ability to change font style, boldness, etc. Advances in CSS in the 2010s have allowed for more sophisticated and adaptive layouts, further improving how images are displayed and managed.

Outlook / Gmail: 2 different methods

Today we use 2 main methods to integrate images into an email: as an attachment or as a remote image.

Embedded images

Attachments where the images are then attached to the email via a unique identifier and referenced in the body of the email via Contents-ID (CID), a simple method of embedded image but which does not allow the display of images in the body of the email and increases the size of the message.

Remote images

A commonly used alternative is hosting images on a server, referenced in the email via URLs, then upon receiving the email, the image is downloaded to be displayed. This method of remote images keeps the size of the email small and allows images on the server to be updated without modifying the email, but it requires an internet connection to display the images and may be blocked by default to protect user privacy.

Advantages and disadvantages of each approach

How does image display work in emails?

Outlook / Gmail: 2 different methods

Today we use 2 main methods to integrate images into an email: as an attachment or as a remote image.

Embedded images

Remote images

Advantages and disadvantages of each approach

DMARC

Finally, DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a security policy based on the action specifications of DKIM and SPF, providing instructions to the mail server on what to do if at least one of the two protocols is not adhered to, whether to send it to the spam folder or to delete it directly.

Comment fonctionne l'affichage des images dans les emails ?

Le mail est aujourd’hui devenu le moyen de communication le plus utilisé dans le monde, avec près de 360 milliards de mails envoyés par jours et sachant que près de 90% des cyberattaques démarre par un simple mail, la sécurité est une véritable nécessité, à la base uniquement textuel pour cause de contraintes technologiques ente 1980 et 1990. Puis c’est en 1991, grâce à l'introduction du standard MIME (Multipurpose Internet Mail Extensions) qui a permis de joindre des fichiers divers que des images ont pu alors être jointes aux mails envoyés. Cette avancée a été un tournant décisif, permettant d'envoyer non seulement du texte mais aussi des fichiers multimédias en plus (images, vidéos, fichiers…). Les clients de messagerie modernes ont continué à évoluer, améliorant la prise en charge des emails HTML et des images intégrées avec la possibilité de modifier la police de l’écriture, son style, le mettre en gras (etc) . Les avancées en CSS au cours des années 2010 ont permis des mises en page plus sophistiquées et adaptatives, améliorant encore la manière dont les images sont affichées et gérées.

Outlook / Gmail : 2 méthodes différentes

Aujourd’hui on utilise 2 méthodes principales afin d’intégrer des images à un email : en pièce jointe ou comme image distante.

Images embarquées

Les pièces jointes où les images sont alors attachées au mail grâce à un identifiant unique et référencée dans le corps de l’email via des Contents-ID (CID), une méthode simple d’image embarquée mais qui ne permet pas l'affichage des images dans le corps de l'email et qui augmente la taille du message.

Images distantes

Une alternative couramment utilisée est l'hébergement des images sur un serveur, référencées dans l'email via des URLs, puis à la réception du mail l’image est téléchargée afin d’être affichée. Cette méthode d’images distantes maintient la taille de l'email petite et permet de mettre à jour les images sur le serveur sans modifier l'email, mais elle nécessite une connexion Internet pour afficher les images et peut être bloquée par défaut pour protéger la confidentialité des utilisateurs.

Avantages et inconvénients de chaque approche

Remote images
(Gmail and other messaging services)

Benefits

The email is lighter

Can be updated
without changing the email

Disadvantages

Requires an internet connection

Can be blocked

Possibilité de tracking des personnes si l’envoyeur demande une confirmation de lecture, ou si l’image est hébergée sur son serveur personnel

Operation on Different Messaging Services

For example, here is the Outlook application that uses the operation of embedded images in the body of the email; it will require manual confirmation to display your signature image.

From Outlook to Gmail
Case of an email with an embedded image sent to a messaging service that uses remote images.

The embedded image in the Outlook message is displayed correctly in Gmail.

From Gmail to Gmail

Case of an email with a remote image sent to a similar messaging service.

The remote image is displayed correctly upon reception in a messaging service with the same functionality for images.

From Gmail to Outlook

Case of an email with a remote image sent to a messaging service that uses embedded images.

By default, the image is not loaded until the user validates it or the sender is approved (white-listed) or in the contacts. This shows a certain security measure put in place by Outlook.
Note: It is possible to change these settings in the Outlook settings to display them by default.

Operation on Different Messaging Services

For example, here is the Outlook application that uses the operation of embedded images in the body of the email; it will require manual confirmation to display your signature image.

From Outlook to Gmail
Case of an email with an embedded image sent to a messaging service that uses remote images.

The embedded image in the Outlook message is displayed correctly in Gmail.

From Gmail to Gmail

Case of an email with a remote image sent to a similar messaging service.

The remote image is displayed correctly upon reception in a messaging service with the same functionality for images.

From Gmail to Outlook

Case of an email with a remote image sent to a messaging service that uses embedded images.

Les images embarquées
(Outlook / M.365)

Benefits

Offline availability

Pas de dépendance à une
ressource externe

Best security

Disadvantages

Deliverability issue: with many uploaded images may be considered to contain a malicious file.

The email is heavier

Fonctionnement sur différentes messageries

Par exemple ici l’application Outlook qui utilise le fonctionnement des images embarquées dans le corps du mail vous demandera une confirmation manuel afin d’afficher l’image de votre signature.

D'outlook vers Gmail
Cas d'un email avec une image embarquée vers une messagerie utilisant les images distantes.

L'image embarquée dans le message Outlook est bien affichée dans Gmail.

De Gmail vers Gmail

Cas d'un email avec une image distante vers une messagerie similiaire.

L'image distante est bien affichée en réception dans une messagerie avec le meme fonctionnement pour les images.

De Gmail vers Outlook

Cas d'un email avec une image distante vres une messagerie utilisant des images embarquées

Par défaut, l’image n'est pas chargée, tant que l'utilisateur ne l'a pas validée ou que l'expéditeur n'est pas approuvé (white-listé) ou dans les contacts. Cela montre une certaine sécurité mise en place par Outlook.
nb : Il est possible de modifier ces réglages dans les paramètres d'Outlook pour les afficher par défaut.