Hardening Email with DKIM, SPF, DMARC

Email is a communication tool whose history is intertwined with that of the internet itself. Being an age-old network service, emails are susceptible to various threats, most of which are inherent to the stack of protocols that make up the solution. Over the years, several means to mitigate such issues have been developed and in this article, I will focus on three specific methods directly related to DNS configurations, which are highly effective in bolstering the service and completely avoiding the most common threats: DKIM, SPF, and DMARC.

DKIM

DomainKeys Identified Mail (DKIM, RFC 6376) is a security standard that safeguards email messages against tampering while in transit. If you have ever examined an email header, you are aware that messages traverse multiple mail servers before reaching the final mailbox. During this journey, there is a potential for a man-in-the-middle attack, where the message can be altered before reaching its intended destination.

DKIM utilizes public-key cryptography to sign the message, ensuring its integrity. The DKIM configuration is done through a DNS TXT record with a specialized name based on the domain. This record has a selector component that enables the email server to perform the necessary DKIM lookup in the DNS, usually in the format selector._domainkey.

The DKIM record in the DNS comprises various fields, including:

SPF

Sender Policy Framework (SPF, RFC 7208) is a specialized DNS record designed to identify authorized mail servers and domains that are allowed to send email on behalf of a domain. Similar to DKIM, SPF is set up using a TXT record. The name typically points to the root domain (@), and the content consists of key-value pairs:

A softfail here can be considered a middle ground between failure and neutrality, which is useful when an organization is gradually adopting SPF.

Important: It is not allowed to have multiple SPF records as the receiving mail server won't know which SPF rules to follow.

DMARC

Domain-based Message Authentication, Reporting, and Conformance (DMARC, RFC 7489) is an email authentication and validation system that aids in protecting against spam, phishing, and spoofing. DMARC provides two types of reports:

DMARC is configured through a DNS TXT record with the name _dmarc. The content of this record comprises key-value pairs, such as:

By employing these three authentication methods together, organizations can effectively safeguard against various threats. DKIM and SPF establish the legitimacy of the senders to the recipients, while DMARC instructs the recipients' servers on how to handle emails when DKIM or SPF checks fail.

While implementing DKIM, SPF, and DMARC is relatively straightforward, it is crucial to approach the configuration with caution to prevent disruption of user communication. It is advisable to start with more lenient policies initially and gradually transition to more secure configurations after successful testing. Here are some examples:

Keep in mind that DNS changes take time to propagate correctly (depending on the DNS's TTL), and improper changes can have serious consequences. It is recommended to make these changes outside of business hours and conduct thorough testing before and after implementing any modifications. Also, it is essential to maintain a record of every change as you may need to revert it due to unforeseen issues.

During my tenure as the leader of the SOC, we faced a situation where we stopped receiving emails from an important partner after activating SPF. We handled that by temporarily setting the SPF policy to neutral until the partner resolved the issue on their end. Although we encountered a few similar issues (users not receiving emails from partners due to SPF blocks), such occurrences became increasingly rare over time. This improvement can be attributed to the growing adoption of email as a service (SaaS) and the implementation of better security practices.

As configuration changes vary for each service/server and detailed guides are readily accessible online, I won't delve into the specifics of the implementation process in this article. The key takeaway is that all three methods effectively ensure email integrity, safeguarding senders and recipients from tampering, spoofing, and related attacks. Enhancing confidentiality and availability requires implementing additional methods, but that's another story.

References