Who’s Sending My Email?

Domain Based Message Authentication

Earlier this year, as part of our company-wide effort to conform to the Center for Internet Security (CIS) 20 Critical Security Controls, Tanium implemented a more restrictive configuration using Domain Based Message Authentication, Reporting, and Conformance (DMARC) for company emails. As expected, it significantly reduced the number of spam and phishing emails. But we also encountered several unanticipated challenges while deploying. Given the number of other companies that choose not to configure DMARC, we thought it might be helpful to share our experience by providing an overview of DMARC, common challenges associated with implementation, and a few helpful suggestions we learned along the way.

DMARC uses two technologies, Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM), to determine if an email was spoofed (i.e. forged to appear as though it originated from your organization) or legitimately sent from your company. Both SPF and DKIM are published as public DNS records that can be referenced from anywhere. These controls allow receiving SMTP servers to examine incoming headers, compare their source and integrity keys to those published by your organization, and then decide whether or not to deliver or take some action, such as quarantining a message. This information is then reported back to an individual email address that can be parsed and sorted for anomalies or issues.

SPF is simply a list of Fully Qualified Domain Names (FQDN) or IP addresses that a company has designated as approved SMTP senders. Receiving SMTP servers can parse the headers of an incoming message to determine the originating SMTP server. DKIM is a much more granular control that relies on asymmetric encryption. Tanium publishes a public key via DNS and securely retains the corresponding, unpublished private key. Any third parties that wish to send emails on the company’s behalf must also generate a public/private key pair, and include their public key in DNS as well.

When an email arrives, the receiving server will take the attached DKIM key from message headers and query the originating server to verify its legitimacy. If the DKIM key provided does not match the originating server’s private key, the message is spoofed. If there is a match, the remote server knows that email originated from the sender, and can be safely delivered.

Implementation challenges

While both SPF and DKIM are fairly simple to implement, they do require that other organizations participate and correctly configure their DNS records. When considering third party software that will be sending email on your behalf, you should consider whether SPF and DKIM are fully supported by the vendor. Failure by the vendor to properly implement SPF and DKIM could make full enforcement difficult or impossible.

That said, even if other organizations do configure SPF and DKIM correctly, you should be aware of additional challenges:

SPF scalability

SPF can only perform ten DNS queries limited to several different record types (this includes A, MX, PTR, EXISTS, INCLUDE, and REDIRECT records). This limit exists to prevent infinite record searches, but also restricts the scalability of SPF. Redirects and other DNS mechanisms that require multiple lookups can exhaust the limit quickly, and can cause confusion in troubleshooting. For this reason, it is extremely important to carefully consider how DNS records are used to implement SPF. IP addresses/ranges are not included in this limitation; however, keeping up with changing IP addresses can be resource intensive when compared with using a FQDN.

Subdomains not included

SPF only evaluates the exact domain name that’s specified in the record — subdomains are not included. For example, if you specify an SPF record IP address for @company.com, and that IP sends from @_subdomain.company.com, _the SPF check will fail. Each subdomain must have its own SPF record.

Using DKIM keys from other domains

DKIM keys allow other organizations to be fully authenticated against your domain (and thus able to send verified email on your behalf). Properly configured third parties can provide you with a selector key (this key is essentially loaning you their public key while they remain in control of the private key). Even though you do not own the private key, properly configuring the selector key in the DNS will allow you to forward decryption requests back to the third party and complete the validation.

Organizations can specify how tightly to control failures from either SPF or DKIM with the following options:

–None: messages are digested and logged for review, while still allowing the offending message to be delivered
–Quarantine: Each mail provider determines what this action will be, but for most, this means dumping messages directly into the Spam folder of the user
–Reject: Messages are outright rejected when not aligned via either SPF or DKIM

Keep in mind: DMARC output is not easy to read. The results are delivered in an XML file and is sent to the email specified in the DMARC policy from every SMTP server that receives messages. Depending on the amount of email traffic, thousands of messages could be sent per day resulting in difficulty in identifying and troubleshooting potential issues.

In order to properly understand your environment, several tools exist to both identify issues in DMARC/SPF/DKIM records themselves, and help identify issues hidden in the DMARC XML reports that are sent back when an SMTP server has determined a message is in violation with policy. Tanium uses a service called Dmarcian to help parse our settings and aggregate results.

While not perfect, implementation of DMARC goes a long way to allowing organizations both visibility and control over who’s sending emails using their domain name. By effectively utilizing these tools, organizations can significantly reduce the amount of malicious email reaching your organization and prevent malicious users from spoofing your domain. DMARC provides organizations with control over how receiving SMTP servers can both verify and take action on legitimate and illegitimate emails purporting to be from the origin “@yourdomain.com”.

By configuring a proper DMARC implementation, Tanium was able to add supportive control coverage in 3 different CIS areas:

• CSC 7: Email and Web Browser Protections
• CSC 8: Malware Defenses
• CSC 9: Limitation and Control of Network Ports, Protocols, and Services

Conclusion

If you manage domains serving email, you should strongly consider implementing DMARC. Not only is it in the best interest of each individual company, but the email ecosystem as a whole will benefit as the number of domains that can be spoofed effectively becomes less and less. Lowering the chance of spoofing your domain means less chance that your users will be exploited, and less chance of spending money responding to incidents or dealing with other liability issues. It is a small but important part of full implementation of proactive security measures like the CIS Top 20 controls, and helps to satisfy the requirements of achieving certification for standard compliance frameworks like ISO 27002. It just makes sense for the health and wellbeing of companies of all sizes.

About the Author: Eric Fisher is an Information Security Analyst and enterprise operations design expert with Tanium in Raleigh, NC. Eric holds a Masters in Information Security and Forensics, and has previously worked as a security consultant standing up SOC and incident response programs for several fortune 500 banks, retailers, and tech companies. He has also designed and secured large scale compute architectures and networks for several different Government agencies and the military as an employee of the Penn State Applied Research Laboratory and Raytheon.