Common Email Security Protocols That Every Business Should Have

When conducting any form of business, communication is the key factor that will decide whether the relationship becomes a success or a failure. Even with so much technology at our disposal, when it comes to doing business, our preferred form of communication is still the good old face-to-face conversation. 

Of course, this is not always possible in today’s dynamic market. But luckily for us, in 1971, Ray Tomlinson invented and sent the first email message as we know it today. Since then, email has grown to become a crucial way of communication in business. In 2018 alone, 281 billion emails were sent out daily. The predictions are that this will only increase, as shown in this chart:

Understandably, this number might seem huge for the average person – but don’t forget that more than half of emails sent daily are spam. Surprisingly, this number has been decreasing over the past few years. One of the reasons behind this improvement are the ever-evolving security protocols that handle not only spam, but also numerous other issues a message might face before it’s opened by the recipient. 

Explaining the trip that your message makes when you click send and when it appears on the recipient’s inbox might seem easy, but there are certain things that happen without our knowledge. This diagram helps to visualise the process:

The three most used email protocols are SMTP, POP3 and IMAP. The first is the transferring protocol of your message, and the other two are the ones that read it.

SMTP

Simple Mail Transfer Protocol is the protocol responsible for the email transfer between email clients (e.g. Thunderbird, Mailbird, Microsoft Outlook) and email providers (e.g. Gmail, Zoho Mail, iCloud, Yahoo).

Unlike the other two, this protocol can be used only to send emails, and it cannot retrieve them from the server. One of the main hindrances is the lack of email authentication and security, which in turn means that the users will get spam mails.

POP3

Post Office Protocol 3 is used by email clients to retrieve the message from a server. Clients that use POP3 store the message on their user’s computer and delete it from the email server. POP3 also gives users an option to save the message on the server. This protocol was created with the option of deleting, drafting and reading the messages while offline.

IMAP

Internet Message Access Protocol shares many attributes with POP3 but a significant difference is the option of multiple users operating emails at any one time. This is very helpful for businesses that assign communication with customers to different team members. IMAP also stores emails on the server by default with an option of being deleted by the user.

In the next few months, SpotlerCRM will be integrating OAUTH and IMAP into its Email Integration product so it can connect to customers' mail servers more securely.

Now that you have a rough idea of how your email finds its destination, let’s move on to all the security protocols needed to keep your message safe from unwanted eyes and your inbox spam-free.

Digital Certificates

By using digital certificates, you are securing your email cryptographically. Digital certificates are a type of public-key encryption. Encryption is done by applying a mathematical function to a file that renders the contents of the file unreachable to anyone without the proper decryption key. 

The certificate allows you to receive encrypted emails using a predefined key, as well as to send out encrypted messages to other certificate users. In this sense, your Digital Certificate acts as a sort of digital passport, confirming your online identity.

Your public encryption key is available to anyone. A sender will use it to encrypt their message, allowing only you to open that message with your private key. If you are interested in learning more about digital certificates you can check out this YouTube video from Dave Crabbe.

SSL/TLS Protocols

SSL (the Secure Sockets Layer) is the predecessor of TLS (the Transport Layer Security). Both are application layer protocols that provide the security framework that works with SMTP to keep your emails safe. From 2015, SSL was officially deprecated but there still remain an alarming number of websites that support it.

What TLS does is to provide additional security for SMTP and even some other communicating computer programmes. Email clients send and receive messages using TCP (Transmission Control Protocol) to initiate the ‘’handshake’’. The handshake is a series of actions that the email client and server go through to validate security and begin the email transition. 

Forced and Opportunistic TLS

The two possible TLS configuration email servers decide if your message will be sent out or not.

If your configurations are set to “Opportunistic TLS’’, when you send a message your server will try to verify if the receiving server is supporting TLS.

Then if the destination server does support TLS your message will be sent over a secured channel using TLS protocol. 

However, if the destination server doesn’t support TLS the message will be sent anyway over a non-secure channel. The same check happens when your configuration is set to “Forced TLS’’, the only difference being that if the other server is not supporting TLS protocol the message will not be sent.

Sender Policy Framework

Simply put, SPF authorises the use of domains in emails.

One of the main misconceptions about SPF is that it’s responsible for protecting you against spoofing. 

“Spoofing” is the term used for when hackers and spammers mask their malicious emails to appear as messages from healthy domains. To the surprise of many, SPF does not handle the sender’s address – it only verifies emails on the transport level. These addresses are not visible to the user and they may differ from the ones in the “From’’ header that the user does see.

SPF does not protect you from spoofing or spam directly, but it does deploy spam filtering systems. 

Here are two steps explaining how SPF really works:

Set a Policy

The policy is published by the domain administrator, stating which email servers are allowed to send messages from that domain. This policy is also called the SPF record and is included in the Domain Name System (DNS).

Identify The IP

When a message is received, an inbound server will check in the DNS for the return-path. After that, it will compare the IP address with the authorised IP addresses in the SPF record settings. Using the rules from the policy, it will either accept, reject or flag the message.

DKIM/DMARC

Domain Keys Identified Mail and Domain-Based Message Authentication, Reports & Conformance, together with SPF, form the holy trinity of email delivery.

DKIM is another protocol that helps keep your email safe in transit. Being an extension of SPF, it checks from which domain the message was sent and whether the domain authorised the sending. It does this by using digital signatures. 

DMARC is the key element in the email security protocol, as it requires both SPF and DKIM to fail, after which it will act on a certain message. It also has a policy that is published alongside your DNS record. If configured properly, the DMARC policy can tell the receiving server how to handle the incoming message, unlike SPF and DKIM.

This is done by matching the “From’’ header domain name and the “Envelope from’’ domain name that was gathered by SPF, after which it does the same with the DKIM signature. If the SPF check and/or DKIM authentication fails, the message is rejected.

MTA/STS

One of the recent improvements in email security protocols, MTA/STS enables a secure encrypted transfer of messages between SMTP servers. 

For the Mail Transfer Agent-Strict Transport Security protocol to be implemented, the DNS policy must specify that the server can fetch a policy file from a certain sub-domain. When the policy is fetched by HTTPS, it will contain an authenticated list of the recipients’ servers. 

The problem of server connection encryption might be solved, but attackers can still access the server itself and see the valuable information. This problem can only be solved by implementing an end-to-end encryption method.

End-To-End Encryption 

Although it might function similarly to SSL, TLS, and SMTP, this type of encryption is different in one crucial aspect, no-one can see the message at any point in the process until it’s decrypted.

This might seem perfect, and you might wonder why aren’t we all using end-to-end encryption, but it’s not that simple. Mainstream providers have no interest in promoting or providing this service as almost all of them depend on advertising and gathering data. Still, there are some that do support end-to-end encryption, like Mailfence.com  and Protonmail.com

Conclusion

Since the 2004 email data fiasco with Jason Smathers, it’s clear that we have to protect our privacy more than ever. Many other information and data breaches have accrued since then, showing that an average cost of a stolen record with confidential or sensitive information is $221 in the US. 

But the cost goes up when you start to consider the loss of customers and the terrible publicity your company will receive. With email being used by almost every business and customer, we can’t underestimate how important these security protocols are.