Tech

The Ultimate SPF / DKIM / DMARC Best Practices 2024

Reduce spoofing and phishing, build and maintain a solid reputation, and increase email deliverability with SPF, DKIM, and DMARC.

Freddie Leeman

• 3 min read
The Ultimate SPF / DKIM / DMARC Best Practices 2024

The internet is evolving, and so are email security best practices. Unfortunately, these recommendations can contradict each other over time due to outdated information and superseded security standards. That's why we've created the ultimate best practice guide for SPF, DKIM, and DMARC. We've included explanations and links to the official documentation and are dedicated to keeping this guide up-to-date and following the recommendations from the M3AAWG and cyber security specialists worldwide.

💡
These best practices are for active domains. Follow the "M3AAWG Protecting Parked Domains Best Common Practices" guidelines for domains that do not send emails (parked domains).

SPF

  • Publish SPF records for EHLO [1] and RFC5321.MailFrom [2] domains
  • SPF records should end with ~all [3]
  • SPF record should not exceed the 10 DNS lookup limit [4]
  • SPF records should not authorize more sources than necessary [5]
  • RFC5321.MailFrom domain should align with RFC5322.From domain where possible

  1. At the start of SMTP transmission, the sending server identifies itself by sending the EHLO command followed by its domain name. This domain name can differ from the RFC5321.MailFrom domain name. The EHLO domain is only used for SPF validation when the RFC5321.MailFrom address is unavailable. ↩︎

  2. After identification, the sending server communicates the RFC5321.MailFrom address by sending the command MAIL FROM. If an email cannot be delivered, this address is used for the non-delivery report. The domain of this address is used to retrieve the SPF policy. ↩︎

  3. The use of ~all (softfail) instead of -all (fail) is best practice, as the latter can cause receiving servers to block the message at SMTP transmission instead of evaluating possible DKIM signatures and DMARC policies. For more details on fail and softfail, please read chapter 8.4 of the SPF RFC and chapter 10.1 of the DMARC RFC. A softfail will still cause DMARC to fail without a valid and aligned DKIM signature. ↩︎

  4. Administrators can implement SPF macros to avoid exceeding the 10 DNS lookup limit mentioned in chapter 4.6.4 of the SPF RFC. We'll dedicate a separate blog on how to implement SPF macros soon. ↩︎

  5. Avoid using CIDR notation to allowlist large network blocks, and use a DMARC monitoring service to monitor and detect unutilized sources. ↩︎

URIports detects unused SPF sources and offers suggestions for improvement

DKIM

  • Sign all outbound emails with a domain that aligns with the RFC5322.From domain [1]
  • Use the rsa-sha256 signing algorithm for creating signature hashes [2]
  • Use a minimum of 2048-bit key length [3]
  • Rotate keys at least every six months [4]

  1. The RFC5322.From address (also referred to as the Header From: address) is part of the email message itself and is usually the address that is shown in email clients to the end user. This address can differ from the RFC5321.MailFrom address, but it needs to align for DMARC to pass. ↩︎

  2. See chapter 3.1 from RFC8301 ↩︎

  3. See chapter 3.2 from RFC8301 ↩︎

  4. To reduce the risk of active keys being compromised, either by attackers cracking or stealing, rotating DKIM keys once every 6 months is recommended. ↩︎

DMARC

  • The policy should be set to reject where possible (p=reject), quarantine (p=quarantine) otherwise [1]
  • The policy must omit the pct element, or it must have a value of 100
  • The policy should include the rua tag for monitoring email channel health [2]

  1. Policy none (p=none, sp=none) should only be viewed as transitional states and upgraded to reject or quarantine as quickly as possible. ↩︎

  2. A DMARC monitoring service keeps track of a domain's outbound email channel. URIports can even send (push-) notifications when irregularities are detected, avoiding the dreadful task of regularly and manually checking the DMARC report data. ↩︎

💙
DMARC Monitoring. Reinvented. Get detailed insight into your email channel with the URIports DMARC Analyzer.
Read more

Conclusion

Implementing SPF, DKIM, and DMARC according to the best practices above will result in an optimal configuration that prevents third parties from spoofing your domain while simultaneously building the best possible reputation and guaranteeing legit emails reach their destination.

If you are still in the early stages of DMARC implementation, start with a p=none policy and use URIports to monitor your email traffic through DMARC reports. After you've allowlisted all aligned sources in your SPF and made sure that all legit sources sign and align with DKIM, you should upgrade to p=reject as soon as possible.

Still confused?

We've written a blog post and created a FREE tool called LearnDMARC to help you better understand these mechanisms by visualizing the communication between servers when an email is delivered. You can also use it to test your current SPF, DKIM, and DMARC setup.

Sources

RFC7489 Domain-based Message Authentication, Reporting, and Conformance
RFC7208 Sender Policy Framework
RFC6376 DomainKeys Identified Mail Signatures
RFC8301 Cryptographic Algorithm and Key Usage Update to DKIM
M3AAWG Best Practices for Implementing DKIM
M3AAWG Email Authentication Recommended Best Practices
M3AAWG DKIM Key Rotation Best Common Practices