What's Their Purpose?

Put simply, SPF, DKIM and DMARC are ways to authenticate your mail server and to prove to ISPs, mail services and other receiving mail servers that senders are truly authorized to send email. When properly set up, all three prove that the sender is legitimate, that their identity has not been compromised and that they're not sending email on behalf of someone else.

These antispam measures are becoming increasingly important, and will one day be required by all mail services and servers. ISPs and mail services, such as Gmail and Office 365, are getting more and more stringent in the types of email they'll accept, so having all three checks configured ensures that email gets delivered and isn't rejected outright or otherwise delayed.

SPF

SPF is an acronym for "Sender Policy Framework". As with all three checks, SPF is a DNS TXT record that specifies which IP addresses and/or servers are allowed to send email "from" that particular domain. It's essentially like the return address that's placed on a letter or postcard that lets the recipient know who sent the communication. The idea is that if they know who sent them the letter, the recipient is more likely to open it. In this example, though, the "recipient" is the receiving mail server, not the actual person being emailed.

UPDATE: Regarding subdomains, the now-extinct website OpenSFP.org recommends the following with regards to subdomains:

"So the advice to SPF publishers is this: you should add an SPF record for each subdomain or hostname that has an A or MX record.
Sites with wildcard A or MX records should also have a wildcard SPF record, of the form: * IN TXT "v=spf1 -all"

In addition, please note that an SPF record cannot generally exceed 255 characters.

How Do I Create An SPF Record?

An SPF record is a very simple string that can be easily created by a domain administrator and added to that domain's DNS record as a TXT entry. Several websites offer SPF record generation, such as MXToolbox. There are very few parts to it:

1. The SPF version being used.
2. The IPs that are authorized to send email for the domain.
3. Any third-party domains that are authorized to send email for the domain.
4. An ending "all" tag that indicates the policy that should be applied when a receiving server detects a server that's not part of your SPF record.

So, let's look at a typical SPF record and what each part of it means:

v=spf1 ip4:22.23.24.25 include:another-domain-that-can-send-email-for-us.com -all

v=spf1 -- This simply states that version 1 of SPF is being implemented. There is no other version at this point, so this should always stay "v=spf1", at least until another version is released. (If you're curious, there was another version at one time -- SenderID -- but it's been discontinued.)

ip4:22.23.24.25 -- This is the IP address of the mail server and/or domain that's authorized to send email for that domain. Multiple IPs can be used. So if your mail provider rotates IPs, all IP addresses can be listed either individually (ip4:22.23.24.25 ip4:12.13.14.15) or through a CIDR range (ip4:22.23.24.0/20). Note that both IPv4 and IPv6 addresses should be listed if both are used by the mail server.

include:another-domain-that-can-send-email-for-us.com -- This is a secondary domain that is authorized to send email on behalf of the primary mail domain. If multiple domains are authorized, they should all be listed as separate "includes." However, a maximum of 10 includes are allowed for any sending domain.

all -- The "all" tag basically tells the receiving server how it should handle all messages sent from a domain if it sees a domain in the header that's not listed in the SPF record. There are a few options, and these options are dictated by the character that precedes the "all" tag. These are:

• -all (dash all) -- This is a hard fail. This means that servers that aren't listed in the SPF record aren't recognized or authorized to send email for the domain, so the email should be rejected by the receiving server.
• ~all (tilde all) -- This is a soft fail. Basically, that means that the server isn't listed in the SPF record, but it should not be flat out rejected by the receiving server. Instead, the message will be marked as possible spam.
• +all (plus all) -- THIS IS NOT RECOMMENDED. Now that THAT is out of the way: this tag essentially means any domain listed is authorized to send email, even if it's not listed in the SPF record.

DKIM

DKIM is an acronym for "DomainKeys Identified Mail". It's also known as "email signing". Just like an SPF record, DKIM is a TXT record that's added to a domain's DNS. And if SPF is like a return address on a letter, DKIM is like sending that letter via Certified Mail as it further builds trust between the sending server and receiving server. That's because DKIM's intent is to prove that the contents of an email message haven't been tampered with, that the headers of the message have not changed (e.g., adding in a new "from" address) and that the sender of the email actually owns the domain that has the DKIM record attached to it. (Or is at least authorized by the owner of the domain to send emails on their behalf.)

Unlike SPF, however, DKIM uses an encryption algorithm to create a pair of electronic keys -- a public and a private key -- that handles this "trust". The private key remains on the server it was created on, which is your mail server. The public key is what's placed in the DNS TXT record. Because of this relation, DKIM records generally need to be created and managed by Domain Administrators. And while the private key is kept private, the public key is generated by a tool on the mail server and can easily be copied and pasted into a TXT record with that domain's DNS provider (e.g., GoDaddy, eNom, DynDNS, etc.). In addition, Domain Administrators have control over all DKIM settings for a domain, and these can be changed and edited as needed. The new record simply needs to be re-added to a domain's DNS.

How Do I Create a DKIM Record?

Ideally, your mail server will provide a tool that allows you to create the information right on the server. (For SmarterMail users, information on "Setting Up Email Signing" is available in our Help documentation.) Regardless of how you create your record, the following information is part of it:

s -- This is the selector, and it indicates the record "name" used with the domain to locate the public key in DNS. The sender creates this (again, ideally automatically.)

d -- This indicates the domain, used by the sender, that's used with the selector record and helps locate the public key.

p -- This is the actual public key that gets published to DNS as part of the record. Therefore, it will look like a random set of upper and lower case letters, numbers and some punctuation marks.

These are the three key parts of a DKIM record. Other tags are available, but these three are what are the most commonly used. Therefore, a typical DKIM record will look like this:

2B8U4DAB93D58YR._domainKey.yourdomain.com; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg
QC1TaNgLlSyQMNWVLNLvyY/neDgaL2oqQE8T5illKqCgDtFHc8eHVAU+nlcaGmrKmDMw9dbgiGk1ocgZ56NR4
ycfUHwQhvQPMUZw0cveel/8EAGoi/UyPmqfcPibytH81NFtTMAxUeM4Op8A6iHkvAMj5qLf4YRNsTkKAV

In the above, you'll find the following:

Selector (s): 2B8U4DAB93D58YR
Domain (d): yourdomain.com
Public Key (p): MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg
QC1TaNgLlSyQMNWVLNLvyY/neDgaL2oqQE8T5illKqCgDtFHc8eHVAU+nlcaGmrKmDMw9dbgiGk1ocgZ56NR4
ycfUHwQhvQPMUZw0cveel/8EAGoi/UyPmqfcPibytH81NFtTMAxUeM4Op8A6iHkvAMj5qLf4YRNsTkKAV

The other information in the record will be added automatically, but it is generally the same regardless of how the record is created. (I.e., _domainKey).

DMARC

DMARC is an acronym for "Domain-based Message Authentication, Reporting and Conformance". It's an email authentication, policy and reporting protocol that's actually built around both SPF and DKIM. It has three basic purposes:

1. It verifies that a sender's email messages are protected by both SPF and DKIM,
2. it tells the receiving mail server what to do if neither of those authentication methods passes, and
3. it provides a way for the receiving server to report back to the sender about messages that pass and/or fail the DMARC evaluation.

Since DMARC uses both SPF and DKIM, you may wonder why it's even necessary. Well, it's simple: DMARC basically builds on SPF and DKIM to ensure that, when an email is received, the information contained in both records matches the "friendly from" domain (e.g., me@my-domain.com) that the user actually sees and the from address that's contained in the message's header. This is what the folks at Dmarcian, a company founded by one of the primary authors of the DMARC specification, call "Identifier Alignment."

How Do I Create a DMARC Record?

Once you have both SPF and DKIM in place, then it's time to create your DMARC record. The easiest way to do this is to use a DMARC wizard. There are many sites that offer such a tool: MXToolbox, DMARC Analyzer (requires sign up), Dmarcian and more. The Dmarc.org site also provides a list of utilities for generating DMARC records, DMARC lookup and parsing, message validation and more. Most of these sites also have tools to validate your DMARC record once DNS propagation has taken place.

Regardless of the tool you use, a DMARC record utilizes a number of "tags". There are really only 2 tags that are actually required: "v" and "p". Other tags are purely optional, and DMARC experts kind of disagree on which optional tags are recommended and which are not. Let's look at the required tags first:

v -- This is the version tag, just like with SPF. It MUST be "DMARC1" and be the first tag listed in the DMARC record.

p -- This is the policy tag. It tells the receiving server which policy to apply to a message that fails DMARC: "none" or do nothing to a message, "quarantine" a message or "reject" the message.

Optional tags include the following:

pct -- This is the percent of suspicious messages that the DMARC policy applies to. Of course, the default is 100, but it can be set to whatever you want it to be.
rua=mailto:address@company.com -- This tag tells receiving servers where to send aggregate reports. These reports provide visibility into the health of the sending server by helping to identify potential authentication issues or malicious activity. These reports are sent daily, so, ideally, if you want reports sent, they're sent to a mail address set up specifically FOR these reports and not a domain admin account, a user account or any other account that normally receives email for any end user.
fo -- This tag lets receiving servers know that samples of messages that fail either SPF and/or DKIM should be returned to the sender. There are four value options for this tag:

• 0: Generate a DMARC failure report if both SPF and DKIM fail to produce a "Pass" result. This is the default option.
• 1: Generate a DMARC failure report if both SPF and DKIM produce something other than a "Pass" result. This is the recommended option.
• d: Generate a DKIM failure report if the message had a DKIM signature that failed the evaluation, regardless of why.
• s: Generate an SPF failure report if the message failed SPF evaluation, regardless of why.

So what does a DMARC record look like? Let's look at the record for SmarterTools:

v=DMARC1; p=none; rua=mailto:fbl@smartertools.com; fo=1

As you can see, we have both required tags -- v and p -- set, but a few optional tags as well. For our policy tag (p) we have it set to "none". So, we're basically collecting feedback on messages but we're not necessarily "interrupting the flow of messages", even if they fail SPF and/or DKIM. From a DMARC roll out perspective, this is a prudent course of action. That's because while DMARC is a serious way to catch potential phishing emails, it's not a widely-adopted policy. Therefore, many domains don't have SPF or DKIM set up, let alone both. So for the time being, simply watching messages and seeing their disposition, without quarantining or outright rejecting them, is the best way to go about our DMARC implementation.

Are All Three Measures Required?

The most basic answer to that question is "yes" and "no". While SPF and DKIM are gaining wider adoption, DMARC is still something that is taking a while to catch on. That said, prudent email administrators WILL get all three set up for the domains they manage as more and more ISPs and email providers are beginning strict enforcement of all three. As the saying goes, "an ounce of prevention is worth a pound of cure." For email, this has never been more true. Having all three records in place shows that your email domains are truly who they say they are. It also shows that you as an administrator, and your domain administrators as well, are all serious about ensuring you're following best practices and doing your part to prevent spam, phishing and other email security issues.

More Information

SPF: https://www.dmarcanalyzer.com/spf/
DKIM: https://dkim.org/
DMARC: https://dmarc.org/