Securing Email for Production

The history of email is long and arduous. Like many components of the interconnected world we live in, it has evolved gradually to fit a need; from humble beginnings as a tool to send notes to others on a single mainframe, it has now become a powerful medium that replaces the printed letter. Unfortunately, email out-of-the-box is a little rough around the edges. This addition to our public technical library is designed to give you a basis to scrutinize your implementation of email in a production environment.

How does sending an email work?

When a sender composes a message, behind the scenes they are composing two artifacts: a set of header fields (such as Subject, From, To and Date just to name a few) and a message body consisting of the text that was composed. When the message is sent, the client uploads the headers and body and it is presented to the receivers mail server, either directly, or passed like a hot potato through a series of mail servers until finally reaching its destination.

Upon arrival, the message headers (remember, these are originally set by the senders’ client) are used to show the reader information such as who it’s from (in the From header) and when it was sent (in Date). Because this information is set by the senders’ client, it is trivial and common for a spammer or hacker to send emails with the From field displayed as e.g. “bob@yourcompany.com”, even though Bob really had nothing to do with it. When one of your contacts sees that Bob has sent them an excellent (fraudulent) business opportunity, they may be far less reluctant to become involved.

This is a practice called “email spoofing” (or the “forged sender address” problem) and fortunately there are ways that you can configure your infrastructure to protect against it.

SPF: Sender Policy Framework

SPF is the oldest of the mechanisms designed to prevent email spoofing. It was first specified in 2006 with RFC 4408 and is designed as a lightweight technique to allow receiving mail servers to determine if the sender mentioned in the ‘From’ field is legitimate.

It accomplishes this by comparing the addresses of the senders’ mail servers with a list of valid addresses that are provided by the sender as part of their SPF configuration. The SPF configuration is defined at a domain level, using TXT records in the DNS information of the senders’ domain (so they are more authoritative than just the headers in the email). In this manner, no extra configuration is required on each the senders’ mail servers.

The lack of these records can be attributed to many common email problems, such as delayed delivery (we noticed up to half an hour) or outgoing emails immediately landing in spam folders. Fortunately, for most hosted email providers the configuration is simple. The OnRock Engineering team uses G Suite for email, so our DNS records for SPF were directly provided by Google and look like the following:

onrock.engineering. 300 IN TXT “v=spf1 include:_spf.google.com ~all”

To briefly explain the different parts of this record, the v=spf1 part specifies the version, whilst include:_spf.google.com references the G Suite mail servers and ~all defines the mechanism to use for accepting/rejecting mail (the strictest is actually -all). On a bash shell you can test your own domains for the presence of an SPF record by customizing and executing the following command:

$ dig onrock.engineering TXT

If you are using Microsoft Exchange or Office365, documentation is also provided on setting up SPF records correctly.

DKIM: DomainKeys Identified Mail

Modern DKIM was specified by RFC 4871 in 2007, which describes a method of signing email body and header validity using public/private key (RSA) cryptography. DKIM is another method designed to prevent sender spoofing, but rather than the lightweight method used by SPF, it requires some support by the sender.

Messages sent with correctly configured DKIM support will contain a DKIM-Signature field, which specifies the headers that will be hashed. Then, the hashes of the message body and specified headers are included with the email, and the public key specified by the domains DKIM configuration can be used to verify that the body and headers have not been maliciously altered. This provides a stronger guarantee of the senders authenticity than can be provided by just SPF (physical server addresses are actually very easily spoofed at a network level).

DKIM public keys are stored as TXT records in the DNS information of the domain associated with the senders email address. DKIM records require mail server support, so you should use the DKIM configuration options provided by your mail server host. The record name would typically be specified with a prefix e.g. prefix._domainkey. For OnRock Engineering we used the G Suite wizard with the prefix google and the record looks something like this (key size trimmed):

google._domainkey.onrock.engineering. 300 IN TXT “v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFA…0lOiiPzHSJix2QIDAQAB”

On a bash shell you can find the full output yourself using this command, which you could customize to determine whether your current email domain is configured if you knew the prefix:

$ dig google._domainkey.onrock.engineering TXT

Similarly, if you are using Microsoft Exchange or Office365, they also provide instructions on how to configure DKIM.

DMARC: Domain Message Auth, Reporting and Conformance

DMARC is specified by RFC 7489 and represents a very recent advancement in email spoofing prevention, dating earliest development in about 2011. DMARC doesn’t actually describe a new message signing technology; rather, it builds on the existing SPF and DKIM technologies to allow domain owners to specify how rejected mail should be handled.

Specifically, having a DMARC record present on your domain tells other servers that your SPF and DKIM records are correctly configured, and specifies your intention to enforce the given policy if any of these fail to authenticate; either none (that is, do nothing), quarantine (treat the message with suspicion) or reject (decline to receive the message). Other functionality of DMARC includes the ability send aggregate reports (rua) and forensic/realtime reports (ruf) to the recipients specified in the record, which provides you with useful details for validating your setup.

DMARC records are stored as TXT records in the DNS information of the domain associated with with the senders email address and will always appear under the record name _dmarc.example.com where example.com is your domain. This is the record for OnRock Engineering, configured using the documentation provided by G Suite:

_dmarc.onrock.engineering. 300 IN TXT “v=DMARC1; p=reject; rua=mailto:postmaster@onrock.engineering, mailto:dmarc@onrock.engineering”

This configuration is comprised of the parts v=DMARC1, specifying the version of the DMARC specification to use, p=reject specifying the policy (other values include none and quarantine), rua=postmaster@example.com to specify who should receive daily aggregate reports, and in this instance no configuration is provided for forensic reports (because these can be pretty spammy). The gist of this configuration is that emails failing either SPF or DKIM will be rejected and daily reports will be sent to the two emails listed.

On the bash shell you may reproduce the above result or modify the following command to query the DMARC records of different domains to see how they are configured:

$ dig _dmarc.onrock.engineering TXT

Microsoft Exchange and Office365 also provide instructions for enabling DMARC validation.

Phishing Awareness

Ultimately though, human error is to blame for most security breaches, and the case is especially true of email where a popular form of infiltration is phishing. Although you may have secured your organizations’ email so that it is not possible to e.g. imitate a director or project manager directly, it may still be possible for people with malicious intent to produce a convincing email that could actually bring your employees to a malicious web site.

There is no shortage of advice on the internet on how to identify a phishing scam. It is important that you make it regular practice to provide education for your employees on how they can identify these scams and whom they should notify if they have become a phishing target.

Quad9 is a project that, in partnership with IBM, provides a free public DNS service using real time threat intelligence that is capable of automatically blocking some malicious domains, and hence some forms of email propagating malware. Configuring your network or workstations to use these servers could provide an additional layer of protection against phishing attacks designed to spread autonomously via malware, but will provide little or no protection against a cunning human infiltrator.

Bulk Emailing

Bulk emailing is a powerful marketing tool, however its widespread adoption has led to a global spam war; an arms race of spam and anti-spam technology. Not only is there a market in bulk emailing, but there is also an economy built on top of extortion by certain less-than-legitimate anti-spam databases. If you are unfortunate enough to find that your users don’t agree on the value of your content, you may be looking down the barrel of steep fees and convoluted, time consuming paperwork.

Typically there are two kinds of spam databases; those that operate on the principle of blacklisting the offending mail server, and those that operate on the principle of blacklisting the domain associated with the email address of the sender. If your business relies on email for day-to-day work, it might be a good idea to segregate your bulk emailing from your normal communications, both at a server level and a domain level. One way to accomplish the former would be to use a separate domain for your mailing lists and outsource delivery to a bulk emailing service like Mandrill. Many of these services support full SPF, DKIM and DMARC configurations and are financially invested at-scale to ensure that your email arrives (in order to keep your business).

You can check the sender score (higher scores imply mail is considered more legitimate) of these services by determining the email address band of their delivery servers (in this instance, one of the boxes in the 205.201.128.0/20 band), reversing them and inserting them into the query as below:

$ dig a 1.128.201.205.score.senderscore.com
..
1.128.201.205.score.senderscore.com. 9 IN A	127.0.4.98

The response returned indicates a very healthy score; 98 out of a possible 100. How about your domain and mail servers? If you are suffering from a poor sender score or a miserable delivery rate, Google has published an extensive list of technical guidelines for bulk senders that go into further detail on current best practices.

Conclusion

We hope that you have found this publication interesting. If you learnt something new today, would like to show your appreciation or have ideas about how we can improve the quality of our public technical library, please feel free to leave a comment here or write directly to our publishing team, publishing@onrock.engineering.