What is Email Security?

Email security is the process of ensuring the availability, integrity, and authenticity of email communications by protecting against the risk of email threats. Email enables billions of connected people and organizations to communicate with one another to send messages.

Why Is Email Security Important?

Email is a prime target for cyber attackers due to vulnerabilities that are deeply rooted in human error, as well as the nature of the information that is shared on it. According to data published by PurpleSec in their 2021 Cyber Security Statistics report, a staggering 92% of all malware is delivered via email. What is more, targeted spear-phishing campaigns are the leading cause in 91% of successful data breaches, affecting 95% of all enterprise networks.

In today’s digital world, email security is a must for any company’s cybersecurity infrastructure. But why? Below, we have detailed the five key reasons why you need to consider it for your enterprise and illustrated each point with relevant statistics.

Message format

The basic Internet message format used for email is defined by RFC 5322, with the encoding of non-ASCII data and multimedia content attachments defined in RFC 2045 through RFC 2049, collectively called Multipurpose Internet Mail Extensions or MIME. The extensions in International email apply only to email. RFC 5322 replaced the earlier RFC 2822 in 2008, then RFC 2822 in 2001 replaced RFC 822 – the standard for Internet email for decades. Published in 1982, RFC 822 was based on the earlier RFC 733 for the ARPANET.

Internet email messages consist of two sections, ‘header’ and ‘body’. These are known as ‘content’. The header is structured into fields such as From, To, CC, Subject, Date, and other information about the email. In the process of transporting email messages between systems, SMTP communicates delivery parameters and information using message header fields. The body contains the message, as unstructured text, sometimes containing a signature block at the end. The header is separated from the body by a blank line.

Message header

RFC 5322 specifies the syntax of the email header. Each email message has a header (the “header section” of the message, according to the specification), comprising several fields (“header fields”). Each field has a name (“field name” or “header field name”), followed by the separator character “:”, and a value (“field body” or “header field body”).

Each field name begins in the first character of a new line in the header section and begins with a non-whitespace printable character. It ends with the separator character “:”. The separator is followed by the field value (the “field body”). The value can continue onto subsequent lines if those lines have space or tab as their first character. Field names and, without SMTPUTF8, field bodies are restricted to 7-bit ASCII characters. Some non-ASCII values may be represented using MIME encoded words.

Header fields

Email header fields can be multi-line, with each line recommended to be no more than 78 characters, although the limit is 998 characters. Header fields defined by RFC 5322 contain only US-ASCII characters; for encoding characters in other sets, a syntax specified in RFC 2047 may be used. In some examples, the IETF EAI working group defines some standards track extensions, replacing previous experimental extensions so UTF-8 encoded Unicode characters may be used within the header. In particular, this allows email addresses to use non-ASCII characters. Such addresses are supported by Google and Microsoft products and promoted by some government agents.

The message header must include at least the following fields:

• From: The email address, and, optionally, the name of the author(s). Some email clients are changeable through account settings.
• Date: The local time and date the message was written. Like the From field, many email clients fill this in automatically before sending. The recipient’s client may display the time in the format and time zone local to them.

Encryption protocols

With the original design of email protocol, the communication between email servers was in plain text, which posed a huge security risk. Over the years, various mechanisms have been proposed to encrypt the communication between email servers. Encryption may occur at the transport level (aka “hop by hop”) or end-to-end. Transport layer encryption is often easier to set up and use; end-to-end encryption provides stronger defenses but can be more difficult to set up and use.

Transport-level encryption

One of the most commonly used email encryption extensions is STARTTLS. It is a TLS (SSL) layer over plaintext communication, allowing email servers to upgrade their plaintext communication to encrypted communication. Assuming that the email servers on both the sender and the recipient side support encrypted communication, an eavesdropper snooping on the communication between the mail servers cannot use a sniffer to see the email contents. Similar STARTTLS extensions exist for the communication between an email client and the email server (see IMAP4 and POP3, as stated by RFC 2595). STARTTLS may be used regardless of whether the email’s contents are encrypted using another protocol.

The encrypted message is revealed and can be altered by, intermediate email relays. In other words, the encryption takes place between individual SMTP relays, not between the sender and the recipient. This has both good and bad consequences. A key positive trait of transport layer encryption is that users do not need to do or change anything; the encryption automatically occurs when they send an email. In addition, since receiving organizations can decrypt the email without the cooperation of the end-user, receiving organizations can run virus scanners and spam filters before delivering the email to the recipient. However, it also means that the receiving organization and anyone who breaks into that organization’s email system (unless further steps are taken) can easily read or modify the email. If the receiving organization is considered a threat, then end-to-end encryption is necessary.

The Electronic Frontier Foundation encourages the use of STARTTLS, and has launched the ‘STARTTLS Everywhere’ initiative to “make it simple and easy for everyone to help ensure their communications (over email) aren’t vulnerable to mass surveillance.” Support for STARTTLS has become quite common; Google reports that on Gmail, 90% of incoming emails and 90% of the outgoing email were encrypted using STARTTLS by July 24, 2018.

Mandatory certificate verification is historically not viable for Internet mail delivery without additional information, because many certificates are not verifiable and few want email delivery to fail in that case. As a result, most email that is delivered over TLS uses only opportunistic encryption. DANE is a proposed standard that makes an incremental transition to verified encryption for Internet mail delivery possible. The STARTTLS Everywhere project uses an alternative approach: they support a “preload list” of email servers that have promised to support STARTTLS, which can help detect and prevent downgrade attacks.

End-to-end encryption

In end-to-end encryption, the data is encrypted and decrypted only at the endpoints. In other words, an email sent with end-to-end encryption would be encrypted at the source, unreadable to service providers like Gmail in transit, and then decrypted at its endpoint. Crucially, the email would only be decrypted for the end-user on their computer and would remain in the encrypted, unreadable form to an email service like Gmail, which wouldn’t have the keys available to decrypt it. Some email services integrate end-to-end encryption automatically.