Email security explained

With billions of people worldwide sending emails every day, you might think that email is a secure way of communicating. But unfortunately, it is not, as email has significant security flaws that people have been trying to solve for quite some time now.

Aside from phishing emails and malicious attachments like viruses and malware, there are also some technical flaws in how email works. These allow attackers to read and manipulate email messages and abuse other (companys') email domains for fraud. I won't dive too deep into the technical aspects in this blog but want to explain the different types of mechanisms that can be used to protect email from abuse, manipulation, and eavesdropping.

The most common mechanisms for securing email are SPF, DKIM, DMARC, ARC, DANE, MTA-STS, STARTTLS Everywhere, and TLS-RPT. I will divide the security issues they solve into two groups: email forgery and unsafe transport.

Email forgery

With regular mail, you can write anyone's name and address on a postcard as the sender. The postal service doesn't verify the sender's identity and will deliver the postcard to the recipient. As a result, multiple people will handle your postcard who could potentially read and change its content. The same applies to email. Unfortunately, some people exploit this by sending Unsolicited Bulk Emails (UBE, aka spam) or trying to commit fraud, abusing a legit company's domain name. Domain owners can (and should) take precautions to avoid this.

Example

People and businesses receive emails with invoices for all kinds of services and products. An attacker could intercept these emails and change invoice information like bank account numbers. Without a proper security setup, the recipient will not know the message was altered or came from a different source and will potentially transfer money to the wrong account number. The money will be long gone by the time the invoice reminders flow in, and the fraud is detected. Therefore, you should never blindly trust the From field or the rest of an email message.

SPF

Sender Policy Framework (SPF) offers some solutions to this. It is a mechanism that allows domain owners to explicitly authorize the hosts (mail servers) to send emails on their behalf. Cooperating mail servers can verify this and process a received message accordingly (deliver, mark as spam, or reject).

DKIM

DomainKeys Identified Mail (DKIM) lets you claim responsibility for an email message. It digitally signs an email with a signature that receiving mail servers can verify. Any alterations to the message during transit would result in a verification failure. DKIM does NOT encrypt the message itself; it only adds a signature header to the email. The message can still be intercepted during transport (more about this below) or read when stored in plain text on servers.

DMARC

Domain-based Message Authentication, Reporting, and Conformance (DMARC) allows you to communicate message handling and reporting policies to cooperating servers. A DMARC policy allows you to tell the receiving server what to do when SPF and DKIM fail. You can also specify a destination for aggregated (rua), and failure (ruf) reports. This allows you to monitor whether or not your SPF and DKIM are configured and working correctly and to see who is trying to send emails on your behalf. DMARC also checks if the SPF and DKIM domains align with the Header From address domain.

ARC

Authenticated Received Chain (ARC) tries to solve an issue that SPF and DKIM can cause when an email is not directly sent from sender to recipient but is forwarded to another address or multiple addresses. This causes DKIM to fail because the email headers are being altered, and because the message is now sent from a different server, SPF will fail too. So, although the message is legit, it may not get delivered. ARC preserves authentication by adding headers with the initial SPF/DKIM/DMARC results and a signature of the original headers. Mail servers with ARC support can use these added headers to verify that the message is legitimate and avoid unintentional rejection.

Unsafe transport

When a server wants to deliver an email message, it looks up the destination server by requesting the MX records using DNS. A so-called man-in-the-middle (MiTM) attacker could manipulate this data and respond with a different destination address, allowing the attacker to intercept the data on a different server before sending it to the domain's actual mail server.

Email messages are transferred using a protocol called SMTP. This communication can be done in plain text, so anyone who intercepts the communication (in a MiTM attack) can read and manipulate the data. The solution for this is to encrypt the communication. When two mail servers support encryption (STARTTLS), their insecure connection is opportunistically upgraded to a secure one. The servers ask each other if they support STARTTLS. Since this initial negotiation is unencrypted, network attackers can alter these messages to make it seem as if neither server supports STARTTLS, causing any emails to be sent unencrypted.

DANE

DNS-Based Authentication of Named Entities (DANE) blocks these kinds of attacks. By publishing a (TLSA) DNS record, you instruct cooperating mail servers to expect encrypted communication and verify the destination's certificate. If no encrypted channel can be set up, the messages will not be sent. DANE works with self-signed certificates but requires DNSSEC. Unfortunately, DNSSEC deployment and validation support is only around 15% worldwide.

MTA-STS

SMTP MTA Strict Transport Security (MTA-STS) is similar to DANE in that it's also designed to avoid downgrade attacks and verify the destination. In contrast, MTA-STS relies on certification authorities (CAs) and doesn't require DNSSEC. It does, however, require trusted certificates. In addition, implementation is harder for mail servers because they have to retrieve and cache the MTA-STS policies using HTTPS. You'll find more about MTA-STS here in my blog.

STARTTLS Everywhere (discontinued)

STARTTLS Everywhere is a project that publishes a preload list of mail servers that support STARTTLS. It's like the HSTS preload list that HTTPS websites use. If your mail server supports STARTTLS, uses a secure version of TLS, and has a valid, trusted certificate, you can add your domain to this list here. The STARTTLS Everywhere policy list gives mail servers an additional reference point to discover whether other mail servers support STARTTLS. Another neat feature of STARTTLS Everywhere is that they send notifications when they notice issues with your mail server.

UPDATE April 2020: The STARTTLS Everywhere project has been discontinued as email providers did not widely adopt the service, and solutions MTA-STS and DANE are good alternatives.

TLS-RPT

When you enable SMTP TLS Reporting (TLS-RPT), you receive daily reports from external mail servers that connect to your domain. These reports have information about any connection problems the external servers find when sending mail to your domain. This information can be used both to detect potential attacks and to diagnose unintentional misconfigurations.

Keeping track of reports

Both DMARC and TLS-RPT can be used to receive a lot of valuable information in the form of reports. Although these reports contain a lot of data, most of them are hard for humans to read. That's why we created URIports. With URIports configured as your report destination, we automatically process your reports and provide you with an intuitive interface to easily manage and analyze the data.

Does your domain have proper email security?

Hardenize is a website that allows you to check whether DANE, MTA-STS, TLS-RPT, SPF, and DMARC have been correctly implemented in your domain.

Conclusion

Increasing efforts are being made to make email more secure. By setting up DKIM, SPF, and DMARC, you can minimize the risk of people abusing your domain and manipulating the content of your email messages. Avoid MiTM downgrade attacks on your mail server by setting up MTA-STS and DANE. Adding DMARC and TLS-RPT reporting using URIports lets you know whether your configuration is (still) working correctly and if urgent matters need your attention. These techniques for securing email are relatively new and not widely adopted yet, but hopefully, we'll get there soon.