Trustworthy

IT administrators, no matter their level of experience, agree that managing mail servers is one of the supreme disciplines. Too many fragile system settings, too many pitfalls, and above all, public pillories in the form of blacklists if something goes wrong during configuration. All the more respect goes to the admins who successfully manage mail servers, keep them permanently available, and ensure that outgoing email reaches the intended recipient reliably.

Microsoft in particular and the email service providers they control are considered particularly strict when it comes to accepting messages from third-party servers. Although some people claim that Microsoft is deliberately filtering third-party providers to boost the number of customers for its own services, this prejudice cannot be confirmed on closer inspection. Microsoft offers comprehensive information about blocking mail servers and recommendations for action on a website set up specifically for this purpose [1]. If you have the mail server under strict control, you do not need to worry about problems with delivery to Live, Hotmail, or Outlook servers.

In this article, I look at how to secure email with the Domain-based Message Authentication, Reporting, and Conformance (DMARC) email authentication protocol.

Secure Mail Dispatch

Even though spam filtering and malware detection when receiving email play a major role in corporate security, in this article, I only look at how to secure email transmission. Of course, the measures I will be looking at also indirectly contribute to the security of enterprise email accounts, as long as the other mail servers also use them. Because fake senders can be blocked even before email is received, the incoming spam volume is automatically reduced. The integration of corresponding tests for receiving mail servers is described in the documentation for the Exim and Postfix mail transfer agents.

Probably the most important step is to set up a Sender Policy Framework (SPF) record in the domain name system (DNS) that lets admins specify authorized outbound mail servers. Although designed in 2004, SPF only became the standard recommended by the Internet Engineering Task Force (IETF) in 2014 [2]. From a sample of more than 3,000 domains belonging to German companies, I examined the DNS records and determined the number of valid SPF records. About 25 percent of these domains do not have an SPF record stored, which means that recipients cannot check whether the delivering mail server is allowed to send messages for the sender domain.

This situation opens the door for phishing and CEO fraudsters; therefore, you should get an overview of your company's sending mail servers and enter them as SPF records in the DNS. If you can't easily determine this list, at least limit sending to your company's subnets and contracted mail sending service providers. Taking this step is still better than having no SPF entry at all. Note that the entry must be created for the domain that is used as the domain part of the email, not for the (incoming) mail server.

Signatures with DKIM

Domain Key Identified Mail (DKIM) [3] lets users sign outgoing email with a private key. The server's public key is stored in the domain's DNS. Here, too, the entry must be created for the domain part of the email. In contrast to SPF, however, multiple keys with different selectors can be managed, which results in DNS entries for different subdomains. For a selector with the name admin-mag , the appropriate DNS entry would be created in admin-mag._domainkey.admin-magazine.com.

The selectors are included with the email signature so that the receiving mail server can select the correct domain to receive the public key. Because the selector can vary from server to server, and the recommendation is even to change it regularly, it is not possible to make a comprehensive statement about the implementation of DKIM on the Internet within the scope of this article. As a lower boundary, however, it can at least be stated that around 13 percent of the domains tested have entered one of the standard selectors from the documentation and tutorials. However, it is not possible to say reliably whether this actually signs outbound messages, if the incoming email message was not signed.

Guidelines with DMARC

SPF entries come with instructions on how to deal with senders not mentioned in the entry, but email without a DKIM signature should not be rejected without further ado. Because of the different selectors, no uniform DNS entry exists to check the existence of a DKIM key.

DMARC lets you define appropriate policies for domains, which means you can specify that email from a domain always needs to be signed with DKIM, even independently of specific DKIM selectors. With the associated policy, you can then determine whether non-signed email will be ignored by the recipient, quarantined, or directly rejected.

Additionally, you can specify the relative proportion of your email messages for which the DKIM signature will be verified. To be on the safe side, you should, of course, have 100 percent verified. In the implementation phase, but also permanently for information purposes, you can store URIs to which forensic and summary reports of the DMARC check are sent. You also need to ensure that you can receive and process the reports sent once or several times a day by the various mail servers.

To receive the reports by email, enter a mailto URI with your email address. However, make sure it matches the domain being checked; otherwise, other mail servers will initially refuse to send the statistics for security reasons. This behavior can be further customized with additional DNS entries and use other domains for receiving DMARC reports.