How to secure your email with SPF, DKIM and DMARC

Email is usually a critical part of corporate communication these days. Without a functional email, companies can lose orders and therefore money for example. Therefore, email security should be a very high priority. But equally, increasing email deliverability should be very important.

In today’s article, we’ll look at how to increase email security from the perspective of protecting your domain. In other words, so that an outsider can’t impersonate you, send emails under your domain, and thereby damage your company’s reputation or credibility by, for example, sending out spam or, heaven forbid, fake invoices for payment from your domain.

We’ll also look at how to increase the deliverability of your messages. That is to say, so that regular emails leaving your domain are delivered to the recipient, and don’t fall into spam or get completely thrown away by the recipient’s mail server.

We’ll focus on three basic options for email security and deliverability that every organization should have implemented.

SPF

SPF stands for Sender Policy Framework. Technically, SPF is implemented using a TXT record added to the domain. This TXT record contains information about the mail servers that are authorized to send email from the domain. The SPF also includes information about what should happen if an email is not sent from a mail server in the SPF record.

For the rest of this article, it’s important to note that SPF only works with the FROM address in the email envelope. However, the FROM address in the email envelope is not what we see in the mail client. The FROM address is typically used for the reply-to address, that is, what appears when you start replying to a given message, which may not be the same as what you see in the mail client as the sender address. In fact, the mail client usually only displays the MAILFROM address from the email envelope.

How to create an SPF record for a domain

I won’t go into all the technical details here, they are described many times on the web or directly within RFC 7208. Let’s just look at the most typical use of an SPF record for a domain.

By default for a domain, you will have your normal mail servers that your outgoing mails come from. If mail is going out from mail servers defined for incoming mail, you can simply use the MX record.

Large cloud mail providers usually have different server addresses for incoming mail and different ones for outgoing mail, so an MX record would not work. These providers therefore usually have outgoing mail servers defined under a specific domain name designed just for SPF. Microsoft has this defined for Office 365 under the domain name spf.protection.outlook.com, for example, under which the SPF policy for Exchange Online is configured.

If you are sending emails from elsewhere, you need to add those mail servers to the SPF as well. For example, if you are sending email from a web server, you must add its IP addresses to the policy using ip4 (for IPv4 addresses) and/or ip6 (for IPv6 addresses).

Taking a practical example, for example for Office 365 (Exchange Online technically) Microsoft has a predefined TXT record in the form v=spf1 include:spf.protection.outlook.com -all that you should add to your domain DNS. This SPF record defines that it is SPF version 1 (v=spf1), that the SPF policy from the spf.protection.outlook.com domain should be added (include:spf.protection.outlook.com), and that emails sent from other servers should be rejected (-all).

However, if you are also sending emails from, for example, a web server with IPv4 address 1.2.3.4 and IPv6 address 2002:1:2:3::4, you need to add these addresses to the record as well and the SPF record would look like v=spf1 include:spf.protection.outlook.com ip4:1.2.3.4 ip6:2002:1:2:3::4 -all.

DKIM

DKIM stands for DomainKeys Identified Mail. DKIM is used to sign emails to ensure that the email actually came from the sender specified and that the email (or parts of it) has not been tampered with in transit.

When an outgoing message is signed using DKIM, the mail server adds a new DKIM-Signature field to the email header. The mail server determines what is signed and what not itself and uses the h tag to specify what is signed within the email, but the FROM field is mandatory and must always be signed.

The recipient’s mail server can then verify the signature using DNS records for the domain. DNS records are usually of the CNAME type, which points to the actual TXT DNS record with the public key used to verify the signature. Or it may be a TXT record that directly contains the public key itself. The public key in the TXT record allows to verify the validity of the signature of the message.

Most providers use two pairs of keys for rotation, so that if one pair is invalidated, messages can still be authenticated using the other key pair.

How to create a DKIM record for a domain

Microsoft uses CNAME records within Exchange Online. A selector is inserted into the DNS that points to the DNS record behind which the public key itself is hidden. For my domain cswrld.com, the records look like this.

The DNS records listed above are always generated directly by your email provider. Within Office 365, these records are generated the moment you activate DKIM for your domain.

When we look what is behind one of the CNAME DNS records above, we will se this

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA56WyeWaBcE8iZ0Ns56JolMv1c89HRSD4B+UegF2V+hBs8l5I+KfSePMVzgwEfhQDchfX3aOsZc7j+ZTnRwXv0icN2qGY9haEUoTNMtvEnw7L/wu8fbCkByqXQ1PJftz80UwQSpG6BIN043+8cL1v1KqlQCkVq9tNM/IPwI15Lg0FU3zfpvQRdlULttO1XRYJv1+MBmPB3j+zvvBINeiVcYccM2l2tOM5ct+WVPB27luvwlxSCu+ExIZb4C1F8Or1HcO9x06A8FSCpb/larkR+M1UrO5dO2UTr7Du0U5caZrQo6hlCH3N/U0WNj80ImKoGieWsdYrIUX5K1232wOvzQIDAQAB;

It is the TXT record that defines the version (v=DKIM1), key type (k=rsa), and the public key (p=MIIBIjA...).

DMARC

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It is an extension of DKIM and SPF mentioned above. Again, it is a DNS record of type TXT that you add to a domain. In this case, however, there is no sender-side mechanism, just a policy that defines what the recipient should do.

As I mentioned earlier, DMARC uses SPF and DKIM. So if SPF and DKIM are defined along with DMARC, the recipient mail server should verify the result of the SPF and DKIM validation. If at least one of these validation failed, the DMARC automatically fails as well and the message should be treated according to the policy defined in the DMARC record.

How to create a DMARC record for a domain

DMARC is defined using a TXT record created for the name _dmarc. The policy then defines what should happen to a message that fails authentication. The options are none (the message is delivered), quarantine (the message is sent to quarantine) or reject (the message is rejected).

The record itself could look like this.

v=DMARC1; p=reject; pct=100;

v=DMARC1 is the DMARC version, p=reject defines the policy what should the receiving mail server do with messages that fail, pct=100 is the percent of bad emails on which to apply the policy (all emails in my case = 100%). Optionally, you can also configure DMARC reports via rua or ruf tags.

How to verify email authentication results

Now you know how email authentication works and how to define it for your domain. Now we’ll look at how to verify that email authentication works for your outgoing messages and also how to verify email authentication for the messages you receive.

As I’ve mentioned several times, the email authentication information is contained in the message header. So just open the message header or the entire message source. The message header tends to be very long and hard to read, so it’s best to use some tool that parses the message header into a readable form.

For example, we can use Message Header Analyzer from Microsoft to paste the header (or the entire message) to and have it parsed into a readable form.

If we look in DKIM-Signature, we can see the DKIM signature.

v=1; a=rsa-sha256; c=relaxed/relaxed; d=cswrld.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aKjrWzus4STeQjzLxIwJzlfO42sadIHoH9Y52N3yGQc=; b=x2bOPYc0qLPE45+AJsz/zdnoqQImHa7ODU+WjbpukrXqLdksgWdOfTCOia+fQvMaJdlWPbXKErGHUFaFJCVIhxRrPqS6KGsmt5asqKdVyGUQqacqiWVsvGCNiJJJ25cFzUkRgIec+xHPDWxfZ5yoVN0QjOCk0d/pNKJ9WwQ6Ukquo4ULndlWhOh9Z8iIf//BbnpDpXtTPrGwdohiCxFWubiSWgvYu6/w7a5yZr4SI+32ggZL+L92/07lQmdtx85ZMdVs4G/eHUSzYDUFgowim0H1Jo+bAWRvsUIMtkyVX+u16Grxm1W+jVcZ3RlALikZc46JJaIP8mlDTkWrnIr2xg==

But the main information is in Authenticaton-Results, where we can see that the SPF, DKIM and DMARC validations passed fine.

spf=pass (sender IP is 40.107.20.121) smtp.mailfrom=cswrld.com; dkim=pass (signature was verified) header.d=cswrld.com;dmarc=pass action=none header.from=cswrld.com;compauth=pass reason=100

You can find a detailed video showing all the settings with spoken commentary describing each configuration option in detail on my Patreon. By subscribing you also support my work. Thank you!