Domain-based Message Authentication, Reporting, and Conformance (DMARC) and DomainKeys Identified Mail (DKIM) are both security protocols for email. The difference between them, in a nutshell, is that DKIM attempts to verify whether mail is legitimate, and DMARC suggests what to do with mail that isn’t legitimate.

The technical details are more complicated, of course. This article will explore the nuts and bolts of how DMARC and DKIM differ while also pointing out their many similarities. By developing a technical mastery of these underlying technologies, you’ll build a strong intuition about these two protocols, so you never find yourself looking up “dmarc vs. dkim” again.

Before we dive in, let’s review some prerequisite technical terminology to prevent confusion later. 

Public Key Cryptography	A technology used by DKIM to verify the authenticity of mail.
SPF	Sender Policy Framework, a DNS-based mechanism for authorizing IPs to send from a domain.
TXT Record	A DNS record for domain metadata, used for SPF, DMARC, and DKIM
DNS	Domain Name System. The system for looking up basic information about a domain, primarily its IP address.

How DKIM Works

With DKIM, administrators have two keys: a private key that the server uses to cryptographically sign all outgoing emails and a public key that recipients can use to verify that the domain’s real private key signed an email. If the signature verification using the public key is successful, the recipient knows that the secret, private key that only the sender possesses must have signed the email, so the email passes DKIM. The verification also proves that the email has not been altered in transit because if it had been, the signature would not match the content.

DKIM Syntax

DKIM syntax refers to two separate considerations. First, there is the syntax of the DKIM-Signature email header. We won’t cover this part because it’s generated automatically by mail exchange software. The other part is the TXT record, which we must create. It consists of three tags:

• The t tag can either be set to y, meaning this DKIM record is just for testing, or s, meaning that any DKIM-Signature header fields using the “i=” tag must have the same domain value on the right-hand side of the “@” in the “i=” tag and the value of the “d=” tag. Note: the “i=” and “d=” tags are in the DKIM-Signature header, not in this TXT record (for a deeper explanation of DKIM-Signature header tags, see RFC 6376 section 3.6.1).
• The k tag defines what kind of key is used. Currently, RSA is the only key algorithm used with DKIM, so you can safely set this to rsa.
• And finally, the most crucial tag, p, is where the public key goes. 

The record is installed on a special subdomain consisting of an arbitrary name of your choosing (called the “DKIM selector”), followed by ._domainkey. and then your domain name. So if you chose dkimrocks as your selector and your domain was funEmail.test, then the DKIM TXT record would be published at the label dkimrocks._domainkey.funEmail.test.

It’s okay if you don’t perfectly understand yet how to turn this syntax and theory into a practical, deployed policy. In the “Deploying DKIM” section later in this article, we’ll show you how to set up these values and deploy a DKIM record on your domain using Google Workspace. 

How DMARC Works

Unlike DKIM, DMARC is configured entirely in DNS, so no additional server-side work is necessary. DMARC involves two separate functions: reporting and enforcement.

Enforcement refers to what should happen when an email fails DMARC validation. The enforcement options include “none,” which just ignores the failure, “quarantine,” which requests that the email be marked as potentially problematic and usually results in the email being placed in the spam folder, and “reject,” which means that the domain owner requests that the message be rejected.

Reporting, the other prominent feature of DMARC, offers admins visibility into what kind of mail is being rejected because of DKIM and SPF. It’s useful for intrusion detection because we can review reports for signs of spoofing attacks that have occurred. It’s also helpful for debugging because we can see if we are rejecting mail that actually should be accepted.

DMARC offers one additional security benefit. Let’s say a man-in-the-middle attack enabled an attacker to remove the DKIM-Signature header in transit, making it look like the email didn’t have DKIM implemented. If the recipient checks the sender’s DMARC record and finds that a DKIM policy is supposed to be in place, it can assume something has gone wrong and reject or quarantine the email accordingly. Even then, the message may pass DMARC if it passes SPF, even if it fails DKIM. 

DMARC Syntax

Let’s look at the tags that make up a DMARC record one by one, explaining the role of each tag as we go. After briefly touching on each tag, we’ll pull them all together to build a complete example DMARC policy.

The p tag is the most important one. It sets a policy for reacting to non-compliant mail. It can be set to none, which does nothing, quarantine, which flags the mail as suspicious, or reject, which rejects the mail. Note that this will only occur if the mail receiver honors the requested policy.

To manage subdomains differently, we can set a separate policy via the sp tag.

Both ruf and rua point to a domain for reporting, specifying either forensic or aggregate reporting, respectively. 

Two tags, adkim and aspf, specify the required domain alignment for SPF and DKIM, respectively. Their default values are “r”, for relaxed alignment, meaning the domains must have the same organizational domain. Their other possible value is “s” for strict alignment, meaning the domains must be identical. 

Finally, the pct tag defines what percentage of emails should be verified according to the policy. Because this tags default, 100, is what most people want, it’s usually left out.

Given all of the above syntax, how would we craft a simple policy that rejects 100% of non-compliant mail? The simplest way would be like this:

v=DMARC1;p=reject;rua=mailto:postmaster@yourdomain.com

You might notice one tag we never covered: v. This specifies the version of DMARC a policy conforms to. However, only one version currently exists, so the value is always DMARC1.

Setting up DKIM and DMARC

Setting up these protocols on an existing domain is another excellent way to familiarize yourself with their differences. Although both use TXT records in DNS, DKIM also requires integration with the mail server, which creates the verification signatures using the private key and adds them to outgoing email headers.

Let’s see what setting these services up looks like in real life, using Google Workspace for our examples.

Deploying DKIM

Implementing DKIM on Google Workspace is a breeze because the work is almost entirely automated for you by Google. First, log in to your Google Admin Console. To get to DKIM, you’ll have to click through a lot of screens, but then you’ll be all set. Just browse to Apps -> App Settings -> Google Workspace Core Services -> Gmail and finally click on Authenticate email. If all goes well, you should be presented with a screen like the one shown below in Figure 3.

Click GENERATE NEW RECORD. Once the record is created, finish by clicking START AUTHENTICATION. Gmail will set up the appropriate DKIM settings on its mail servers and generate a TXT record for you to paste into your DNS. It will also give you the subdomain that the TXT record should be published on (recall that this subdomain is known as the DKIM selector). 

Deploying DMARC

DMARC is even easier to deploy than DKIM. There is no need to fiddle with any settings in Workspace; just go straight into your DNS settings and add your DMARC record at the _dmarc subdomain. For an example of how this looks in the wild, let’s use the Unix DNS tool dig to see Google’s DMARC policy.

$ dig -t TXT _dmarc.google.com
_dmarc.google.com.    TXT    "v=DMARC1;p=reject; rua=mailto:mailauth-reports@google.com"

We see that google.com has an admirably simple DMARC policy set to reject all non-compliant mail and send aggregated reports to mailauth-reports@google.com. 

Beware of applying Google’s “p=reject ”policy to your own domain when initially deploying DMARC. It’s better to start with a softer policy, like “p=quarantine”, so that messages can get through. An even less committed approach is to set “p=none” with reporting enabled, so you can see what mail gets rejected and why.

Best Practices

Although both protocols aim to make email forgery less feasible, the way they contribute toward that goal is quite different. The difference between their respective goals is what leads to the different syntax covered above. As such, it should be unsurprising that recommended best practices also diverge considerably between the two. Here are some simple tips based on industry consensus.

Don’t Manage Keys Yourself

Some mail providers, notably Gmail and Outlook, offer generic DKIM using a shared key for all users. This is usually the smart choice because attackers will have a harder time stealing data from a large provider like Google. Unless your organization is large enough to compete with Google in defensive strength, or your provider doesn’t offer this, it’s best to avoid managing keys yourself if possible.

Rotate Keys Regularly

If you do manage keys, change them out often. If your provider manages your keys, try to choose a provider with regular key rotation.

In some cases, keys can leak, often without administrators ever finding out. To mitigate the damage done when leaks occur, new keys should be put in place periodically. There’s no broad consensus as to how often, but recommendations vary from one week to one month.

It’s also recommended to publish old keys after they are rotated out of use. Because DKIM cryptographically proves the authenticity of emails, this means it can be used to prove the authenticity of stolen emails. By publishing old DKIM keys, the appearance of a legitimate DKIM signature in stolen emails does nothing to prove their legitimacy, making them less valuable to hackers. For an excellent writeup on the technical details of this kind of attack, check out Ok Google: please publish your DKIM secret keys.

Use a 2048-Bit Key Length

When DKIM originally came out, 512 was the standard key length. Once it became clear that 512-bit keys were easily crackable, domain admins began switching to 1024-bit. However, according to RSA Laboratories:

• As of the year 2010, 1024-bit keys should be considered insufficient, except for legacy support.
• Source: RSA Key Size

So even as of 2010, we see that 1024-bit keys are insufficient. But what do cryptographers have to say about 2048-bit keys?

• It would take a classical computer around 300 trillion years to break a RSA-2048 bit encryption key.
• Source: Breaking RSA Encryption – an Update on the State-of-the-Art (2019)

Thus, the reasonable default should be a 2048-bit key. The only reason to use a 1024-bit key is if you have a DNS provider with a strict character limit for TXT records, which would prevent you from implementing a longer key.

Deploy SPF

Excessive faith in DKIM can be misguided because it’s possible for a sender’s DKIM private signing key to be stolen by attackers, enabling them to pass DKIM verification completely. Domain admins can mitigate this risk by implementing SPF in addition to DKIM. That way, even if DKIM keys are leaked, mail can still be restricted to authorized sending IPs.

Reporting: ruf or rua?

In DMARC, ruf and rua refer to two ways reporting can be implemented (see the section on DMARC syntax above). With ruf, each message that fails DMARC should be reported and sent to an admin, whereas rua sends a periodic report containing aggregated statistics about rejections. However, most providers don’t even send ruf reports, and those that do heavily redact them, rendering them essentially useless. 

Aggregate reporting policy is by far the more popular and common option. It enables easier analysis by centralizing the data into periodic reports, rather than scattering them across many distinct report emails like ruf. Therefore, rua is the preferred reporting mechanism.

Conclusion

DMARC works with DKIM as one way to prevent unauthorized use of a domain in email. DKIM provides strong cryptographic validation of message authenticity and DMARC enables visibility into possible attacks. Beyond security, DMARC also helps debug DKIM misconfigurations thanks to the increased visibility a DMARC report offers administrators into which messages are failing and why. At the end of the day, secure email requires deploying both DKIM and DMARC as well as other essential security mechanisms like SPF.