DomainKeys Identified Mail (DKIM) is a method to cryptographically sign email. The goal of DKIM is to reduce email spam and fraud. Email services use DKIM as one of the methods for determining the authenticity of an email.

With DKIM the sending email service adds a cryptographic signature to the email headers using the sender's private key. This signature is used by the receiving service to determine if the sender, and the email content, are to be trusted.

The domain willing to use that email service (that's you) publishes the public key of the sender in the DNS of the domain. By doing so you indicate to the receivers that a sender that holds the corresponding private key is to be trusted to send email for the domain.

DKIM is considered an improved mechanism over SPF because it also protects the email content from tampering, and it doesn't suffer from the problems with email forwarding that SPF has.

Cryptographic signatures

To understand how DKIM works, you first need to understand what cryptographic signatures are, and how they work. If you are already familiar with cryptographic signatures and Public Key Infrastructure you can skip this segment.

A cryptographic signature is different from a 'human' signature.

A human signature is a handwritten scribble (like someone's name, or even an 'X'). If placed on a document, it proves (to certain extent) the identity and intent of the signer.

A cryptographic signature is a (very long) number that uniquely and mathematically matches the information that was signed. The signed information can be anything that can be digitally represented, such as a document, email or financial transaction. The cryptographic signature proves identity and intent of the signer, and also authenticity of the signed information.

A cryptographic signature is created by applying a mathematical function on the information to sign in combination with a cryptographic key. The key consists of two parts (represented as long numbers) that are mathematically linked to each other. One part is called the private key, it is meant to be kept secret by its owner. The other part is called the public key, and like the name suggests it is public (not secret) information. Here comes the clever bit: a cryptographic signature can only be created with the private key, but it can be validated by anyone with the public key.

You can sign a document with a private key, and publish the resulting signature along with the document and the public key. Anyone can use the public key to validate that the signature was created with the corresponding private key. This scheme is called a Public Key Infrastructure (PKI), it allows for anyone to validate a signature without needing access to the private key.

Unlike a human signature, a cryptographic signature is unique to the information that is being signed. For every document and key combination there will be a different and unique signature. If a single letter in a signed document was to be changed, the signature would no longer be valid for that document. This means that a cryptographic signature can be used to check if a signed document is authentic, thus has not been tampered with. This also makes copying a cryptographic signature pointless, as it will only be valid for the original email.

Human signature Cryptographic signature
Representation Handwritten Large number
Proves Identity, intent Identity, intent and authenticity
Proof Judgment Math
Forgeability Easy Very hard to impossible


DomainKeys Identified Mail (DKIM) leverages Public Key Infrastructure (PKI) to cryptographically sign email. The signature proves that the email is authentic and that the sender was authorized to use the domain name in the sender address. DKIM is defined in RFC6376.

To use DKIM, an RSA key pair is created by the service that sends the email. This can be an on-premise email service, but also a third party cloud service such as Microsoft 365 or Mailchimp. The private key is kept secret by the sending service, but the public key is shared with anyone willing to implement this service.

A domain administrator publishes the public key of the sender through DNS as a DKIM record. By doing so, the domain is allowing the sending service to use that domain as the sender address.

The sending service automatically adds a cryptographic signature to every email that it sends using the private key. Any email service receiving the email will request the public key through DNS, and validate the signature using that public key.

If the signature is valid, it proves that:

By publishing a DKIM record in a DNS zone, the domain is saying "Any email service that holds the private key that corresponds to this public key is allowed to send email for this domain."

By adding a DKIM signature to an email, the sender is saying "Here is proof that I have access to the private key"

By validating a DKIM signature of an email, the receiver is saying "I have found proof that this email is authentic and the sender was authorized to send email for this domain"

The DKIM DNS record

The public key to validate the DKIM signature is published in a DNS record for the domain. A DKIM record is of type TXT and must be placed at address [selector]._domainkey.[domain]. The selector is an identifier for the DKIM key, more about this later.

A DNS query on [selector]._domainkey.[domain] may only result in 1 TXT type record maximum. If you have multiple keys, you can publish each corresponding public key with a different selector. That way different private keys can be used to sign the email. For example: You can have a key for an on-premise email service and one for a third party such as Mailchimp.

DKIM keys are not meant to ever change. If you need to use a new DKIM key, you should use a new selector also. Because DKIM records never change they can have a high time-to-live (TTL) value. A TTL of 1 day (86400 seconds) or more is not uncommon for DKIM records.

Here is an example of a DKIM record: 86400 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAgAF0AKrnAY2oscOh7jlBBPJDHgWO/HR/TxPr18yG6uFs3jVLkz1qZpI0QJX90aVnpPiu1C+6MZzUwzYYY/f8g8rVGxwj2D/anjih4sKUFmun2IluFiS93RcPZXYWNXor4gALdsdAVB7ak4/30l0uVAU3OEwFX77yWNT6BDSiobfpKMDG4TV4iZiohOlc1gHHX" "HYbLbcQ1uM9CLPkuqHKQkudLjvAbvl0eqDtAzThAahsmhl5Lc7Qru1SJShv47RxzIxShBL6MGTxEGiIR09244oQf++CmKCT8TPxptT/Y6mrLO5+t//dlvSVLsrKhF6xqZWwSOL0pskJiDdqDAxDGQIDAQAB"

We have a DKIM validator tool available here, you can use it to inspect and validate a DKIM DNS record.

Field specification

The following information can be placed within a DKIM record:

Field Required Description
v Optional The version field. The default is DKIM1, which is currently the only acceptable value.
h Optional A colon-separated list of acceptable hash methods to be used with this key. Current supported methods are sha1 and sha256.
k Optional The type of key. Valid values are rsa or ed25519 (see: How to use DKIM with Ed25519. Defaults to rsa.
n Optional Notes for the record, such as an identifier. Intended for humans (administrators), validators ignore this value.
p Required The public key data, BASE64 encoded.
s Optional A colon-separated list of types of services intended to be used with this key. Allowed values are * (all services) or email. Defaults to *.
t Optional A colon-separated list of flags for this key. Supported values are 'y' to indicate this is a testing key. And 's' to require strict domain validation (this key is not valid for subdomains).
g Deprecated The 'granularity' of the DKIM key. Intended to limit domain use of the key. Deprecated, do not use.

The selector

Every DKIM record must have a unique identifier known as the selector. The selector is part of the address that is used to query the DKIM record in the DNS. A DKIM signature in the headers of an email will also contain this selector, so the receiver knows where to query the DKIM DNS record.

Since the selector is used as the DNS name of the DKIM record, it can contain only characters that are valid for a domain name. So a maximum of 255 characters containing letters, numbers and hyphens (-).

Spaces, dots, and underscores are not allowed. As with all DNS names, a selector is not case-sensitive.

Because the v=DKIM1 part in the DKIM record is optional (unlike, for example, the version indicator in a DMARC record), there is no way for a validator to distinguish a DKIM record from any other TXT type DNS record. It is therefore required that a DNS query on the selector address yields no more than one TXT record.

The DKIM signature header

An email message consists of 2 parts:

The headers contain information such as the date, subject, return address and more. The headers are used by email services and clients to process the email. Most email programs will hide the headers from the user.

When using DKIM, a DKIM-Signature header is added to the email that contains the DKIM signature, and other implementation details instructing the receiving service on how to validate the signature.

The DKIM header is added to an email by the sending service. An email message may contain more than one DKIM header, as an email can be signed by multiple parties and by multiple keys.

Here is an example of an email with a DKIM header:

From: John Doe <>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=subject:from:to; 
    s=selector1; bh=edgxW+m2NmYw6Pxq6wY+B9YA+Z8SvmZ+y5zRCKxm6ik=; b=ClVxK8f
Subject: This email is signed with DKIM

This is an email signed with DKIM

In the sample email message the DKIM header was added by the sender in order to prove that the service that sent the email was really allowed to send email on behalf of

The DKIM header contains the domain name, and the selector s=selector1. This means that the receiver is supposed to query the DNS service for a DKIM TXT type record at

The bh field contains the BASE64 encoded hash digest of the email body. The h field indicates which headers of the email were also included in the signature input. The a=rsa-sha256 indicates that the SHA256 hash function was used to create the digest. Finally, the b field contains the BASE64 encoded RSA signature.

Field specification

Here is the full list of fields that can be used in the DKIM-signature header:

Field Required Description
v Required The version field. This is a numeric field, currently the only supported value is 1.
a Required The signature and hash algorithms used to create the signature, in format [sig]-[hash]. The recommended algorithm is rsa-sha256.
b Required The signature data, BASE64 encoded, created with the algorithm defined in a.
bh Required The BASE64 encoded hash digest of the message body, created using the algorithm defined in a.
c Optional The message canonicalization method used, default is simple/simple.
d Required The domain claiming responsibility for this signature. This is the domain that is queried for the DKIM DNS record to obtain the public key.
h Required A colon separated list of the email headers that were included during creation of the signature.
i Optional Email address claiming responsibility over the created signature. The domain part in the address (after the '@' character) must match the value in d.
l Optional Body length in octets used as input for the hash function, defaults to the entire message length.`
q Optional The method to retrieve the public key. Defaults to txt/dns, which is currently the only allowed value.
s Required The public key selector, together with the d value this determines the address for the DNS query to fetch the DKIM DNS record.
t Recommended A UNIX style timestamp of the time when the signature was created. If not set, the creation date is unknown.
x Recommended A UNIX style timestamp of the expiration of the signature. After this date a validator should no longer accept the signature. If not set, the signature never expires.
z Optional A vertical-bar (|) separated list of all email headers that were present during creation of the signature.

SHA1 deprecation

To create a cryptographic signature, the email contents are first ran through a hashing function, which outputs a hash digest. This is a fixed length value that is (or should be) unique to the message content. In a well-designed hashing method, when a single letter in the email is changed, the hash digest should change completely, this is known as the 'avalanche', or 'waterfall' effect. With a good hashing method, it should also be unfeasible (impossible) to find an input (other than the original email message) that would hash to the same digest, this is known as finding a 'collision'. With these two properties of a hashing function, it should be impossible to craft an email with a valid DKIM signature without having access to the private key.

At the time when the DKIM standard was drafted, SHA1 was widely accepted as a cryptographically strong, collision resistant hashing method. As such, SHA1 was selected as one of the supported hashing methods for DKIM.

However, in the years following the release of the first DKIM standard, researchers found weaknesses in SHA1 that would allow for calculating collisions. With a collision, it is (in theory) possible to craft an email message that matches a known good signature, meaning that you can send DKIM valid email messages without access to the private key.

Due to this weakness, SHA1 is now widely regarded as cryptographically unsafe. SHA1 is therefore deprecated, meaning that it should no longer be used for any application.

Within the scope of email, there are many legacy systems that may still sign with SHA1, so it is recommended that DKIM validators should still accept SHA1 hashes. For DKIM signers, it is strongly recommended to use SHA2-256 as the hashing method.

It is possible for a domain to force rejection of SHA1 based DKIM signatures by adding h=sha2 to the DKIM DNS record. This indicates to DKIM validators (the receiver) that only SHA2 based hashes are acceptable for this key. But, the DKIM signer (the sender) is still the one who dictates which hashing method is used, though they should no longer use SHA1 due to its deprecation, they may still be using SHA1 for legacy reasons. So, before adding h=sha2 to a DKIM DNS record, it is recommended to contact the vendor of the sending service first, to verify that they are using SHA2 exclusively.

Debugging DKIM issues

Debugging DKIM issues can be frustrating, as email services (by design) do not give feedback when email is rejected.

If you are experiencing DKIM related issues with one of the services you are using to send email on behalf of your domain, there are some simple steps to take to debug the issue.

The easiest method is by sending yourself an email from the service you are experiencing problems with, then inspect the email headers using your email client.

  1. Verify that the sender address (in the From header) is actually set to your domain. This means that the part of the sender address after the '@' sign must match your domain.
  2. Verify that at least one DKIM-Signature header has your domain in the d= section of the header.
  3. Verify that the correct selector is used in the s= section of the DKIM-Signature header found in step 2.
  4. Verify that the DKIM selector exists at [selector]._domainkeys.[yourdomain], and that it is a valid DKIM record. You can use our DKIM record validator to verify the record is valid.

Most inbound (receiving) email services will add debugging headers to the email before delivering it to the inbox. Check if you can find a Authentication-Results header, it should contain information on SPF, DKIM and DMARC results, and whether the validation has passed or failed.

Note that a DKIM header may be found valid, but that does not necessarily imply the email is DKIM aligned, see more about DKIM alignment in the section below.

DMARC DKIM alignment

As DKIM is optional to use in email, a malicious sender may just send email without a DKIM-Signature header, or just send the email with a DKIM-Signature for a domain that they control.

To mitigate this weakness in DKIM, DMARC may be used to mandate that any email received claiming to be from your domain, must be at least SPF or DKIM aligned.

DKIM alignment means that there must be at least one DKIM-Signature with the d= value set to the domain that is used in the RFC5322.From address (in the From header).

An email containing a DKIM header for a different domain than the one used in the From header is considered DKIM verified, but not DMARC aligned.

Example: An email with a From: header, that has a valid DKIM signature with is not DMARC aligned, even though the DKIM signature is valid.

Advantages of DKIM over SPF

As explained in our document about SPF, SPF is also used to authorize an SMTP service to send email on behalf a domain. So why use DKIM, if SPF is much easier to set up?

This does not mean that DKIM is a replacement of SPF. SPF should still be used as it is a quick and effective method for receivers to perform basic verification of email.


DKIM is, especially when combined with DMARC, a very effective email hardening technique.

With DKIM, both the authenticity of the email message, and the authorization of the sender are proven to the receiver, which allows for effective fraud prevention. DKIM is a vast improvement over SPF, which has many safety and practicality issues.

Domain administrators should always strive for 100% DKIM coverage for all email sent from the domain. DKIM coverage can be verified and monitored by using DMARC reporting with a DMARC report aggregation service such as Mailhardener.

Further reading



Share your thoughts!

On last thing: If you have questions, comments or thoughts on this article, don't hesitate to shoot us an email.

You can also follow and reach us on Twitter @Mailhardener.

With Mailhardener you can configure, validate and monitor your domain for all aspects of email security. Mailhardener is free to use for a single domain.
Sign up now