Recommendations for DKIM Signing

This article gives recommendations for DKIM signing parameters based on operational experience. As of 2023, it is advisable to use RSA/SHA-256 as signing algorithm with a key length of 2048 bits. Optionally, Ed25519/SHA-256 can be used in addition to the RSA signature (not as replacement).

Signing Algorithm

Use either RSA only, or RSA together with Ed25519. There are currently two signing algorithm specified for use with DKIM: RSA and Ed25519. The latter has been introduced with RFC 8463 in 2018. While some senders use Ed25519 along with RSA, almost nobody supports Ed25519 verification on the receiver side yet. It is thus advisable to use RSA for DKIM signing. If you like to be equipped for the future, you can double-sign messages with both, RSA and Ed25519. Double-signing requires the use of separate selectors for different public keys.

Hash Algorithm

Use SHA-256. Originally, DKIM also supported SHA-1. This is no longer allowed due to cryptographic weaknesses in SHA-1.

RSA Key Length

Use 2048 bits. Originally, RFC 4871 in 2007 required DKIM verifiers to support RSA keys ranging from 512 to 2048 bits (and optionally larger ones). RFC 8301 raised this requirement in 2018 ranging from 1024 bits to 4096 bits. While most receivers support keys with 3072 or 4096 bits, there are many corporate, governmental, and academic mail receivers that do not support more than 2048 bits. This is due to a restriction of the Cisco Secure Email Gateway (formerly Cisco IronPort ESA) and the corresponding cloud service hosted under

The email gateway supports keys from 512 bits up to 2048 bits. The 768 - 1024 bit key sizes are considered secure and used by most senders today. Keys based on larger key sizes can impact performance and are not supported above 2048 bits.

This product is widely used, therefore it’s not advisable to ignore its restriction if you care about email deliverability. Cisco’s recommendation is outdated, though. 1024 bits RSA is not state of the art anymore. 2048 bits is a safe choice between security and compatibility.

Key Change Interval

It depends. With an automated process for generating and publishing a new DKIM key, it is possible to replace the key every few weeks. This is too much of an effort when DNS changes are applied manually. With 2048 bits RSA, it is safe to replace the key every one to three years.

When switching keys, the old key must remain online while emails signed with it are still in transit. This may take a few days in case of queueing due to temporary errors. Always use a new selector; do not reuse selectors for different keys. As DKIM is a transport-level authentication method, the signature and corresponding key are not needed after an email has been delivered to its final destination. It is thus safe to remove an old DKIM key from DNS after about one week of its last signing usage.


Use c=relaxed/simple or c=relaxed/relaxed. The “relaxed” canonicalization applies a normalization algorithm before signing and verifying, which gives more leeway for whitespace modifications of the signed email than the “simple” canonicalization. The c= field has two values, one for message headers and one for the body. It is advisable to use the “relaxed” canonicalization for message headers, because whitespace alteration of headers are observable in practice. I have not seen a whitespace modification of the body yet and thus cannot make a case for the body canonicalization.

Publication of Private Key

Some privacy advocates argue to publish old DKIM private keys that are not used for signing anymore. The purpose is to ensure deniability of old messages. If someone leaks an old private email signed with DKIM, having published the private key gives you the freedom to deny its authenticity. Whether this is desirable, is outside the scope of this article.

Test Your DKIM Setup

Test the DKIM-Signature of your outgoing emails with the DKIM Test.