With billions of people all over the world sending emails every day, you might think that email is a secure way of communicating. Unfortunately it is not, as email has major 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 the way that email works. These allow attackers to read and manipulate email messages and abuse other (company's) email domains for fraud. I will not 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".
With normal mail, you can write anyone's name and address as sender on a postcard. The postal service does not verify the sender's identity and will just deliver the postcard to the recipient. Your postcard will be handled by multiple people, who could potentially read and change its content. The same applies to email. Unfortunately some people exploit this by sending Unsolicited Bulk Email (UBE, aka spam) or try to commit fraud, abusing a legit company's domain name. Domain owners can (and should) take precautions to avoid this.
People and businesses receive emails with invoices for all kinds of services and products these days. An attacker could intercept these emails and change invoice information like bank account numbers. Without proper security set up, 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. By the time the invoice reminders flow in, and the fraud is detected, the money will be long gone. You should never blindly trust the "From" field, nor the rest of an email message.
Sender Policy Framework (SPF) offers some solution for this. It is a mechanism that allows domain owners to explicitly authorize the hosts (mail servers) that are allowed to send email on their behalf. Cooperating mail servers can verify this and process a received message accordingly (deliver, mark as spam or reject).
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.
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 both SPF and DKIM fail. You can also specify a destination for aggregated (rua) and failure (ruf) reports. This allows you to monitor if your SPF and DKIM is configured and working correctly and to see who is trying to send email on your behalf.
Authenticated Received Chain (ARC) tries to solve an issue that both SPF and DKIM can cause when 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 indeed legitimate and avoid unintentional rejection.
When a server wants to deliver an email message, it looks up the destination server by requesting the MX records using DNS. A 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 named SMTP. This communication can be done in plain-text, allowing someone to intercept the communication to read and manipulate data (man-in-the-middle (MiTM) attack). The solution for this is encrypting the communication. When two mail servers support encryption (STARTTLS), their insecure connection is opportunistically upgraded to a secure one. In order to make that upgrade, the two mail servers ask each other if they support STARTTLS. Since this initial negotiation is unencrypted, network attackers can alter these messages to make it seem like neither server supports STARTTLS, causing any emails to be sent unencrypted.
DNS-Based Authentication of Named Entities (DANE) blocks these kind 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.
SMTP MTA Strict Transport Security (MTA-STS) is similar to DANE, in that it is also designed to avoid downgrade attacks and verify the destination. In contrast, MTA-STS relies on certification authorities (CAs) and does not require DNSSEC. It does however require trusted certificates. Implementation is a bit harder for mail servers too, because they have to retrieve and cache the MTA-STS policies using HTTPS. More about MTA-STS can be found in my blog here.
STARTTLS Everywhere is a project that launched in June 2018 and publishes a 'preload list' of mail servers that support STARTTLS. It's like the HSTS preload list that is used for HTTPS websites. 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 another point of reference 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.
When you enable SMTP TLS Reporting (TLS-RPT), you will 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 to both detect potential attacks and 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 it is hard to read by humans. That is why we have made URIports. By configuring URIports as your report destination, we automatically process your reports and provide you with an intuitive interface so that you can easily manage and analyze the data.
Does your domain have proper email security?
Hardenize is a website that allows you to check if your domain has correctly implemented DANE, MTA-STS, TLS-RPT, SPF and DMARC.
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 let's you know if your configuration is (still) working correctly, and if urgent matters need your attention. These techniques for securing email are fairly new and not widely adopted yet, but hopefully we'll get there in the near future.