DomainKeys Identified Mail (DKIM)

What is DomainKeys Identified Mail (DKIM)?

DomainKeys Identified Mail (DKIM) is a protocol for authenticating email messages using public key cryptography to protect against forged emails. Using DKIM signatures in message headers helps improve email deliverability and email security by differentiating legitimate email from fraudulent email, such as business email compromise and phishing scams.

Organizations that send email can use the authentication standard defined by DKIM to add a digital signature to the header of each email they send, and organizations that receive email can authenticate those emails. DKIM is an especially effective email authentication method because it can detect forged emails using strong cryptographic authentication on each individual message.

The DKIM protocol is specified in Internet Engineering Task Force RFC 6376, DomainKeys Identified Mail (DKIM) Signatures. DKIM gives the entity that owns the signing domain the ability to claim responsibility for messages by associating them with the domain. The protocol enables the sending domain to sign outgoing messages using DKIM.

DKIM signatures are different from message-signing protocols, such as Pretty Good Privacy or Secure/Multipurpose Internet Mail Extensions, or S/MIME, which enable end users to authenticate messages. Those digital signatures are incorporated into the message body. While they authenticate the message body, they say nothing about the system sending the message.

In contrast, DKIM signatures are incorporated into the message headers of authenticated emails, not generated or authenticated by end users. Instead, DKIM signatures are generated by the sending mail server and authenticated by the receiving mail server.

Along with the Sender Policy Framework (SPF) and Domain-based Message Authentication, Reporting and Conformance (DMARC) protocols, DKIM helps email providers and enterprises validate email and prevent their email domain from being highjacked and used for phishing scams, email spoofing and other malicious email-based attacks.

The SPF, DMARC and DKIM email validation and authentication protocols work together as follows:

• The SPF protocol enables an email-sending organization to identify the email servers authorized to send email on behalf of the organization's domain. SPF records information about authorized email servers in the sender's domain name system (DNS) records, which are accessible to any internet-connected system. SPF is especially important for email service providers -- notably, Google Gmail, Yahoo email services and others -- that send and receive email for many different organizations.
• The DKIM protocol enables an email-sending organization to digitally sign each individual message sent by an authorized email server. DKIM relies on SPF to identify whether a message was sent by an authorized email server and relies on DMARC to determine the appropriate policy when an email message fails authentication.
• The DMARC protocol enables an email-sending organization to specify the procedures receivers should take when they receive email that has not been authenticated. When an email server not listed in the SPF record attempts to send a message or when DKIM authentication fails, DMARC policies provide guidance to the receiver as to whether the message should be delivered, quarantined -- i.e., sent to spam folder -- or rejected entirely.

DKIM, SPF and DMARC publish all the information used to authenticate email in DNS TXT records. DKIM publishes the public key used to do DKIM authentication of individual emails. SPF publishes information about the email servers authorized to send email for a domain, and DMARC publishes its policies for unauthenticated email.

What is a DKIM key?

DKIM enables email senders to publish the public key of the domain owner's public key pair.

Email senders using DKIM publish their public key to a DNS TXT record associated with the domain from which email is being sent. The receiving mail server uses this public key to authenticate the digital signatures added to email headers from the sending domain.

What is a DKIM record?

DKIM, like SPF and DMARC, uses DNS TXT records to store data used for email authentication. DKIM records include the protocol version -- 1, for DKIM version 1 -- and the public key to be used to authenticate email sent by the domain owner.

Unlike SPF and DMARC records, DKIM DNS TXT records also include a selector, which is a value that links an email service provider with the domain under which email is being sent. In this way, the email-sending organization can use multiple email services, each of which has its own public key.

DKIM record names use the following form:

[selector]._domainkey.[domain]

Prepended to the sending domain are the following:

• _domainkey. This string in the DNS TXT record name specifies it is a DKIM record.
• [selector]. The DKIM selector links the DKIM record with a specific public key used by the email server or email service provider that provides email service for part of the underlying domain.

An example of a DKIM record name for the domain example.net and mail sent through the Gmail email service using the selector gmail might look like this:

gmail._domainkey.example.net

Key length presents a challenge recording public keys in DNS. While modern recommendations call for minimum key lengths of greater than 256 bits, DNS records can't handle strings longer than 255 bits. The solution is to split public keys longer than 255 bits into multiple strings of fewer than 255 bits each.

What is a DKIM signature?

Messages with a DKIM signature are identified by the presence of the DKIM-Signature: header field, which conforms to the standard defined in RFC 5322, Internet Message Format. Any email server that supports DKIM processes the DKIM signature appropriately, based on the data included in the DKIM signature header field.

DKIM signatures include the digital signature itself, along with other information related to the signature. DKIM header tags, which are fields that contain necessary data about the signature, are listed in the first table below.

Header and body canonicalization

One of the challenges of using digital signatures on email is that some email servers modify email that is in transit. Examples of those modifications include the following:

• changes to the way email header fields wrap, for example, adding carriage returns to break up longer headers; and
• changes in the way servers treat white-space characters -- i.e., spaces, tabs and carriage returns.

The concept of canonicalization, or specifying which parts of the message should be considered canonical or officially part of the signed message, in DKIM enables the domain owner to specify how strictly the digital signature must be interpreted, based on the received email. Canonicalization can be applied separately to the message headers and the message body. The two options are the following:

1. Simple canonicalization means that no changes in the email header or body are tolerated.
2. Relaxed canonicalization means that common modifications -- specifically, changes to the way headers wrap and the way white-space characters are treated in the body -- are acceptable.

For relaxed canonicalization, receiving email servers must use specific algorithms to reverse any modifications that may have been applied to a message between the time it was signed and the time it was received.

DKIM signature syntax

The DKIM-Signature: header field includes its own tags as described in this table. Tags are components of the DKIM header, separated by semicolons as shown in the example below.

DKIM-signed messages are signed with the private key associated with the DKIM public key. Domain owners can authorize more than one public key pair to authenticate email from different subdomains or delegated servers, but each domain, subdomain or delegated server can use only one public key pair.

DKIM signature example

DKIM signatures begin with the string DKIM-Signature: followed by tag values, separated by semicolons.

DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=boston; c=simple; q=dns/txt;
[email protected];t=1143894938; x=1118003238; h=from:to:subject:date;
z=From:[email protected]|To:[email protected]|Subject:demo=20run|Date:July=2015,
=202015=213:42:09=30PM=20-0700; bh=EyMzQ0NTY3ODkwMTIMTIzNDU2Nzg51Njc4OTAxMjMMD=;
b=dzdVyOSlEnfAKCdLXdJOc9G2qzGeeruD08LoXiSbav+yuU40lszZVoG4ZHRNiYzR

The tags in this example are explained in the following table:

How does DKIM work?

A DKIM DNS TXT record is a domain name record that mail-originating organizations can use to advertise their public key. This public key is used to digitally sign mail sent on behalf of a mail-originating domain's organization. DKIM records are used in conjunction with SPF and DMARC:

• SPF enables the organization to specify which IP addresses are linked with authorized email servers.
• DMARC policies determine the next action for the receiving email server.

When an email server receives a message with a DKIM signature in the header, the receiving server does the following:

• There is a DNS query on the sending domain to retrieve the SPF DNS TXT record for the domain. This record identifies domain names and IP addresses of email servers authorized to send email on behalf of the owner of the domain.
• There is a DNS query to retrieve the DKIM DNS TXT record associated with the DKIM signature. This public key is used to authenticate the DKIM digital signature.
• If the message was sent from a domain not authorized under SPF or if the message signature failed to authenticate under DKIM, the recipient does a DNS query to retrieve the DMARC DNS TXT record associated with the domain owner. The DMARC record assigns policies.

DMARC policies tell the recipient what next step to take, which may be the following:

• None. No special action needed. This option is usually used when first implementing email authentication protocols. Failed email under this policy is not treated differently from authenticated email, but the failure can be reported to the sender.
• Quarantine. Put the unauthenticated email in the recipient's spam folder. This policy may be used for email that appears suspicious but might be legitimate. It may also be used as an intermediate measure during email authentication implementation.
• Reject. Discard email without delivering it. This policy is used when SPF and DKIM verification are completely implemented and shown to be reliable at stopping phishing attacks, spam and other suspicious or malicious email.

While it might be possible to implement DKIM on its own, the overall effectiveness of DKIM signatures is reduced without implementing SPF and DMARC, too. DKIM depends on SPF records to determine whether a message originates from an authorized email server. Many of the benefits of DKIM, such as being alerted to attacks by spammers and other malicious actors, depend on the use of DMARC to request reports about emails that failed to authenticate.

Forms of phishing come in different varieties, from vishing to spear phishing to whaling, but tips to defend against phishing attacks can help employees avoid them.