Understanding Email Authentication Protocols: A Technical Overview of SPF, DKIM and DMARC With Configuration Tips

Historically, email was a bit of a free-for-all where mail servers blindly accepted any email that was received. Obviously, this has changed in the last 15 years with the proliferation of spam and virus filters, also known as mail filters or “milters” for short. These filters look at the content of an email or the reputation of the sending mail server and determine if the email is likely spam or contains malicious content. And while these controls are certainly necessary, they do nothing to address the legitimacy of emails that are received. Let’s dive into today’s email authentication protocols, SPF, DKIM and DMARC to better understand your email security risks and configuration options. I’ll also share three quick configuration tips to strengthen your security.

What Are Email Authentication Protocols?

At a high level, modern email protocols allow the sender to set the “From” address to anything they want. In most circumstances, the originating address for an email is enforced by the email service provider (Gmail, Microsoft, etc.) or by your organization’s IT department (likely based off the organization’s domain name and enforced by the mail server). That enforcement is done by the email provider and not the underlying email protocols, meaning savvy users or malicious actors can still forge emails to appear to come from any “From” address they want. Since the sender can specify any address they want, you might be thinking “but how do we ensure bad actors cannot impersonate a legitimate user or send unauthorized emails that appear to come from our domain?” Email authentication is the answer to that question.

According to the Oxford English Dictionary, authentication is the process of verifying the identity of a user or process. This blog post is not meant to cover user authentication, but rather authentication between the sender and recipient mail servers. Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) are two email authentication protocols, both of which rely on Domain Name System (DNS) to host information. A receiving mail server can use these two authentication methods to determine the legitimacy of an incoming email using a Domain-based Message Authentication, Reporting & Conformance (DMARC) policy, which defines whether to accept or reject the email. Let’s take a deeper look at SPF, DKIM and DMARC to better understand these three common mechanisms that are usually part of email authentication protocols.

SPF (RFC7208) is simply a list of IP addresses that are authorized to send emails for a given domain and are hosted in DNS TXT records. When a mail server receives an email, it checks to see if the if the email came from an IP address that is listed in the hosted SPF record. The receiving mail server can then accept or deny the email depending on if the SPF check passed or failed. SPF records contain various mechanisms and qualifiers that are beyond the scope of this blog post. If you are looking for information on SPF syntax, DMARCIAN has a great reference here.

DKIM (RFC6376) is based on Public Key Infrastructure (PKI) and is a cryptographic signature applied by the sending server that allows the recipient to ensure the legitimacy of the email. Each server that needs to send DKIM signed emails must first create a public/private keypair and post the public key in a DNS record. To create the DKIM signature for an email, the sending server first hashes specific components of the email (specified by the mail administrator) and then encrypts the subsequent hash with the server’s private key. The resultant ciphertext is inserted into the DKIM header of the email message that is embedded into the email. The receiving mail server inspects the DKIM header, which includes 2 important attributes, “d” and “s”. These tags represent the originating domain and the “selector” it uses. Selectors determine which public key to use to decrypt the ciphertext in the DKIM header. Sending servers can, and likely should, have multiple public/private key pairs used for different purposes (i.e., different countries, business units, or departments). These public keys can be configured as additional TXT DNS records.

With the public key, the recipient server can compute its own hash of the message and compare it to the value in the “bh=” DKIM header sent by the originating server, in this way the recipient can verify the message source and ensure it was not tampered with along the way. It is important to note that even though DKIM utilizes public key encryption, this does not mean that the contents of these emails are end-to-end encrypted; that should be handled by a combination of TLS and either S/MIME or PGP.

While SPF and DKIM are mechanisms to support email authentication and validation, DMARC (RFC7489) can be thought of as the rule book for email authentication protocols, telling recipients what to do with the messages given different circumstances. DMARC also provides mechanisms for reporting on the effectiveness of your SPF and DKIM policies. The three options for DMARC policies are “none”, “quarantine”, and “reject”. The “none” option effectively places DMARC in monitor-mode and allows mail to be delivered. This option should be used while SPF/DKIM are being rolled out and things are being fine-tuned. “Quarantine” does exactly what you’d think it does and tells the mail server to deliver any emails that fail SPF or DKIM checks to a quarantine or junk folder for follow-up. “Reject” is the most-strict option and tells the mail server to drop any emails that fail SPF or DKIM checks. Reject can also be configured to send an error message back to the originating server. It should be noted that an email need only pass either an SPF or DKIM check to then pass DMARC; it does not need to pass both, although it’s great if it does!

3 Quick SPF, DKIM and DMARC Configuration Tips

1. Configure SPF for your domain and use either the -all or ~all flag. The ~all flag may be sufficient most of the time, although the more strict -all flag could also be used.
2. Configure DKIM according to your mail service provider’s instructions.
3. Configure DMARC initially with the “none” option until you’re confident SPF and DKIM are functioning properly, then consider switching to “quarantine” or “reject.” Review DMARC reports regularly to measure the effectiveness of SPF and DKIM for your domain.

Email authentication protocols can help mitigate risks associated with email tampering, spoofing, and phishing attacks. The Center for Internet Security (CIS) recommends SPF as part of its Critical Security Controls (CSC) category 9, “Email and Web Browser Protections.” Further, the National Institute of Standards and Technology (NIST) released SP 800-177 and Technical Note 1945, both of which cover SPF, DKIM, and DMARC in great detail. NIST also published broader email security guidance in SP 800-45 “Guidelines on Electronic Mail Security.”

We hope you find this technical guidance on email authentication protocols and configuration tips for SPF, DKIM and DMARC helpful. LMG frequently reviews clients’ SPF and DKIM configurations as part of our Microsoft 365 Configuration Review service. If you are interested in having LMG review the security controls of your Microsoft 365 tenant, please contact us!