Email security standards
Email is still the most widely used form of communication between businesses, partners and customers. Often, e-mail is necessary for the functioning of certain business processes such as invoicing or sending an order confirmation when an order is placed. It is therefore important that a recipient actually receives an e-mail and can assume that it actually comes from your organisation. To ensure this, we use e-mail security standards.
Why are there email security standards?
Email is a widely used communication form that many organisations depend on. Most organisations use their own email domain so that email addresses are recognisable and traceable. But email is not the most secure and reliable form of communication. Without additional setup in your email environment, you run the following risks:
- It is fairly easy to 'spoof' your organisation's email domain. This means that someone can send emails pretending to come from your business. Phishing attacks have a greater chance of success this way because the recipient (wrongly) trusts the sender's email address. Employees within your own organisation as well as other recipients can become victims of this;
- The incorrect use of email security standards can prevent emails sent by your organisation from being trusted by the receiving email environment. Depending on how strict the receiving mail server is set up, the emails may not reach the recipient or may be marked as ‘spam’;
- The communication between the sending mail server and the receiving mail server is unencrypted, so that the content of email messages is open, and messages can be modified before they reach the recipient.
Email security for businesses
When talking about corporate email security, attention is often paid to protection against phishing, malware, or spam on the receiving end. This is of course important, but corporate email security goes beyond having a good spam filter and training employees to recognise ’wrong’ emails. The risks described above affect the availability, integrity, and confidentiality of emails your business sends. By taking measures against these risks, you also contribute to making email more secure on the part of the recipient.
What can your business do?
It is possible to remotely check which email security standards have been set up. It does not matter if you manage your organisation's email environment or if it is outsourced to an IT service provider. There are several websites on the internet that can easily perform this check. All you have to do is enter the mail domain of your organisation in the appropriate input field.
An example is the email test on the internet.nl website. This email test looks at the most important email security standards. After completing the test, you will receive a report and a score to give you an idea of the status of your email domain. This overview can help you to make adjustments or additions yourself or to start a conversation with your IT service provider. Such a test cannot see everything, but it does give you a good starting point. We briefly describe different email security standards below. It is important to be aware of these standards and consider using them.
Email authentication
The following 3 security standards are used for email authentication. This makes it possible for the receiving party to verify that email from a particular email domain comes from an authorised person. This helps to prevent spoofing and determine whether an email is spam.
Sender Policy Framework (SPF) is a standard that allows you to specify which IP addresses are allowed to send email messages on behalf of your organisation's email domain (and which are not). The information is stored in the so-called SPF-Record of the email domain. This record is read by the receiving mail server via Domain Name System (DNS), the system used on the internet to translate computer names into IP addresses and vice versa. Having an SPF Record increases the trust of the receiving mail server when determining whether your message is spam.
DomainKeys Identified Mail (DKIM) ensures that a 'fingerprint' is added to an email. The receiving mail server uses this fingerprint to determine whether an email is from a trusted mail server and whether the message has been changed during the transport of the email. The fingerprint is based on a certificate of which a receiving mail server can retrieve the public key from a DNS Record of the mail domain. This technique also helps the receiving mail server to decide whether a message is classified as spam.
The SPF and DKIM security standards can be configured separately from each other and offer an improvement in email security in their own right. Domain-based Message Authentication, Reporting; Conformance (DMARC) has been developed to link SPF and DKIM via a policy. It indicates how a receiving mail server should deal with the results of these 2 standards. In addition, you can use the reporting option of DMARC to get an idea of whether abuse is detected by a receiving mail server. If there is such a report of possible abuse, this may also be due to an incorrect configuration of DKIM or SPF, which means that valid emails may not arrive. A DMARC policy is also stored in a DNS record of the mail domain.
Encryption (STARTTLS)
It is important to realise that when you send an email, there is no guarantee that the transport is encrypted. Without encryption, an email to a customer, for example, can be viewed by others. This is probably not a big problem in the case of a newsletter, but there is also a chance that an email contains sensitive (personal) data. This security issue is related to the SMTP protocol, used to send and receive emails between the mail servers. The ability to encrypt this traffic is done through STARTTLS. This is known as ’opportunistic encryption’; you can use it, but it is not necessary. In addition, a lack of proper setup of STARTTLS often results in a lack of validation options. This makes it relatively easy for hackers to prevent an encrypted connection between mail servers or to set up an encrypted connection to the wrong server. In short, STARTTLS unfortunately has shortcomings. It is important to consider a number of topics:
While there are technical solutions that can circumvent the shortcomings of STARTTLS to some extent, these solutions are not yet widely used. In addition, this does not cover the entire transport of email. Even if you are 100% sure that traffic between mail servers runs via STARTTLS with the correct mail servers, the email message can still be found unencrypted on the mail servers through which the message is sent. Because encrypted transport is difficult to guarantee, it helps to make agreements within your organisation about what you will or will not send via email. Think, for example, of social security numbers or passwords.
It is possible for hackers to prevent an encrypted connection or to have an encrypted connection set up with another (wrong) server. These problems can be solved by means of DNS-based Authentication of Named Entities (DANE) by indicating which servers are allowed to receive emails in the DNS of the mail domain via a so-called ’TLSA Record’ , and that email reception must be encrypted. With this technique, however, you are dependent on the receiving party to arrange this for their mail domain.
Most mail servers have the ability to force STARTTLS. However, there is a risk that mails will not arrive if STARTTLS is not supported by the recipient. In practice, this is therefore often only set up between parties who know from each other that STARTTLS is possible.
Businesses can contribute to a safer email environment
When businesses pay attention to setting up your email environment securely on both the sending and receiving side, you automatically contribute to a safer email climate. For more information, see the factsheets on STARTSSL and DANE (in Dutch), and SPF, DKIM and DMARC (in Dutch).
DNSSEC
The aforementioned email security standards rely heavily on information stored in the DNS. Mail servers retrieve this information to, for example, check within the SPF record whether an email comes from a trusted server. To ensure that this kind of information cannot be manipulated within a DNS request, it is important that the DNS Server containing your organisation's email domain supports DNSSEC. In this way you prevent that the email security standards can still be circumvented. The internet.nl email test shows whether DNSSEC is in use.