Best Practices to Setup SPF DKIM and DMARC

Chapter 3

11 min

Table of Contents

    Simple Mail Transfer Protocol (SMTP), the core protocol for email delivery, was never designed with security in mind. Over time, attackers have exploited its lack of authentication to launch various types of abuse, especially domain impersonation. By abusing the lack of sender authentication in the SMTP protocol, a threat actor can send an email impersonating any domain on the Internet, resulting in successful phishing and business email compromise (BEC) attacks. 

    To address this weakness of the SMTP protocol and to enhance the email spoofing protection, the security research community designed three email authentication protocols: Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC). While the request for comments (RFC) specification documents theoretically explain in detail how to implement each protocol, practical implementations can lead to misconfigurations or errors that undermine security. To avoid such issues, in this article, we cover some security best practices to keep in mind when implementing each protocol and how to ensure that your implementation remains resilient.

    Summary of SPF, DKIM, and DMARC setup best practices

    The table below summarizes the different security best practices we will cover for each email security protocol during its setup and after. 

    Best practice category

    Description

    Defense in depth email security mindset

    By combining SPF, DKIM, and DMARC, you ensure defense-in-depth email protection against domain impersonation.

    SPF setup best practices

    Implementing SPF might look straightforward, but its use can get cumbersome. Best practices for SPF setup include restricting lists of IP addresses and avoiding nested SPF records. 

    DKIM setup best practices

    DKIM relies on cryptography to ensure email authenticity and integrity. Since DKIM uses cryptographic keys to verify email integrity, missteps in key management or algorithm choice can weaken your implementation. You can avoid a poor DKIM implementation by following best practices such as maintaining private key hygiene and choosing cryptographically secure algorithms.

    DMARC setup best practices

    While DMARC is simpler to implement than SPF and DKIM, consuming and managing many DMARC reports can quickly get challenging and frustrating. To avoid getting overwhelmed, make use of best practices like implementing DMARC strict mode after testing and reviewing your DKIM/SPF setups.

    What comes after the setup?

    Regular maintenance should also be performed by changing the list of IPs for SPF or rotating the cryptographic material for DKIM. Reviewing DMARC reports for your domain will help you identify and thwart domain impersonation trends in time. 

    The importance of a defense-in-depth email security mindset

    The use of  SPF, DKIM, or DMARC considerably improves your email security against domain impersonation, but no protocol is 100% safe from attacks. Relying on a single tool or protocol creates risk, especially in security where attackers look for weak links. That is why it is always recommended to follow a defense-in-depth approach, so that even if one layer of defense falls, other layers will still protect you. You can achieve this for email security by implementing SPF, DKIM, and DMARC in tandem, as each protocol complements the others and mitigates their respective weaknesses.

    SPF setup best practices

    SPF works by creating a DNS TXT record for your domain where you specify a list of IP addresses, IP ranges, or domains that are authorized to send emails on behalf of your domain. For the sake of simplicity, here is an example of a basic DNS TXT record for SPF:

    v=spf1 ip4:1.2.3.4 -all

    This SPF record contains the following information:

    • v=spf1 → Every DNS TXT record that is used for SPF must begin with this string to distinguish it from other types of DNS TXT records.
    • Ip4: 1.2.3.4 → The IP address of the email server that is authorized to send emails on your behalf. If more than one IP address is allowed, another Ip4: field can be added. Note that you can also specify an IP range like 1.2.3.0/24.
    • -all → The final field in an SPF record is used to instruct the recipient email server on how to handle the email if it fails the SPF check. 
      • -all: Any email originating from IPs not listed in the SPF records is not authorized and must be rejected.
      • ~all: The sender’s email server IP is not authorized to send the email; it should be marked as spam but accepted, a.k.a. “soft fail”.
      • +all: Any email server can send email on your behalf, and these emails should be allowed.

    While the SPF setup seems straightforward, there are some security best practices to consider when during implementation:

    • Restrict the list of IP addresses to only necessary IPs: While it might seem convenient to authorize an entire IP range to avoid email delivery issues, this increases the possibility of a threat actor owning an IP in this IP range, enabling them to impersonate your domain in emails. For example, if your email servers are operating in the cloud and you add an entire IP range to your allowlist, there is a chance that some of those IPs are assigned to unknown entities that might abuse this IP assignment.

    • Avoid nested SPF records: By using the include keyword in an SPF record, you can specify domains that are allowed to send emails on your behalf. However, this domain might name other domains to do that as well, which can chain together multiple layers of “includes”, making it difficult to track or control the resulting list of IP addresses authorized to send emails for your domain. Unless necessary, it is recommended to avoid such complex setups.

    While these are some common challenges for any SPF setup, keep in mind that other additional challenges might arise with the SPF implementation when you start using Microsoft 365 or Google Workspace.

    DKIM setup best practices

    DKIM is another email security protocol that helps you prevent domain impersonation by using public-key cryptography. Since DKIM setup tends to be more complex than SPF or DMARC, we’ve covered it in more depth in a separate article. In this article, we review a basic DNS TXT record for DKIM and go through some of the security best practices to keep in mind during and after the setup process:

    v=DKIM1; k=rsa; p=<base_64_encoded_public_key>

     

    A basic DKIM record contains the following elements:

    • v=DKIM1 → The version of the DKIM protocol, in this case, version 1.
    • k = rsa → The key type describes the cryptographic algorithm for the key pair, in this case, RSA.
    • p = <base_64_encoded_public_key> → This field contains the base64-encoded public key.

    For DKIM, follow these security best practices to ensure the effectiveness of this protocol:

    • Maintain private key hygiene: Since DKIM depends on the secrecy of the private key, it’s critical to store it securely both during and after setup, just like you would with credentials or passwords. Limit access to only the staff who need it, and rotate the key regularly. If your private key is ever compromised, an attacker can use it to sign malicious emails that appear to come from your domain, completely undermining DKIM.
    • Choose cryptographically secure algorithms or keys: Avoid obscure or custom cryptographic algorithms that haven’t been widely reviewed by the security community—they may contain vulnerabilities that haven’t been discovered yet. Stick to well-established public-key algorithms like RSA or Ed25519. Also, make sure your keys are long enough to resist brute-force attacks; for example, RSA keys should be at least 2048 bits to meet current best practices. Use of short cryptographic keys might open an attack vector that could undermine the security of the algorithm. Ensure that the cryptographic key size is long enough, following the best practices for the chosen algorithm.
     

    DMARC setup best practices

    DMARC is the newest of the three protocols and was created to complement SPF and DKIM as well as to provide domain owners with authentication results and reports of the emails sent from their domain. DMARC relies on SPF and/or DKIM and requires that either of these two protocols already be set up for it to function properly.

    Unlike SPF, DMARC information is placed on a separate DNS TXT record under _dmarc.example_domain.com and not directly under example_domain.com. A basic DMARC record would look like this:

    v=DMARC1; p=none; rua=mailto:<some email address>; ruf=mailto:<some email address>

    This record contains the following fields:

    • v=DMARC1 → The version of the DMARC protocol being used.
    • p=none → A parameter that tells the recipient’s email server what to do with the email if it fails DMARC verification:
      • None: Do nothing; often used during the monitoring/audit phase.
      • Quarantine: Accept the email, but treat it as spam/junk or quarantine it.
      • Reject: Do not accept the email from the sender’s email server.
    • rua = <some email address> → This instructs the recipient’s email servers where to send aggregate DMARC reports for any kind of DMARC check performed for your domain.
    • ruf = <some email address> → This instructs the recipient email servers to send DMARC failure reports to the specified email address. 

    Consider the following security best practices both before and after setting up DMARC:

    • Implement DMARC strict mode after testing: While it is important to properly test DMARC with p=none before enforcing it in production, it is often the case that domain owners are reluctant to change DMARC to strict mode later on, or forget to do so. By leaving DMARC set to p=none, the recipient’s email server will accept all emails from your domain, even those that fail the DMARC verification. By never enforcing DMARC in strict mode (e.g., quarantine or reject), you will not be making use of the email security enhancement that DMARC provides. 

    As a best practice, we recommend a gradual approach. You can start by using p=none to create an understanding of the email delivery and collect data, followed by a light enforcement (i.e., emails might be quarantined but still delivered) by switching to p=quarantine once you have evaluated the data from the first stage. Finally, after ensuring that email delivery is not hindered by p=quarantine, you can confidently change the enforcement level to p=reject to benefit from the full protection of DMARC.

    The step by step process of carefully enforcing DMARC to strict mode

    • Review the implementation of DKIM and/or SPF: DMARC relies on SPF and/or DKIM, so misconfigurations in either can cause DMARC to fail. Before enabling DMARC, make sure both protocols are set up properly and pass alignment checks. Fixing issues up front ensures DMARC works as intended.

    What comes after the setup?

    Setting up SPF, DKIM, and DMARC is just the beginning, keeping them effective takes ongoing monitoring and maintenance. For example, SPF relies on a hardcoded list of IPs to work, so if your IT infrastructure changes, this might impact SPF. For example, if your organization stops using a third-party email service but forgets to remove its IP addresses from your SPF record, those IPs could eventually be recycled and assigned to someone else. If that happens, and your SPF record still lists them as authorized, a malicious actor could send spoofed emails that appear to come from your domain. That’s why it’s important to regularly review and update your SPF configuration to ensure it only includes active, trusted sources. 

    Similarly, DKIM might require the periodic rotation of the cryptographic material to remain secure. While this monitoring and maintenance doesn’t need to be very frequent, it still remains an essential process to ensure that your defenses are operating properly and remain secure. 

    Finally, one of the most important benefits of DMARC is its reporting capabilities. By regularly reviewing and analyzing DMARC reports, you can track and react in time to active attempts that impersonate your domain. However, regularly parsing XML reports, analyzing them, and extracting important insights from these reports might become overwhelming with time. That is why you should consider investing in a solution that performs all these tedious tasks for you, allowing you to only focus on visualizing the results and acting on them. 

    Conclusion

    SPF, DKIM, and DMARC can greatly boost your email security, reduce the risk of domain spoofing, and ensure your emails get delivered to inboxes. During their setup, it is important to follow security best practices to avoid undermining the security benefits these protocols provide. In this article, we explored each of these protocols and some of the most important best practices to keep in mind and how to combine all three protocols for a defense-in-depth approach to email security. Remember that, once set up, regularly monitoring and analyzing the DMARC reports is necessary to maximize the security benefits of these three protocols. 

    Continue Reading this Series

    Chapter: 3 How to Setup SPF DKIM and DMARC

    Learn how to set up SPF, DKIM, and DMARC protocols to protect against domain impersonation and email compromise.

    Read chapter

    Chapter: 2 SPF vs DKIM vs DMARC

    Learn how the email security protocols SPF, DKIM, and DMARC compare in terms of purpose, implementation, setup complexity, maintenance effort, and reporting capabilities.

    Read chapter

    Guide to SPF DKIM, and DMARC

    Learn how to protect your business from Business Email Compromise (BEC) and other phishing attacks using SPF, DKIM, and DMARC email authentication protocols.

    Read chapter