Domain impersonation is one of the natural enemies of the Simple Mail Transfer Protocol (SMTP) protocol. To combat this risk, the Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) were created. Each of these three protocols uses different approaches to prevent threat actors from impersonating your domain. As a result, each protocol comes with different strengths and weaknesses, setup complexity, maintenance effort, reporting capabilities, etc.
While each protocol is different, it is important to emphasize that they all provide an important contribution to email security, and the purpose of this article is not to suggest that you pick one of the three. The goal here is to compare these three email security protocols with each other using different criteria to help you choose which protocol to prioritize and deploy first, depending on your use case. This article also sheds light on the inner workings of these protocols, helping email administrators understand each protocol better.
The table below summarizes the five criteria we will use to compare the SPF, DKIM, and DMARC protocols to help improve our understanding of each.
|
Criterion |
SPF |
DKIM |
DMARC |
|
Primary purpose |
SPF lets a domain owner publish which IP addresses are authorized to send mail for that domain. |
DKIM cryptographically signs the message body and selected headers, proving that the content hasn’t been altered and that it originated from an authorized domain. |
DMARC checks whether SPF and/or DKIM results align with the visible “From” domain, then tells the receiver how to handle verification failures. |
|
DNS record implementation |
SPF requires a simple DNS TXT record where you specify the authorized IPs that can send emails on behalf of your domain. |
DKIM requires the creation of a special TXT record following a specific naming convention: selector._domainkey.<domain_name> |
DMARC requires the creation of a special DNS TXT record that looks like this: _dmarc.<domain_name> |
|
Setup complexity |
SPF is easy to set up and straightforward in most cases. |
DKIM setup might be considered difficult for inexperienced IT administrators with little experience with cryptography. |
DMARC setup difficulty can be considered moderate since it heavily relies on the correct implementation of SPF and/or DKIM. |
|
Maintenance effort |
SPF might require high effort to maintain if your IP space or IT infrastructure change often. |
DKIM requires little to no effort to maintain once it is securely set up. |
Similar to DKIM, DMARC requires next to no effort after the setup. However, managing DMARC reports afterward can be time-consuming. |
|
Reporting capabilities |
SPF provides no built-in reporting capabilities. While some platforms may expose SPF authentication results, this is not standardized, nor are the results sent back to the domain owner. |
DKIM provides no native reporting capabilities. Its results are logged by receivers but not shared upstream with the sender’s email server. |
DMARC provides two different XML reports: one containing all DMARC authentication results (RUA) and one that only contains the failed attempts (RUF). |
In the rest of this article, we explore each of the five criteria we have selected to compare the three email authentication protocols: purpose, implementation, setup complexity, maintenance effort, and reporting capabilities.
SPF works by checking the IP address of the sender’s email server and comparing it with a list of IPs that the sender’s domain owner has included in their DNS record as authorized to send email on its behalf. If the verification fails, the SPF record for the domain also specifies how the recipient’s email server should act, e.g., rejecting or marking an email as spam.
DKIM makes use of public-key cryptography to achieve the same goal as SPF. Once a cryptographic key pair is generated, the private key is used by the sender’s email server to digitally sign the emails. After an email is received, the recipient’s email server uses the public key that was published on the Internet by the domain owner and verifies the email signature. If the verification fails, it is up to the recipient’s email server to decide what to do with the email. The DKIM record, unlike SPF, doesn’t specify how to handle the email.
DMARC is dependent on SPF and/or DKIM, and can only work if one of the two protocols is already implemented. Its purpose is to cover an important weakness of both SPF and DKIM: the non-inclusion of the From: email header in the verification process. In order for the DMARC verification to succeed, at least one of the SPF and DKIM verifications needs to pass, and the From: email header needs to match the Mail From email header (for SPF) or the domain name on the d= field of the DKIM-Signature: email header (for DKIM). If one of these two checks fails, the DMARC record provides instructions to the recipient on how to handle the suspicious email. Unlike SPF and DKIM, DMARC also enables domain owners to receive reports from recipients regarding benign and/or malicious emails that are sent on behalf of their domain.
All three protocols use DNS records to store the information needed for the recipient to verify the authenticity of the email.
To find the SPF information for a domain, admins can list all DNS TXT records for a domain and find any DNS record starting with v=spf1:
|
v=spf1 ip4:1.2.3.4 -all |
For DKIM, identifying the correct DNS record is not as straightforward as SPF. This is because a special DNS record is created for DKIM, following the naming convention <selector>._domainkey.<domain_name>. Before the recipient’s email server can identify the DNS record, it needs to extract the selector from the s= field and the domain name from the d= field of the DKIM-Signature email header of the email. Then, using this information, the recipient can identify the DNS record containing the base64-encoded public key, which will be used to verify the email’s digital signature.
|
Name |
Type |
Content |
TTL |
|
dkimTest._domainkey.example.com |
TXT |
v=DKIM1; k=rsa; p= <base64_encoded_public_key_step_4> |
6000 |
DMARC also uses a DNS TXT record to store its information. Like DKIM (but unlike SPF), a new subdomain is used for its DNS record. This DNS TXT record is created under _dmarc.<domain_name> and specifies the email addresses the recipient can use to report the results of the DMARC authentication they perform:
|
v=DMARC1; p=none; rua=mailto:<some email address>; ruf=mailto:<some email address> |
Of the three protocols, DKIM can be considered the most difficult to implement for the first time because it requires the generation and maintenance of cryptographic keys as well as configuring the email server to sign emails. Due to the nature of cryptography, certain security considerations need to be remembered to avoid undermining the security provided by the DKIM protocol. For example, a leak/compromise of the private key or short cryptographic keys would immediately enable a threat actor to forge malicious but correctly signed emails that appear to come from your organization.
SPF, on the other hand, is relatively easy to implement. The domain owner only needs to create a DNS TXT record and list one or more IP addresses (or IP ranges) that are authorized to send emails for the domain. However, the setup might get more complex and hard to handle if nested SPF records are used.
Nested SPF records use the keyword include: to specify another domain that holds the list of IPs to check during the SPF verification. As one can imagine, if one domain includes another one and the other domain includes one as well, it might become difficult for the domain owner to keep track of or control which IPs are authorized or not. .
Additionally, RFC 7208 section 4.6.4 for SPF clearly states that the receiving email server should only perform up to ten SPF DNS lookups for an email. If this quota is reached, the receiving email server will throw an error and not accept the email, causing delivery issues. Alternatively, if you have more than 10 SPF records, or are getting close to 10, this will also reach the quota and hinder email delivery. To keep the SPF setup simple and not affect email delivery, you can "flatten" your SPF records manually or through a service like this one to avoid this. You can learn more about SPF flattening here.
Finally, while DMARC is relatively easy to set up itself, remember that the security benefits of DMARC rely on the correct setup of SPF and/or DKIM. Given this dependency, its setup can be considered of moderate complexity.
Implementing any of SPF, DKIM, or DMARC is not a fire-and-forget process. Each protocol requires some periodic maintenance effort that depends on certain factors.
SPF heavily relies on a list of authorized IP addresses to send emails that the domain owner specifies. If the organization changes its IT infrastructure, moves to the cloud, or merges with another company, this list of authorized IP addresses needs to be adjusted accordingly. The frequency of SPF record adjustments will depend on how dynamic and large your organization’s IT infrastructure is.
For DKIM, the maintenance effort will depend on whether the domain owner followed security best practices when setting up DKIM and whether the private key is stored securely and is only accessible by authorized staff. While the cryptographic key pair should be rotated periodically, as long as the private key is secure, this can be done annually or even less frequently.
Finally, DMARC requires far less maintenance than SPF or DKIM once the initial DMARC tests are completed. After setting up a stable DMARC record, as long as the email addresses specified on the DMARC record remain active, the DMARC record rarely needs to be changed.
Unlike SPF and DKIM, DMARC is the only protocol that provides built-in reporting capabilities. By specifying the rua= field on the DNS TXT record for DMARC, the domain owner will receive (typically) daily reports about how their emails are being handled by receiving mail servers. Furthermore, by specifying the ruf= field, the domain owner will also receive a report from email recipients for all failed DMARC authentications observed. This information can greatly help your organization debug email delivery issues and, more importantly, identify and track domain impersonation attempts against your domains.
While this information is valuable, the volume of reports can grow quickly, especially for large organizations or frequently spoofed domains, making them difficult to analyze manually. To simplify this process, consider using a dedicated solution to automatically process and interpret DMARC reports.
While it is recommended to implement all three of SPF, DKIM, and DMARC, sometimes it is necessary to prioritize and plan the deployment one by one. Before choosing which one to implement first, it is important to remember that each of the three email security protocols follows a different approach for email spoofing prevention. For that reason, in this article, we compared the differences between SPF, DKIM, and DMARC using five different criteria, including implementation strategy, setup complexity, reporting capabilities, etc. An important takeaway from this article is that none of the three protocols is perfect, and all three protocols should be implemented to guarantee resilient email security against domain impersonation attacks.