DKIM
DomainKeys Identified Mail / email signing / DKIM selector / key rotation
DKIM attaches a cryptographic signature to a message so a receiver can confirm the signed parts were not altered. The standard describes it as a domain claiming some responsibility for the message, and it separates the signer from the purported author. Modifying a message in transit breaks the signature.
The specification chooses its words carefully. DKIM lets whoever owns the signing domain claim some responsibility for a message, by tying the domain to it. That party can be the author's organization, an operational relay, or one of their agents. Then comes the sentence that explains why another layer had to exist. DKIM separates the identity of the signer from the purported author of the message.
So a valid signature tells you a domain vouched for this message. It does not tell you that domain is the one in the From line your customer reads.
Microsoft describes the mechanics plainly. The primary purpose is to verify that a message was not altered in transit. A private key on the sending system signs important parts of the message. Those parts include header fields such as From, To, Subject, Date and Content-Type, plus the message body. The result is stored in a DKIM-Signature header.
The public half lives in DNS, in records Microsoft calls selectors. Only one selector is active at a time. The second exists so keys can be rotated, and it is activated only after a rotation, once the original has been switched off.
In practice
The failure is predictable, and it is not a misconfiguration. Microsoft lists DKIM failing after message forwarding. The cause it gives is the body or headers being modified by an intermediary, and the fix is to configure that intermediary as a trusted ARC sealer. Anything that appends a footer, rewrites links or reformats a message can invalidate a signature that was good when it left. The specification expects this. It says consumers should not judge a message solely on a missing or unverifiable signature, because that would cause severe interoperability problems.
Not the same as
- SPF
- That authorizes which servers may send for a domain. This signs the message contents, and the two fail for completely different reasons.
- Encryption
- The specification says no attempt is made to include encryption as part of the mechanism. Anyone in the path can still read the message.
Why it matters to you
The separation between signer and author is the whole reason DMARC exists. Knowing it stops a common and expensive assumption. A message can carry a perfectly valid DKIM signature from a domain with nothing to do with the business named in the From line. DKIM is one of two inputs. On its own it authenticates a vouching party, not a sender identity.
What to ask or check
- 01Is our mail signed for the exact domain that appears in the From line, including subdomains?
- 02When were our keys last rotated, and does a second selector exist to rotate into?
- 03Does anything in our mail path modify messages, which would break signatures downstream?
What people get wrong
That a valid signature proves who sent the message. The standard separates the signer from the purported author, so a signature vouches for a domain that need not be the one in the From line.
Red flags
- A signature valid for a domain that is not the one in the From line.
- Keys nobody has rotated, with no second selector to rotate into.
- Authentication problems blamed on configuration when an intermediary is modifying messages.
Who owns it
The sending platform holds the private key and DNS holds the public half, so a rotation needs both, which is why it gets postponed.
Where you will see it
As a DKIM-Signature header on a message, as CNAME selector records in DNS, and in authentication results reports.