Securing your corporate e-mail system

The problem with e-mails

Electronic mail has been around for the over 40 years — and today it is so ubiquitous few of us ever wonder how it works. Like most of the scientific and technological innovations that underpin our modern life, we expect it to just do its job. We learned to live with its quirks, and to handle the thousands of unwanted, irrelevant and potentially malicious e-mails that magically appear every day in our inbox. Countless man-hours were invested into ever more sophisticated solutions to this problem: to filter out spam and to warn users about phishing attempts. Today, users of reputable e-mail providers got used to the fact that when something lands in their inbox, it is most likely legitimate — making e-mails slipping through even more dangerous.

The source of all these spam-related woes is sender fraud. When the protocols and standards for e-mail were first developed, few expected it to be used by billions of people on a daily basis. As such, there is no reliable way to tell who actually sent a message. It is much like good old physical snail mail — the name is on the envelope, but that’s it. Since sending e-mails costs virtually nothing and can be done from the safety of a far away country, there is little risk or financial investment involved. A solution was needed, but the fundamental nature of e-mail could not be altered, so it had to be an addition to the existing standards.

E-mail, meet DNS

Say you want to send an e-mail to first.last@example.com. Here is how it works:

1. You write your message in a Mail User Agent (MUA), a nice interface that lets you type, format and address your e-mail — think Outlook or Gmail. Once you are finished, the MUA will put it in an envelope, adding all kinds of other information (identifying you as the sender, among other things), then submit it to a Mail Submission Agent (MSA). An MSA only accepts e-mails from authenticated users, so your MUA will have to prove that you are indeed who you claim to be. If you are using a desktop application to send and receive e-mail, you most likely had to log in at some point — the MUA stores those credentials in some form, and will reuse them every time you send a message to identify you to the MSA. For web clients, this process is invisible and happens in the background.
2. Once authenticated, the MSA will inspect the message and accept it if it passes the checks. These checks can include, among other things, a check for the sender address: you have authenticated yourself as a specific user, you should only be able to send e-mails from addresses that belong to that user. After the checks, the MSA will hand over your mail to a local Mail Transfer Agent (MTA).
3. The local MTA looks at the destination e-mail address and checks if it is local — an e-mail address that belongs to someone in the same organization, and where the MTA can deliver it immediately. Since it is not a local address, it will have to figure out how to deliver it. To do that, it looks at the domain part of the e-mail — example.com, in our case. It sends a query to a Domain Name System (DNS) server, essentially asking: “I have an e-mail for someone under the domain example.com, where should it be delivered?”. The answer to this question is a matter of public record, and the DNS server will return with an answer — “Mail should be sent to 175.45.177.43”. The local MTA will then open a connection to 175.45.177.43, and hand over the message for delivery to the remote MTA.
4. The remote MTA also looks at the destination e-mail address and checks if it is local — if it wasn’t, it would either be forwarded to another MTA (if there is a local rule in place) or rejected (since the remote MTA cannot deliver it). If accepted, the remote MTA hands it over to its associated Mail Delivery Agent (MDA).
5. The MDA stores the e-mail for later retrieval by the addressee.
6. The user who owns first.last@example.com will eventually open a MUA, which will download new messages from the mailbox (after authentication, in most cases), completing the process.

Please note that the role of MSA, MTA and MDA are often integrated to some degree, and may in fact be implemented by the same software performing the functions of all three roles for a domain. If we look at this workflow, we can see that some checks are present even in this simplified version:

• The MSA only accepts messages from an authenticated user that belongs to the organization
• The MSA checks if the user can send e-mails with the specified sender address

Since anybody can run an MTA, the checks performed by the MSA to prove that you are indeed who you are and can send messages with the specified sender e-mail address are essentially worthless. To fix that, a few additional steps were introduced to the e-mail delivery workflow. These checks work by asking the DNS server for additional information, letting the owners of a domain specify not only how e-mails to that domain should be delivered, but also how e-mails sent from an address that belongs to that domain can be validated to have come from an authorized sender. Such validations are usually performed by the remote MTA or the MDA.

Sender Policy Framework (SPF) checks

SPF works by specifying which servers are allowed to hand over mail that claims to be from the domain. If the mail server at 175.45.176.2 wants to check if another mail server at 175.45.177.43 is allowed to send a message that claims to be from first.last@example.com, it can query a DNS server for the SPF record of example.com, which will specify which servers are allowed to do so.

There is a problem, however. An e-mail under delivery contains more than one address that may mark who the sender is:

• The From field contains the people who wanted the message to be sent
• The Sender field contains a single person who actually sent the message
• The Resent-From and Resent-Sender fields may be added when an e-mail is forwarded to another address (in practice, these are rarely used)
• Replies to the e-mail should be sent to the address in the Reply-To field
• Delivery errors (bounced e-mails) should be sent to the address specified in the Return-Path field

These fields are stored in the headers section of the e-mail, which is not directly shown to users but some of the values they contain are used at various parts of the user interface:

In a simple e-mail, it is quite possible that Sender, Resent-From, Resent-Sender and Reply-To are missing and From is the same as Return-Path — but for e-mails that go through mailing lists, are routed through multiple servers or have advanced error detection for delivery failures, these addresses might all be present and quite different. Since each of these addresses can be for a different domain, one had to be chosen for SPF. The standard designates Return-Path — unlike other fields, it is not part of the original message, but appended by the receiving mail server based on who the sender mail server claims the message is from. There are many problems with this approach: the Return-Path is usually not displayed on the user interface of mail clients and it does not have to have any connection with the actual person sending the e-mail. Nonetheless, if configured correctly, SPF at least validates one address — even if not the most useful one.

DomainKeys Identified Mail (DKIM) checks

DKIM took a very different approach — it added a digital signature to the message that proves, among other things, that it has not been tampered with. When a message is sent, the MSA signs the message before passing it to the local MTA. Since the MSA has authenticated the user sending the message, at this point it has proof that the message is by an authorized sender. On the receiving end, the MDA can verify the signature and reject any e-mails with invalid signatures.

Digital signatures use two keys: a public key and a private key. The private key is used to sign data, the public key can be used to verify that the data is signed. For DKIM, the private key is managed by the MSA, while the public key is published through DNS for clients to retrieve. When an MDA receives a message, it looks at its DKIM signature — it contains a domain name that can be used to retrieve the public key. A verified signature means that whoever owns this domain name has claimed responsibility for the message.

Since according to the standard, the domain designated by the signature does not need to be the same as the one used by any of the addresses in the aforementioned fields, we haven’t gotten closer to verifying that the e-mail is legit. But now we have cryptographic proof linking the contents of the e-mail and its claimed sender to a domain. Unfortunately, if no DKIM signature is present, there is no way to tell if the message should be signed in the first place — since the domain which the message should be validated against is only specified in the signature itself, it is impossible to decide if an unsigned message is valid or not.

Domain-based Message Authentication, Reporting and Conformance (DMARC) checks

SPF and DKIM are pieces of the puzzle, but they are not enough. An e-mail that claims to be from first.last@example.com can be sent by a rogue MTA with a valid SPF record, a valid Return-Path that passes muster and a valid DKIM signature by an unrelated domain, but that brings us no closer to authenticating the sender. DMARC is another DNS record that can be queried, and it aims to solve these problems by providing the missing information. It works by looking at the From header, using its domain to query for a DMARC record, which when present indicates that the domain used by the address in the From field must match (or as the standard calls it, align with) an authenticated domain — either the domain of the Return-Path address validated by SPF or the domain used for a valid DKIM signature. While the record may also hint at whether e-mails sent from this domain should have either DKIM, SPF or both enabled, the presence of one or the other is enough to pass DMARC checks regardless of the hinted configuration.

With DMARC in place, if an MDA receives a message, it can be sure that based on the DMARC record the message would need to have either SPF or DKIM, and can decide whether the sender domain was faked or not. Keep in mind that this still does nothing to validate the actual person sending the e-mail, just the domain part of the From address. It is up to us to trust the owner of the domain to set up the infrastructure to authenticate its users and tie them to specific addresses.

DMARC also solves the problem of authenticating e-mails using subdomains — first.last@example.com and first.last@sub.example.com are two different addresses, and even if the primary domain is configured correctly, attackers would still be able to use any of the non-configured subdomains as the source of e-mails. Unlike SPF, where each record only applies to mail sent with a specific domain or subdomain, DMARC introduces the concept of organizational domains, which is just a fancy name for what most people usually mean when they say domain or primary domain. If no DMARC record is found for a subdomain, the standard requires a check on the organizational domain, and if a DMARC record is found there, to apply its configuration to mail using the subdomain.

What happens when an MDA decides that an e-mail does not pass DMARC checks? While SPF and DKIM does not specify what should happen to such e-mails, DMARC can be used to tell servers what the owner of the domain expects clients to do. There are three possible actions: none (do not take action), quarantine (mark the e-mail as suspicious) and reject (do not deliver the e-mail). The domain owner can also request that the action is applied in a probabilistic manner, only applying the rules for a set percentage of messages. Last but not least, DMARC can be used to request that receiving mail servers send regular reports to the domain owner. These reports will be delivered periodically to a specified e-mail address, and can be used to diagnose problems with e-mail systems and to recognize if and when the domains are being used by unauthorized entities. These features can be used to roll out the new policies incrementally, and to ensure business continuity during deployment. Any blind spots in the configuration can be easily detected by looking at the failure reports while the DMARC action is set to none, since all mail will be delivered as if no DMARC record were set up at all for the domain.

Reputation is king

So we have a reliable system to check if an e-mail was sent from a sender authorized by the owner of the domain — but anybody can register a new domain name in a few seconds, so to combat the continuous onslaught of spam we need to tell reputable senders (who are unlikely to send us malicious or unwanted messages) from those who are known as malicious or not known at all. There is no centralized mechanism to do this: e-mail providers use blacklists, content based algorithms and other heuristics to decide if a sender is trustworthy or not.

When your organization is operating an e-mail system, it is responsible for maintaining its good reputation with other services. This includes:

• Sending e-mails that are not marked as spam by users receiving them
• Letting users unsubscribe from automated messages
• Preventing unauthorized users from sending e-mails using domains managed by the organization
• Configuring SPF, DKIM and DMARC to help others filter out fraudulent mail sent in your organization’s name
• Keeping DKIM keys and DNS records secure

Due to the decentralized nature of e-mail systems, each recipient makes its own decision on classifying e-mails as spam. These steps help — on the long run — to maintain trust in your system and to prevent malicious senders from committing fraud using your organization’s name.

Rely on trusted vendors

The easiest way to maintain a secure e-mail system is not to maintain one. There are several cloud providers on the market who will be more than happy to take care of all these issues — the two largest being Google (with G Suite and Gmail) and Microsoft (with Office 365 and Outlook). They both have detailed guides on how to configure your domains to use their services, and they take care of all the technical aspects of both signing and delivering your messages and verifying messages sent by others. You will also have less to worry about when it comes to maintaining a reputation, since thanks to their well documented abuse handling processes these providers are widely trusted across the internet.

• See Set up SPF in Office 365 to help prevent spoofing and its follow up articles if you are an Office 365 user
• Start with Enhance email security if you are using G Suite

There are also cloud providers specializing in marketing e-mails and other automated messages sent by software on your organization’s behalf. Prominent examples include Mandrill, SendGrid and Amazon Simple Email Service, but there are many others. These services can be configured to follow these best practices — if you are using one or more of these, look for e-mail security related articles on their support pages. As an added bonus, some of them may also help your organization with compliance requirements related to user consent, by allowing users to opt out of e-mails from your organization and report unwanted or fraudulent messages — helping you maintain your reputation and giving your emails the best chance of reaching the inbox.

Configure it yourself

If you don’t trust cloud providers, or you have requirements they can’t hope to meet, you can always configure your own e-mail system. Please note that this is not something you set up once then forget about— maintaining your own e-mail system is significant burden on IT personnel.

Make use of SPF, DKIM and DMARC

To deploy these DNS records, you will first need to take inventory of your existing systems:

• Which domains are used by your organization to send e-mail from?

This includes top level domains (@example.com) and their subdomains (@newsletters.example.com). You will need to deploy the new DNS records to all of them.

• Which servers do you use to send e-mails?

All of these servers need to have their domain names reverse DNS resolvable, and they must be included in the SPF records of all domains they are sending e-mails from.

• Do you have any third parties sending e-mails on your behalf?

Most services have guides on how to configure them for SPF, DKIM and DMARC. If not, they can usually be configured to either send e-mail through a relay you maintain, or to send messages under their own domain. Carefully consider which third parties you allow to send e-mails on your behalf. It is best if they are assigned their own domain or subdomain so they cannot fake e-mails under your primary domain, which is often used for the e-mail addresses of employees and departments.

• Do you have internal services sending e-mail notifications without going through your mail servers?

For example, scanners, alarm systems, and other IoT devices may send e-mails as notifications. Instead of sending e-mails directly, they should connect to relays under your control (with authentication). If that is not possible, they should use a different sender e-mail address and you should whitelist them explicitly for received mail.

If you also want to use DKIM, DNS records are not enough — your MTA or MSA needs to be configured to sign outgoing e-mails. You should use a separate key on all servers and add them under different selector names to your domains. Selector names should be hard to guess but easy to identify.

Secure your server

No amount of DNS configuration helps if your servers are vulnerable. You need to ensure that only authorized users can use it to send e-mails:

• Do not run an open relay

Open relays are servers that will forward incoming mail to any other mail server if the recipient cannot be found locally. If you do so, your server will be used by malicious parties to send messages on your and others behalf.

• Authenticate senders

Ensure that your MSA requires users to be authenticated before accepting e-mails for delivery. IP based whitelisting is not authentication, yet it is used in many organizations. It makes auditing sent messages a nightmare, and infected devices can take advantage of such a misconfigured MSA to spread malware inside and outside your network. Establish a strict relationship between your users and the e-mail addresses they can send messages from. Commonly used MSA configurations usually allow any authenticated user to send an e-mail from any address that belongs to your organization, which not only makes the consequences of stolen credentials significantly worse, but might also put your organization in legal jeopardy.

• Use TLS for message submission

Do not allow unencrypted connections to send e-mails or to authenticate. If your employees are working from outside the office, it is possible that someone is listening, and can catch unencrypted credentials sent over Wi-Fi. This kind of attack is quite common at airports or hotels.

A simple example

Configuring an MSA or MTA securely is a daunting task, and not one we will tackle this time. But to give a practical example of these DNS based mechanisms, let’s take a look at the DNS records needed to configure a domain in a simple, single mail server situation that covers the needs of most small businesses. Please note that we will be using a very strict configuration, and if other legitimate mail servers wanting to send e-mails are present, compliant recipients will reject their messages.

Infrastructure

We want to send e-mails from the domain example.com. We have one mail server, that has been assigned the domain name mail.example.com which points to the IP address 175.45.177.43. At this point, we have the following mail related DNS records in the DNS zone that belongs to example.com:

Name            Class   Type    Value
mail            IN      A       175.45.177.43
@               IN      MX      mail.example.com.

The first record is an A record, which specifies that the mail.example.com domain refers to the server with the IP address 175.45.177.43. The second record is an MX record for example.com, which designates that all mail to addresses with the domain example.com should be delivered to the server mail.example.com. These records make it possible for mail addressed to the organization to be processed by the server. The IP address 175.45.177.43 should also be configured to be reverse DNS resolvable to mail.example.com.

SPF record

The SPF record for this setup is very simple. Since the MX record already specifies the servers that are designated to receive mail, we can simply reference that and deny everybody else. The DNS record we need to add looks like this:

Name            Class   Type    Value
@               IN      TXT     "v=spf1 mx -all"

SPF records are assembled from components: one possible component is mx, which adds all hosts found in the MX records of the domain to the allowed senders list. By specifying -all, we have instructed all compliant servers to reject mail coming from servers not on this list. If we wanted to use a more relaxed policy, we could have used ~all, which would have instructed servers to simply mark the message as suspicious, but continue with the delivery.

DKIM record

DKIM requires the MSA to have built-in support for signing messages or to route outgoing mail through a so-called “milter” or mail filter to add the signatures. As such, generating private and public keys for message signing and presenting the corresponding DNS record is usually handled by the software tasked with signing messages. A common milter used is OpenDKIM — while it is out of our scope to configure it to sign outgoing and validate incoming messages, we will use it to generate our private key and the corresponding DNS record:

root@mail.example.com:~$ opendkim-genkey --domain=example.com --selector=exsrv --bits=2048

We specified the domain for which we want to generate the record for (example.com), the name of the selector (exsrv, short for example server) and the length of the private key (2048 is the recommended minimum). Inside our folder, we will now find two files: exsrv.private and exsrv.txt. The former is the private key OpenDKIM will use to sign outgoing messages, while the latter contains the DNS record that we will need to add. For consistency, the record is presented in the same format as the DNS records above, but OpenDKIM saves the record using a different representation.

Name               Class  Type    Value
exsrv._domainkey   IN     TXT     "v=DKIM1; h=sha256; k=rsa; p=..."

The record as shown is incomplete — the public key portion is too long to be conveniently displayed here. No matter the software you use for signing messages, the format of the DKIM record will be the same. Please note that adding a DKIM record if you already have an SPF record is optional, but highly recommended, as it also serves as an integrity protection mechanism — preventing third parties from forging e-mails and claiming them to be from your organization.

You can check if your MSA signs outgoing e-mails correctly by looking at their headers on the receiving end. You should see something similar added:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=example.com; s=exsrv; t=1559206871;
    i=@example.com;
    bh=qwrwt4csbjxK5ZIluMsBeb2ouCHCk1BoqNDnea+zvxo=;
    h=Date:From:To:Message-ID:Subject:Content-Type;
    b=I25nXCIwH8q16FLkf7ASO0wyjYuAA2n6lNeM5UTcmjKBUEv
    /mDY+hdTMKqxnku3/X7nbdPJ41a+Uv2WeXFwZRDDi8GVDRbH4
    F4Nz65qNF1kwL1PPuyFWH7uXN231vk8yfv3+By9ojsaupko1i
    xq1XZpes1JtqL2Wl0/KETU1XgU=

DMARC record

To tie it all together, we want to add a DMARC record:

Name    Class  Type  Value
_dmarc  IN     TXT   "v=DMARC1; p=reject; aspf=s; adkim=s;"

This is the strictest possible record you can have: it will reject all messages that fail DMARC checks, and requires one-to-one matches between the domain in the From field and the authenticated domain from either SPF or DKIM — no subdomains allowed. The reporting features of DMARC have been turned off, so we won’t receive aggregated or forensic reports about failed e-mails.

If you want to receive reports on messages rejected by servers, you can either process those reports manually, or use a third party service to do that for you. In the latter case, the service will have extensive documentation on how to set up the DMARC record in a way that they receive these notifications and can process them for you. If you just want to handle these reports yourself, you will have to specify an e-mail address in the DNS record to which they will be sent (dmarc@example.com will be used in the example):

Name    Class  Type  Value
_dmarc  IN     TXT   "v=DMARC1; p=reject;    
                     rua=mailto:dmarc@example.com;
                     ruf=mailto:dmarc@example.com; 
                     fo=1; aspf=s; adkim=s;"

Please note that you can only have one DMARC record — so the entire configuration has to be included in a single TXT entry. The configuration above is just an example: it will opt-in to both forensic and aggregate reports, and will trigger a report even if DMARC is passed but either SPF or DKIM is missing.

The other side

To see how e-mail service providers make use of this information, it is worth taking a look at the headers they append to incoming mail to indicate the results of the SPF, DKIM and DMARC checks they perform. For users of Office 365, Exchange will add something like this:

Received-SPF: Pass (protection.outlook.com: domain of example.com
    designates 175.45.177.43 as permitted sender)
    receiver=protection.outlook.com;
    client-ip=175.45.177.43; helo=mail.example.com;
Authentication-Results: spf=pass (sender IP is 175.45.177.43)
    smtp.mailfrom=example.com; dkim=pass (signature was
    verified) header.d=example.com; dmarc=pass action=none
    header.from=example.com; compauth=pass reason=100

As for users of G Suite, Gmail does something similar:

Received-SPF: pass (google.com: domain of first.last@example.com
    designates 175.45.177.43 as permitted sender) 
    client-ip=175.45.177.43;
Authentication-Results: mx.google.com; dkim=pass     
    header.i=@example.com
    header.s=exsrv header.b="JothSm7L"; 
    spf=pass (google.com: domain of first.last@example.com 
    designates 175.45.177.43 as permitted sender)
    smtp.mailfrom=first.last@example.com; dmarc=pass 
    (p=REJECT sp=REJECT dis=NONE) header.from=example.com

These headers indicate that both Exchange and Gmail checks SPF, DKIM and DMARC to verify the sender. Depending on the DMARC action, an e-mail that failed these checks might never reach the inbox of the user, or might be placed into the spam folder.

Check your score

Want to see if your organization has configured SPF, DKIM and DMARC correctly? There are services out there that can help you check this quickly. Head over to dmarcian.com and enter the domain part of your e-mail address. (Please note that we are not affiliated with dmarcian.) For example, entering tresorit.com yields the following results:

Conclusion

The way electronic mail was designed has made it very hard to conclusively verify the legitimacy of the sender. Fortunately, solutions exist to this problem, but they must be deployed and maintained. Many companies today ignore this risk — and attackers have free reign in sending mail on their behalf. Most companies usually wake up to this problem once their e-mails land in the Junk folder of their partners, but by that time, the damage to domain reputation has already been done. It it in the best interest of every company, administrator or even end user to use an e-mail system that is well configured and prevents sender fraud.