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:
- Simple canonicalization means that no changes in the email header or body are tolerated.
- 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.
| Tag | Tag description | Required |
| v |
Version of DKIM being used. Currently, version 1 is the only valid version of DKIM. |
Y |
| a |
Algorithm. This is the digital signature algorithm being used for this DKIM signature. |
Y |
| b |
Signature data. This is the digital signature generated for the message. |
Y |
| bh |
Body hash. This is the cryptographic hash value of the canonicalized part of the message body. See the following for more about canonicalization. |
Y |
| c |
Message canonicalization. The only valid values for this optional tag are simple or relaxed. Canonicalization refers to whether the digital signature on the body and header should be processed strictly (simple) or should be processed on content in the headers or body that might have been modified in transit (relaxed). |
N |
| d |
Signing Domain Identifier (SDID). This is the primary domain from which the email is being sent. This value must match the domain under which the DKIM DNS record is stored. |
Y |
| h |
Signed header fields. This tag is a list of the header fields included under the DKIM digital signature. Since some header fields are modified when email is in transit, it is important to include only those header fields that do not change in transit. |
Y |
| i |
Agent or User Identifier (AUID). This tag is optional, used only when the default value, which is the domain part of the SDID domain, preceded by the @ character. The AUID tag is specified to use the same syntax as an email address, and the AUID must uniquely specify the agent or user that is signing for the message. |
N |
| l |
Length of the message body. This value is limited to no more than 76 decimal digits and specifies the number of octets (bytes) in the message body. This optional tag represents the number of octets in the canonicalized body. |
N |
| q |
Query methods. This tag can be used to include a comma-separated list of query methods that can be used to retrieve the sending email server's public key. Currently, the default and only supported value for this tag is dns/txt. This means the DKIM record can be retrieved only through a DNS query, and the retrieved record is all text. |
N |
| s |
Selector. Required for all DKIM records, the selector is used to reference a specific public key used by the email server or email service provider that provides email service for part of the underlying domain. This is the mechanism that enables a domain owner to use multiple public keys to do DKIM signing on messages. |
Y |
| t |
Signature timestamp. This optional but recommended tag contains the time the signature was created, in the form of an integer that represents the number of seconds that have elapsed since 00:00:00 on 1970-01-01 Coordinated Universal Time (UTC), which is the Unix epoch. |
N |
| x |
Signature expiration. By default, DKIM signatures do not have an expiration period. The value of this tag is the number of seconds that elapse between 00:00:00 on 1970-01-01 UTC and the time and date when the signature expires. This tag is optional but recommended. |
N |
| z |
Copied header fields. This optional tag includes all the header fields and their contents that were included in the message signature. Header fields in this tag are each separated by a vertical bar (|). |
N |
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:
| Tag value | Explanation |
| v=1 |
DKIM version 1 is in use. |
| a=rsa-sha256 |
The SHA-256 secure hash algorithm is used to generate the message digest value, which is then digitally signed using the Rivest-Shamir-Adleman, or RSA, signing algorithm. |
| d=example.net |
The domain owner for the domain example.net claims responsibility for the message. |
| s=boston |
The DKIM selector boston should be used to determine which DKIM public key should be used to authenticate the message. |
| c=simple |
Simple canonicalization should be used, and the message signature should be strictly interpreted when authenticating. |
| q=dns/txt |
In this case, dns/txt is the only valid value for this query method tag, indicating that the DNS TXT record lookup algorithm must be used to retrieve the DKIM public key. |
| This indicates the individual (entity or person) associated with the authenticated message. This value is used to query the public key needed to authenticate the message. |
|
| t=1143894938 |
The timestamp value is the number of seconds elapsed between 00:00:00 on 1970-01-01 UTC and the time at which the signature is created. |
| x=1118003238 |
The signature expiration time value is the number of seconds elapsed between the 00:00:00 on 1970-01-01 UTC and the time at which the signature is no longer considered valid. |
| h=from:to:subject:date |
These are the header fields that were included in the DKIM signature. |
| z=From:[email protected]|To:[email protected]| |
These are the email headers that were included when the message was digitally signed. In this example, the header names were capitalized, e.g., From:. If the header names were changed to lowercase and the canonicalization was set to relaxed, the recipient would authenticate the message correctly. |
| bh=EyMzQ0NTY3ODkwMTIMTIzNDU2Nzg51Njc4OTAxMjMMD |
This is the canonicalized hash of the message body. |
| b=dzdVyOSlEnfAKCdLXdJOc9G2qzGeeruD08LoXiSbav+ |
This is the DKIM signature itself. This digital signature was generated on the canonicalized hash of the message body. |
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.
