Article

The ultimate guide to deliverability

Articles

Jul 18, 2024

Article

The ultimate guide to deliverability

Articles

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. 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 the "@" 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.

Originally 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. It's a bit like a letter never being 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 the sent elements has become a major issue. To address this, three protocols are essential: DKIM, SPF, and DMARC. These are the different protocols I will discuss today, explaining how they work.

Definitions

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

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

To continue and dive into the details of how each of these protocols works, one must understand the basics of cryptographic systems.

Basics of Cryptographic 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 must 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 one position in the alphabet.

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

So it becomes IFMMP, this encrypted message is called a “hash”.

The third party, carrying the message, will not understand the hash.

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

This encryption system used in the example is very simple (not robust at all). Moreover, deducing the private key is instant when the public key is known.

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 look more specifically at what a hash is:

A hash is the result produced by a hashing function (encryption algorithm), which takes an input (such as a password or a file) and generates a fixed-length string of characters. This string is unique for each distinct input, and even a small 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.

Now imagine you want to send an encrypted message to a friend and ensure that this message indeed comes from you. For this, you have two keys: - a private key (of which you are the only holder) 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 that only your private key can generate. The message is then sent to your friend. Upon receiving it, they use the public key to verify the signature and decrypt the message. If the message decrypts, then they know that the message indeed comes from you, since only a message encrypted with your private key can be decrypted with your public key.

Here we seek 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 identifying the sender of an email by digitally signing it with a private key that cannot be shown to everyone. This key is unique to the sending company. In addition to being sent with the email, the digital signature also has a second key, this time public, which can be shown to everyone. The public key is sent to the recipient’s DNS server, and then the mail server compares the two keys, and if they match, the email arrives in the recipient's inbox. Otherwise, the email is sent to the spam folder. This very practical protocol serves as the first line of defense. But unfortunately, it is not sufficient, as attackers can also use it.

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

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 defines the mail servers authorized to send emails to your domain by verifying that they come from the authorized sender.

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.

How does image display in emails work?

Email has become the most widely used means of communication in the world today, with nearly 360 billion emails sent per day and knowing that about 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 (Multipurpose Internet Mail Extensions) standard that allowed various files to be attached, images could then be included in sent emails. This advancement was a decisive turning point, allowing not only text to be sent but also multimedia files (images, videos, files, etc.). Modern email clients have continued to evolve, enhancing support for HTML emails and embedded images with the ability to change the font, style, and make it bold (etc.). Advances in CSS over 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 images are then attached to the email through a unique identifier and referenced in the body of the email via Content-ID (CID), a simple method of embedded image but that 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 on receipt of the email, the image is downloaded to be displayed. This method of remote images keeps the email size small and allows for updating images on the server 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

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

Possibility of tracking individuals if the sender requests a read receipt, or if the image is hosted on their personal server

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.

Embeded pictures
(Outlook / M.365)

Benefits

Offline availability

• No dependence to any external resource

Best security

Disadvantages

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

The email is heavier

Operation on Different Messaging Services

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

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

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

From Gmail to Gmail

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

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

From Gmail to Outlook

Case of an email with a remote image to a messaging service using embedded images.

By default, the image is not loaded until the user has validated it or the sender has been approved (whitelisted) or is in the contacts. This shows a certain level of security put in place by Outlook.
Note: It is possible to modify these settings in the Outlook settings to display them by default.