DKIM Validation: An Email Authentication Best Practice. Email authentication ensures the recipient can verify that a message genuinely comes from the claimed sender, providing trust and security.

• DKIM (DomainKeys Identified Mail) is a content-based email authentication method that verifies whether a message was altered after it was signed.
• Unlike SPF, which validates the sending path, DKIM validates the message content itself using cryptographic signatures.
• DKIM uses two keys: a private key to sign outgoing messages and a public key published in DNS for receivers to validate signatures.
• A DKIM signature includes hashes of both the headers and body, selectors, timestamps, and identity fields — all of which the receiver must reproduce and verify.
• DKIM validation relies on receiving the entire message first, meaning failures can occur late in the process.
• Troubleshooting failed DKIM validations is often difficult because senders and receivers cannot reproduce each other’s signing/verification environments.
• Even when DKIM fails, it typically does not directly cause inboxing issues on its own unless combined with other negative reputation signals.

• What does DKIM actually do?DKIM attaches a cryptographic signature to an email, allowing the receiving server to confirm whether the message content was modified after it was sent.
• How is DKIM different from SPF?SPF validates who is allowed to send mail for a domain (path-based).
• DKIM validates whether the content is intact (content-based).

Both serve different purposes and complement each other.

• What is inside a DKIM-Signature header?Key fields include:v= version
• a= algorithm
• c= canonicalization rules
• d= signing domain
• s= selector
• h= headers included in the signature
• bh= body hash
• b= actual signature data

Each part contributes to how the signature is validated.

• How does a receiving server validate DKIM?Extracts the d= and s= values.
• Looks up the public key at: selector._domainkey.domain
• Regenerates header and body hashes and compares them to the bh= and b= values in the DKIM-Signature header.

Unlike its authentication counterpart SPF, which provides a way for a domain to authorize a host to send mail on its behalf, DKIM provides a way for an entity (domain, organization, person, etc.) to take responsibility for a message, independent of the entity that actually sent the message. While in many cases the responsible entity and the sending entity will be the same, or at least closely related, with DKIM there’s no requirement that this be so.

My goals for you with this post are that you learn and understand the following concepts about DKIM:

• DKIM is a "content-based" authentication, unlike the "path-based" SPF.
• The responsible entity asserts its responsibility by "signing" the message with a pair of cryptographic hashes inserted in a message header.
• DKIM validation is done by the receiving domain attempting to generate the same two hashes.
• DKIM validation cannot be completed in many cases until the full message has been transmitted by the sending server.
• Validation failures can be difficult to troubleshoot.

DKIM is referred to as "content-based" authentication, rather than "path-based", because whether or not a message passes DKIM validation is based solely on whether or not the content has changed between the time it was signed and the time validation was attempted.

Organizations wishing to DKIM sign mail will first generate two cryptographic keys. One of the keys is kept private and available to the sending server for the signing of mail, and the other is to be made public in DNS for use by receiving domains in attempts to validate the signature. The methods for generating these keys and installing them are platform-dependent and beyond the scope of this post, although later I will describe the publishing in DNS of the public DKIM key.

To begin our understanding of DKIM, let’s first look at a DKIM-Signature header:

DKIM-Signature: v=1; a=rsa-sha256; d=welcome.foo.com; s=notices; c=relaxed/relaxed; q=dns/txt; i=@welcome.foo.com; t=1454417737; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=;

In addition to the requirement mentioned that the i= domain must be the same as or a sub-domain of the d= domain, the d= and s= bits are used by the validator to look up the signer’s public DKIM key in DNS. The key is a TXT record in DNS, and it’s always found at the location selector._domainkey.domain. So, in our example here, with s=notices and d=welcome.foo.com, the public DKIM key would be found in DNS at notices._domainkey.welcome.foo.com, and it might look something like this:

notices._domainkey.welcome.foo.com. descriptive text "v=DKIM1; h=sha256; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB; s=email"

I mentioned above that DKIM failures can be difficult to troubleshoot, and I’ll explain why that’s so here.

Some DKIM validation failures have obvious causes, such as the message not being signed, or the signing domain’s public key not being found in DNS or not being syntactically correct, or perhaps the message was obviously altered in transit. When those kinds of failures happen, it’s easy to figure out the problem and recommend a solution. The tough ones, though, and the ones which lead to the most frustrating support experience, are the cases where the message was signed, the public key exists in DNS, and the message wasn’t obviously altered, but the validator reports that the signature failed to validate.

The reason that these are tough to troubleshoot is because there’s no real way for either side to reproduce the conditions under which the message was signed and validated. The message has in its DKIM-Signature header the hashes that were generated by the signer at the time of signing, but the validator likely has no access to the signer’s infrastructure and so cannot try to reproduce the signature under the signer’s conditions. Similarly, the signer likely has no access to the validator’s infrastructure and so has no way to try to validate the message in the way that the validator did.

Failures like I’m describing here are rare occurrences, and DKIM validation failures by themselves usually don’t have an impact on delivery placement. While DKIM handles message authentication, implementing comprehensive email validation techniques ensures you're sending to legitimate addresses that can actually receive and authenticate your messages. It’s been my experience that such failures drive more support tickets than any other kind of DKIM issue.

Read more from this category

Dec 19, 2016SPF Authentication: An Overview and Best Practices