How SPF, DKIM, DMARC Drive Email Delivery, Security

A trio of email authentication standards work together to improve email deliverability for the sender and email safety for the recipient.

Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) help to ensure that emails sent from your company are real and that malicious actors are not spoofing or otherwise tampering with them.

SPF, DKIM, DMARC

SPF, DKIM, and DMARC show the receiving email server that a given message was sent from an authorized IP address, that the sender is authentic, and that the sender is transparent about its identity.

Let’s take each one in turn.

Setting up SPF records for your domain involves adding a type of TXT record containing an authorized list of outgoing mail servers to the Domain Name System (DNS). SPF verifies that emails from your business’s domain come from an authenticated source, not an imposter.

DKIM keys consist of two parts: a public key stored in the DNS and a private key stored on the sending mail server. The DKIM signature attached to each outgoing email is used by recipients’ mail servers to verify its authenticity. DKIM can also indicate if a given email message has been altered.

DMARC is a policy mechanism that allows a company to control how incoming emails from its domain should be handled if they fail the SPF or DKIM authentication. The options are “reject,” “quarantine,” or “none.” This can be like an alarm bell if a wrong-doer is trying to use your domain.

SPF Records

Setting up an SPF record requires access to your domain’s DNS records at the registrar, such as GoDaddy or similar. If you have ever had to verify your domain or move it to a new server you likely updated its DNS record.

Screenshot of an SPF record in a DNS settings interface

An SPF record is simply a TXT record in your domain’s DNS.

The SPF record will be of the type “TXT.” And it will start with the version of SPF you are using.

v=spf1

The version is followed by a list of authorized IP4 or IP6 addresses, as in:

v=spf1 ip4:192.168.0.1

This SPF record would authorize emails from the 192.168.0.1 IP address. To allow a range of IP addresses, you could use Classless Inter-Domain Routing (CIDR) notation (sometimes called “slash” notation).

v=spf1 ip4:192.168.0.0/16

The above SPF record would authorize a range of IP addresses from 192.168.0.0 to 192.168.255.255 — this is what the “/16” indicates.

Using the prefix “a,” an SPF record can authorize a domain by name. The record below authorizes a server associated with the example.com domain.

v=spf1 a:example.com

Similarly, the prefix “mx” (“mail exchange”) authorizes specific mail servers.

v=spf1 mx:mail.example.com

To authorize a third-party sender, use the prefix “include.” The example below permits both an IP range and Google servers.

v=spf1 ip4:192.168.0.0/16 include:_spf.google.com

There are also two SPF qualifiers. The first is ~all with a tilde (~). The second is -all with a hyphen (-).

The tilde version (~all) is a soft-fail qualifier. In most cases, the receiving email server will accept messages from senders that aren’t in the associated SPF record but consider them to be suspicious.

The hyphen version (-all) is a hard-fail qualifier. The receiving email server will likely label messages sent from a server not authorized in the SPF record as spam and reject them.

Finally, all of these may be used together for relatively complex authorizations.

v=spf1 ip4:192.168.0.0/16 a:example.com include:_spf.google.com

Remember, SPF records help the receiving email servers identify authentic email messages from your company’s domain.

DKIM Keys

DKIM protects your domain and helps to prevent anyone from impersonating your company. The two DKiM keys allow the recipient’s email server to verify that your company sent the message and that it was not altered after you sent it.

The first step in setting up DKIM is generating the keys — one public and one private. The private key is secure on the server used for sending emails from your domain. The public key is added to the DNS as a TXT record.

The tricky part is generating the keys since the exact procedure for creating them varies from one email service provider to the next. And it is completely different if your company hosts its own mail server.

Email service providers offer instructions. Here are several examples in no particular order.

Mailchimp: Set Up Email Domain Authentication,
Klaviyo: How to Set up a Dedicated Sending Domain,
Zoho Campaigns: How to Authenticate My Domain,
MailerLite: Email domain authentication,
Campaigner: DKIM, SPF, and DMARC,
ConvertKit: Using a Verified Domain for Email Sending,
MailUp: Maximizing Deliverability for Your Emails,
ActiveCampaign: SPF, DKIM, and DMARC Authentication,
Keap: DKIM.

In each case, the DKIM is completed when you add — copy and paste — the email provider’s CNAME record to your domain’s DNS. This record(s) represents the public key to authenticate your company’s outbound email marketing messages.

DMARC

DMARC provides another layer of protection and also instructs email servers what to do with messages that fail SPF or DKIM authentication.

The foundation of DMARC is a TXT record placed in your domain’s DNS. This will contain the DMARC policy with at least two elements:

An email address to receive aggregate reports of email authentication, and
The action to take on emails that fail authentication (i.e., reject or quarantine).

Here’s an example DMARC TXT record in a DNS:

v=DMARC1; p=quarantine; rua=mailto:armando@example.com; ruf=mailto:armando@example.com.

The record begins with the DMARC version.

v=DMARC1;

The “p” element assigns the action for emails that fail authentication. In this case, it’s set to “quarantine,” which instructs the receiving server to move such messages to a holding area. Other options include “none” — which does not stop the email but monitors SPF or DKIM failures — or “reject.”

p=quarantine;

The prefixes “rua” and “ruf” tell the receiving server where to send aggregate reports (rua — Reporting URI for Aggregate data) and forensic reports (ruf — Reporting URI for Failure data). These reports can disclose a criminal attempting to impersonate your business.

Additional modifiers include:

pct — the percentage of email messages subjected to the DMARC policy.
sp — the DMARC policy for subdomains.
adkim — assigns strict (adkim:s) or relaxed (adkim:r) mode for DKIM.
aspf — assigns strict (adkim:s) or relaxed (adkim:r) mode for SPF.

Third-party services can help generate a DMARC record based on the official standard. These services include:

Protect Sender and Recipients

Setting up SPF, DKIM, and DMARC records for your domain ensures that email servers recognize messages from your company as authentic and reject imposters. The result protects your company’s reputation and shields customers from phishing attacks and other types of email fraud.