You can build the best content strategy, if your message isn't delivered you won't get 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 Signitic team is sharing a good deal of email knowledge with you today!
Summary
In this guide, we'll look at:
- How does sending and receiving an email work: the protocols that validate (or not) the delivery of a message
- How does the image display work
1. Security that has become mandatory
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: e-mails.
Originally intended for restricted use, it was implemented with little or no security. It is possible to impersonate any sender and the servers that relay emails have access to their content. A bit as if a letter was never put in an envelope.
Today in 2024, 53 years later, email is the most used means of communication in the world, the authentication of the identity of a sender and the security of the elements sent has become a major challenge. To go in this direction, 3 protocols are required: DKIM, SPF and DMARC. These are the various protocols that I am going to talk to you about today, explaining how they work.
Definitions
First of all, what is the purpose of each of them?
- DKIM allows you to authenticate with certainty the sender of an email.
- SPF lists the email servers that are authorized to send email to your domain
- DMARC is used to reduce email abuse.
To continue and go into detail about how each of these protocols works, you need to 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)
Let's say you want to say HELLO to your friend. Instead of sending this message directly, you'll encrypt it by offsetting each letter by 1 position in the alphabet.
BONJOUR will become: B⇒ C O⇒ P N⇒ P N⇒ O J⇒ O J⇒ K O⇒ P U⇒ V R⇒ Q.
Let's say CPOKPVQ, this encrypted message is called A “hash”.
The third party carrying the message will not understand the hash.
- To encrypt the message you have to shift each letter 1 position to the right in the alphabet. ⇒ It's the private key.
- To decipher the message you have to shift one position to the left ⇒ It's the public key.
This encryption system used in the example is very simple, (not at all robust). Moreover, the deduction of the private key is instantaneous when you know the public key.
A real encryption system will have different properties:
- The private key cannot be guessed from the public key.
- Trying to find the public or private key by deduction is completely impossible.
How does Hash work
In order to better understand the encryption of a message, let's take a closer look at what a Hash :
A hash is the result produced by a hash function (encryption algorithm), which takes input data (such as a password or a file) and generates a fixed-length character string. This string is unique for each distinct entry and even a small change to the entry 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 virtually impossible to find the original entry from the hash.
There are several types of hash 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 according to the specific requirements of the application.
Now let's say you want to send an encrypted message to a friend and they can be sure that the message is coming from you. For this you have two keys: - a private key (of which you are the sole owner) and a public key that anyone 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, it uses the public key to verify the signature and decrypt the message. If the message can be decrypted, then he knows that the message actually came from you, because 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), it makes it possible to identify the sender of an email by signing it digitally using a private key, which cannot be shown to everyone. This key is unique to the sending company. In addition to being sent with the email, the number also has a second key, this time public, that can be shown to anyone. The public key is sent to the receiver's DNS server, then the email 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 defense barrier. Unfortunately, it is not enough, because attackers can also use it.
SPF
This is why the DKIM protocol is often associated with an SPF (Sender Policy Framework), which can be defined as a kind of list that defines the email servers that are authorized to send emails to your domain by verifying that they come from the authorized sender.
DMARC
Finally, DMARC (Domain-based Message Authentication, Reporting and Conformance) is a security policy based on DKIM and SPF action specifications by giving instructions to the email server what to do if at least one of the two protocols is not respected, whether to send it in spam or directly delete it.
How does the display of images in emails work?
Email has now become the most used means of communication in the world, 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, based solely on text because of technological constraints between 1980 and 1990. Then it was in 1991, thanks to the introduction of the MIME standard (Multipurpose Internet Mail Extensions), which made it possible to attach various files, that images could then be attached to the emails sent. This advance was a decisive turning point, making it possible to send not only text but also multimedia files in addition (images, videos, files...). Modern email clients have continued to evolve, improving the support for HTML emails and embedded images with the ability to change the font, style, bold (etc.). Advances in CSS during the 2010s allowed for more sophisticated and responsive layouts, further improving the way 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 using a unique identifier and referenced in the body of the email via Content-IDs (CID), a simple embedded image method but which does not allow images to be displayed in the body of the email and that increases the size of the message.
Remote images
A commonly used alternative is the hosting of images on a server, referenced in the email via URLs, then upon receipt of the email the image is downloaded in order to be displayed. This remote image method keeps the email size small and allows images to be updated on the server without changing the email, but it requires an Internet connection to view the images and can be blocked by default to protect user privacy.
Operation on different messaging systems
For example, here the Outlook application, which uses the operation of the images embedded in the body of the email, will ask you for manual confirmation in order to display the image of your signature.
From Outlook to Gmail
Case of an email with an image embedded in a messenger using remote images.
The image embedded in the Outlook message is displayed correctly in Gmail.
From Gmail to Gmail
Case of an email with a remote image to a similar email.
The remote image is well displayed on reception in a messaging system with the same operation for images.
From Gmail to Outlook
Case of an email with a remote image to a messenger using embedded images
By default, the image is not loaded until the user has validated it or the sender is not approved (white-listed) or in the contacts. This shows some security that Outlook has put in place.
nb: It is possible to change these settings in the Outlook settings to display them by default.
