Tuesday, March 14, 2023

DMARC, DKIM, and SPF for email

There is a huge amount of spam and phishing emails on the internet. To combat this recipients are getting more and more aggressive in trying to block it. As a mail system administrator, you want the valid email from your domain to be accepted by recipients. 

There are three different (but related) technologies that you should be aware of that validate email from your domain:

  • SPF (Sender Policy Framework)
  • DKIM (DomainKeys Identified Mail)
  • DMARC (Domain Message Authentication Reporting and Conformance)

All of these technologies are used by recipients to validate that email is sent from an authorized email system. Correctly configuring these technologies increase the likelihood that email you send won't be incorrectly categorized as spam.

These technologies are also useful to prevent spoofing email from entering your email system. Many phishing attempts try to appear as though mail comes from your domain. SPF and DKIM help identify these. For example, a message from it@contoso.com would be identified as unauthorized when coming from a random IP address on the internet rather than your own authorized servers. 

SPF

An SPF record is a TXT record in DNS that list authorized sources for email in your domain. For example, the SPF record in contoso.com defines which servers are authorized to send email from the contoso.com domain. You need to identify all of the services that send email on behalf of your domain before you configure the SPF record. Valid sources can be applications or marketing services in addition to your email provider.

The value in the TXT record contains host names (a) and IP addresses (ip4 or ip6) that are allowed to send email for your domain. If you have three servers in your organization that send email to the internet, then you need to include the IP addresses or host names for those servers in your SPF record. Remember that the IP address and host name are from the perspective of hosts on the internet. You need to include host names that can be resolved by internet DNS or IP addresses that are routable on the internet.

If you're using a hosting service, such as Microsoft 365 or Gmail, to send messages, they'll provide instructions on how to configure SPF for their service. In many cases, they maintain lists of host names and IP addresses so you don't have to. In your SPF record, you refer to their configuration by using the include option.

Example:

  • Type: TXT
  • Name: @
  • Value: v=spf1 include:spf.protection.outlook.com ip4:1.1.1.1 -all

Description of record contents:

  • All SPF records start v=spf1 to indicate that they are an SPF record.
  • The include option in this example is used for Microsoft 365. Microsoft maintains the detailed information required at this DNS location.
  • The ip4 option specifies that the server 1.1.1.1 is allowed to send email on behalf of the domain.
  • The all option is always includes at the end of the SPF record. When it's configured with a dash (-), then mail not from a valid host should be a hard fail. When it's configured with a tilde (~), then mail not from a valid host should be a soft fail.

 Additional resources:

DKIM

DKIM adds a digital signature to email messages to verify that they are from an authorized source. The recpient email system reads the digital signature and verifies that it's valid for your domain. The digital signature is validated based on DNS records that you publish.

The process for implementing DKIM varies depending on the email provider. Microsoft has an easy to use system in Exchange Online where they manage most of the DNS work for you. Other vendors provide information for you to create your own DKIM DNS records. And, some vendors and applications don't support DKIM at all. For example, on-premises Microsoft Exchange Server doesn't have DKIM functionality included.

In Microsoft 365 (Exchange Online) the DKIM process is pretty simple to implement. You need to create two CNAME records in your domain that point to records created by Microsoft and then turn on DKIM for the domain. The following example record is for contoso.com:

  • Type: CNAME
  • Name: selector1._domainkey
  • Value: selector1-contoso-com._domainkey.contoso.onmicrosoft.com

When an email that's signed using DKIM is received, it includes a digital signature. The digital signature refers to the selector that contains the key used to used validate the signature. The DNS example above is for selector1 in the contoso.com domain. The CNAME record directs recipients to selector1-contoso-com._domainkey.contoso.onmicrosoft.com to obtain the necessary key for validation.

Additional resources:

DMARC

A DMARC record is a TXT record in DNS that tells recipients two main things about email from your domain:

  • How to handle email that fails validity checks.
  • Where to send reports about email that fails validity checks.

Email is validated when it passes either the SPF check or the DKIM check. This means that you can begin using DMARC when you have implemented SPF but don't have DKIM. This is important since some email systems don't support DKIM.

The p option in the record allows to you define what action should be taken on messages that fail SPF and DKIM. The potential values are:

  • none - Specifies that no action should be taken and messages that don't pass should be delivered. You can use this during initial setup when you're still validating your configuration.
  • quarantine - Specifies that unvalidated messages should be send to quarantine or junk email. You can use this when you think your setup is configured correctly but still want more time to validate.
  • reject - Specifies that unvalidated messages should be discarded. You should use this option when you configuration is fully validated and you know that your SPF and DKIM are configured properly.

An important benefit of DMARC is the ability to define an email address for reporting messages that were not validated. A recipient email system that receives in invalid email sends a report to the email address. Then you can review the reports and identify any valid systems or applications sending email from your domain and fix the configuration. This email address is defined by the rua option.

For a busy email system, it's not realistic to review all of the DMARC reports manually. Instead, there are many services such as dmarcian (dmarcian.com) that will host a mailbox for you and process the DMARC reports into usable information.

Example DMARC record:

  • Type: TXT
  • Name: _dmarc
  • Value: v=DMARC1; p=reject; rua=mailto:dmarcreports@contoso.com;

 Description of record contents:

  • The DMARC record for a domain always has the name _dmarc.
  • A DMARC record always starts with v=DMARC1.
  • The p option defines the action for unvalidated messages.
  • The rua option defines the email address for reports.
  • The  semicolon (;) at the end is optional.

Additional resources:

Summary

Every organization should have SPF and DMARC in place. You can do this without having DKIM enabled because the SPF passing is sufficient. However, DKIM is an additional assurance of validity for email delivery and you should implement it where you can.

Be aware that receiving email systems can do whatever they want with inbound mail for spam filtering. So, it's possible that even if you have SPF, DKIM, and DMARC configured correctly, a message can be blocked, but it's much less likely.