IT Security 101: DKIM, SPF and DMARC
Introduction
iEmail is essential for organizations of all sizes, and is a common target for threat actors. There are various ways in which email may be leveraged to obtain sensitive data, deploy malware or gain access into a network. One major flaw in email systems is that they inherently allow impersonation of individuals or organizations by malicious actors (a.k.a. “spoofing”).
Luckily, controls have been developed to help organizations protect themselves against their own systems and users being spoofed:
DomainKeys Identified Mail (DKIM)
Sender Policy Framework (SPF)
Domain-Based Message Authentication, Reporting and Conformance (DMARC)
These controls rely on DNS record configurations to provide identity verification of senders. When email is received, the receiver can analyze the email’s headers, and query the DNS records of the sending domain, to validate that the sender is authentic (or, that the sender is authorized to send on behalf of an authenticated source).
All three controls should be implemented to prevent, or reduce greatly, the ability of threat actors to spoof an organization’s email. Note, these controls must be implemented by the sender, and any validation performed by a recipient’s system is only effective if the sender has properly configured their own DKIM/SPF/DMARC. Further, if a recipient has strict controls for validation, then improperly configured senders may be blocked, rejected or quarantined, regardless of their validity, causing a disruption to business communications.
DomainKeys Identified Mail (DKIM)
DomainKeys Identified Mail (DKIM), defined in RFC 6376, utilizes cryptographic signatures to authenticate an email’s sender and content. It further provides the ability to:
verify the identity of the sender,
identify the sender as known or unknown, and
identify the sender as trusted or untrusted.
It does this through the use of a public/private key pair. The public key is stored as part of the DNS record, and can be queried by recipient systems. A hash of the e-mail header and some of the e-mail’s body are recorded in the header, along with the algorithm used to hash them. The receiving system can then use that information in conjunction with the published public key to validate the message.
Sender Policy Framework (SPF)
Sender Policy Framework (SPF), defined in RFC 7208, uses DNS TXT records to verify emails are sent from authorized servers. An organization can configure TXT records to specify IPs and IP ranges that are authorized to send for their domains.
When configured, prior to receipt of a complete email message, receiving systems can query the DNS records of the sender to verify the originating server is listed as an authorized source. If the sending IP matches one in the TXT record, it will pass the SPF check and allow the full email to be retrieved. If it fails, the receiving side can decide how to handle the message.
Typically, the receiving system can be set to reject the message, or hold it for further review by an administrator. Holding a message will allow admins to check for false-positives. In that case, they can either add an exception according to their own organization’s policies, or preferably for all involved, reach out to the sending organization through a known, valid method and request that the sender resolve any issues with their SPF configuration. Adding excessive exceptions opens an organization to risk, and in this case bypasses the purpose of SPF. Requesting that the sender fix their own SPF issues will not only protect the defender’s organization, but will strengthen the security of all recipients with which the sender does business.
Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
Domain-Based Message Authentication, Reporting, and Conformance (DMARC), defined in RFC 7589, combines the use of DKIM and SPF to allow for the creation of policies on how to handle authentication failures. For this to be effective, DKIM and SPF must be configured.
DMARC again utilizes DNS TXT records to prescribe how a recipient should handle failures, and also may request that recipients provide reports so that domain owners can monitor policy effectiveness.
DMARC defines three policies on how to treat unauthenticated messages:
Take no action, but generate reports (none).
Flag the message as suspicious (quarantine).
Block the message (reject).
Through the use of the failure options (fo) tag in the record, policy can be set to report if:
Both SPF and DKIM fail (fo=0, or Default).
Either SPF or DKIM fail (fo=1).
Only DKIM fails (fo=d).
Only SPF fails (fo=s).
The default option fo=0 is the most restrictive and will result in the greatest number of failures, yet offers the greatest protection.
Again, these options are configured by the sender, and the receiver can choose how they would like to honor them. When email is received, DNS can be queried to retrieve the sender’s policy. Generally, it is expected that recipients will respect the policy; however, certain circumstances may require the recipient to override it. Recipients can again choose to bounce, drop or quarantine messages.
Note, any rejected messages will be unretrievable, as they will be dropped before they are allowed to be further processed by the system. For any actions taken by the recipient system, the admins of that system can decide who should be informed, such as the email sender, the intended recipient, or a system admin (or no one at all). If no one is informed, legitimate business communication may fail without anyone’s knowledge, and will result in unhappy users. However, choosing not to inform senders of rejects may be a valid defense option, as it would prevent malicious actors from being able to validate when their attempts fail.
Conclusion
Email is a powerful business tool, but its reliance, and its constant and wide use, make it a major threat vector for organizations, especially given the ease with with threat actors are able to spoof legitimate senders. For effective protection against spoofing, it takes a coordinated effort by both sending and receiving defenders to ensure that SPF, DKIM, and DMARC are configured effectively.
Daily Cuppa
Today’s cup of tea is Organic Earl Grey provided by Equal Exchange. Organic and fair trade.
Smooth and energizing, with a burst of bergamot!
If you enjoyed this article, or the site in general, feel free to buy the author a cup of tea.
The author is also available for work.