What is SSL Email? Secure Email Communication Explained

Before you can understand how SSL encrypts emails, you need to understand how emails work in the first place. 

When you send an email, it doesn’t just go directly to the recipient. When you hit “send”, your email client (such as Outlook, Gmail, etc.) sends it to an SMTP (Simple Mail Transfer Protocol) server. The SMTP server is where outgoing emails are processed and then sent to their final destination.

During this process, a few things happen:

If the email needs to travel over the internet, your SMTP server will query the Domain Name System (DNS) of the recipient’s email provider. Specifically, it will confirm the Mail Exchange (MX) records of the recipient’s domain.

Once your email is received by the recipient’s email server, it is stored there until the recipient retrieves it. The storage and delivery of emails is done either through IMAP (Internet Message Access Protocol) or POP3 (Post Office Protocol v3).

The key difference between IMAP and POP3 is that IMAP keeps messages stored on the server so that recipients can access them from multiple devices, while POP3 downloads the messages to store them locally and then deletes them from the server.

When your recipient opens their email client, it will connect to the mail server (either through IMAP or POP3) and retrieve the email to display it for reading.

Without SSL/TLS encryption, there are multiple points in the process at which an attacker could intercept or compromise the email being transmitted.

These include:

When your email client connects to your SMTP to transmit the email, if the SMTP server is not encrypted, it is possible for someone on the same network (such as unencrypted public Wi-Fi) to perform a Man-in-the-Middle (MITM) attack and intercept the message.

When it comes time for the SMTP to forward the email to the recipient’s server, the email will travel across multiple networks and routing points. If there is a lack of SSL encryption between these mail servers, the email will be transmitted in plaintext and can be seen or even modified by anyone monitoring the network.

Attackers achieve this with packet-sniffing tools that allow them to monitor data as it flows through the internet. 

In the same way that emails are vulnerable between your client and your mail server, the reverse is true when your recipient’s mail server receives the email. Once their email server receives the message, your recipient’s client will retrieve it either via IMAP or POP3. 

Regardless of which protocol is used, if this connection is not encrypted, the received message will be transmitted in plaintext, allowing any unauthorised person monitoring the network to see/alter the information.

SSL/TLS protects emails the same way that it protects data transmitted between websites and users. This is achieved through the SSL/TLS handshake. You can learn the specifics of this process and the encryption algorithms in our guide to SSL/guide to TLS, but here is a basic summary of what happens when the handshake takes place on email servers:

When sending an email, the client (e.g., Outlook, Gmail) connects to the mail server using SMTP (Port 465 or STARTTLS on Port 587). When receiving an email, the client connects to IMAP (Port 993) or POP3 (Port 995).

In either situation, the client requests encryption by listing supported TLS versions and cipher suites.

At this stage, the mail server responds to the client using the selected encryption method (such as AES-256) and its installed SSL/TLS certificate. If the certificate is expired, revoked, or from an untrusted Certificate Authority (CA), the connection will be rejected.

Once the SSL/TLS certificate is verified by the email client, a secure session key is established. This key encrypts the data transmitted between the client and the server. 

At this point, the secure session is closed, and the session key is discarded. This means that a new SSL/TLS handshake would be required for any new connections.

When learning about SSL in email, you will inevitably come across S/MIME email certificates.

S/MIME (Secure/Multipurpose Internet Mail Extensions) is a cryptographic standard that is used to:

The first point may be a bit confusing since we’ve already established the benefit of SSL/TLS certificates in encrypting email communication. However, the key difference is that S/MIME certificates encrypt the individual emails themselves, while SSL/TLS certificates only encrypt the connection between the email client and server.

So, while SSL/TLS is effective for protecting emails from attackers during transmission, if an attacker gains access to the email server or client inbox, they would still be able to read the message. 

With a S/MIME certificate installed, an attacker would be unable to read email messages even if they have accessed the inbox or mail server. This is because the only way to decrypt the email requires the private key, which is stored securely on a local device or secure key store (rather than on the compromised email server).

Like with code signing certificates, the main benefit of digitally signing emails with S/MIME is that it assures they have not been altered in any way and that they have truly come from the claimed sender. 

But how does this work?

Using a cryptographic hashing algorithm like SHA-256, the email is given a unique hash (fingerprint) that’s encrypted by the private key. When the email is sent, the recipient’s client will retrieve the sender’s public key from the S/MIME certificate attached to the email, decrypting the hash and checking if it matches.

If it matches, the email is verified as authentic and unaltered. If it does not match, the email will be flagged as untrusted within the recipient’s email client.

You can find more details on this process in our article on SHA-256 and how hashing works.

Since S/MIME encrypts the content of individual emails, it begs the question: Why would SSL/TLS still be important in protecting them during transmission?

While it’s true that an S/MIME encrypted email can’t be read or altered by an attacker, S/MIME still has some limitations that make it necessary to use it in conjunction with traditional SSL/TLS encryption:

So, while S/MIME protects the body content (including attachments) of emails, there are still other vulnerabilities that you need to cover with SSL/TLS encryption.

While taken for granted by most people who send emails every day, SSL/TLS forms a vital part of why we trust and rely on email communication in both our professional and personal lives.

However, for any person or organisation that needs complete assurance of the integrity of their email correspondence, a combination of SSL/TLS and S/MIME is a must. While SSL/TLS encryption of the connection between mail servers and clients is a default expectation of all modern email platforms, S/MIME goes the extra mile in providing peace of mind that the integrity of individual emails is protected no matter who has access to the server or client.