DELIVTERMS: DomainKeys Identified Mail (DKIM)

DomainKeys Identified Mail (DKIM)
is an email authentication protocol. It is one of two different types of email authentication, the other being known as Sender Policy Framework (SPF). DKIM uses a public/private key pair to generate a cryptographic signature for an email message, and the signature information is stored in a hidden “DKIM Signature” email header. The signature allows a receiving mail server to confirm that the message body (and various email headers) were not modified (that is to say, this is truly what was sent by the sender), and they also effectively identify the sender, when the domain name of the sender is the domain name used in the signature.

A public/private key pair involves both a private key, which is a bit of information kept private by the sender, configured to be used by the sender’s mail server or mail sending platform, as part of the signature generation process, and a public key in DNS, a bit of information queryable by anyone, used as part of the signature validation process by any mailbox provider or internet service provider (ISP) receiving the signed email message.

A DKIM key can vary in size, and you’ll see sizes like 512 bits, 1024 bits or 2048 bits. The larger the key size, the (theoretically) harder it is to crack (guess) the DKIM private key, which would allow a bad guy to sign emails as your domain that would verify successfully. Key size used to also impact email sending infrastructure; slow hardware signing many messages with a higher-bit key meant slow email sending; this is no longer a concern today, but it might explain why you might see some lower bit DKIM keys out there somewhere. Current best practices require that senders use a 1024-bit key or larger. (512 bit keys were mostly driven out of existence by Google.)

There was an older version of this email authentication protocol called “DomainKeys,” created by Yahoo. DKIM is meant to replace DomainKeys.

For an email message to pass DMARC checks, it must successfully authenticate with DKIM or SPF; it isn’t required that it authenticate with both; but it’s always best to configure both, if possible, so that the other protocol can be available as a backup mechanism to authenticate an email message, if SPF or DKIM checks fail for a given message.

Want to learn more about deliverability terminology? If so, be sure to visit the DELIVTERMS section here on Spam Resource.

Post a Comment