What Is DKIM?

At a glance

A sending server signs a message. The recipient retrieves a public key from DNS and checks whether the signed content changed in transit.

How DKIM connects a message to its signing domain

DKIM, or DomainKeys Identified Mail, lets a sending system use a private key to sign selected headers and a digest of the message body. It places the result in a DKIM-Signature header. The recipient reads the signing domain d= and selector s=, then queries s._domainkey.d for the corresponding DNS public key.

Successful verification means the signed content has not undergone disallowed changes and the signer controls the relevant private key. It does not prove that the message's claims are true or its sender is trustworthy. Nor must the signing domain automatically match the visible From address: DMARC evaluates that alignment.

Selectors, canonicalization and key rotation

• Selectors allow a domain to publish several public keys at once. Different sending platforms can use separate selectors without sharing private keys.
• The simple and relaxed canonicalization methods define permitted whitespace and formatting changes. Overly strict handling can make legitimate intermediary changes break signatures.
• Signature parameters identify protected headers and may specify a body length. Mailing lists that change subjects, footers or message bodies can invalidate the signature.
• For rotation, publish the new public key first, switch outgoing signatures, retain the old public key for delayed and in-flight messages, then retire the old selector.

Managing multiple sending platforms

Website notifications, support, marketing and HR systems may use different signing providers. Each should have an identifiable selector and a signing domain aligned with the brand domain, supported by procedures for private-key storage, rotation and retirement. Sharing a default selector makes troubleshooting and revocation more disruptive.

DKIM failures can result from a missing key, temporary DNS errors, algorithm or syntax problems, message modification or key rotation. Finding a DNS public key does not establish that current messages use it; actual message headers provide that evidence.

Practical use and interpretation

A valid public key at a known selector confirms that selector is configured. A real message with a valid signature is needed to establish that the current sending path signs correctly. Public DNS generally cannot enumerate every selector, so a failed lookup for a guessed selector does not establish that DKIM is absent.

A website profile can show confirmed DKIM capability or an unknown status. Conclusions about impersonation protection also depend on DMARC alignment, SPF, key length, algorithms and verification of actual messages.

Points to consider

Valid DKIM provides an authenticated signing identity and can contribute to a passing DMARC result.

Frequently asked questions

Why can I not find a DKIM public key?

Selectors are not fixed. Obtain the selector from a real message's DKIM-Signature header. Trying common names such as default or google only tests those particular names.

Does a valid DKIM signature prove a message is trustworthy?

It verifies the integrity of the signed content and control of the signing key. The truth of the message's claims requires separate judgment.

How often should DKIM keys be rotated?

The protocol does not prescribe one universal interval. Rotate according to key-management policy, provider capabilities, risk and incident-response requirements, with a safe overlap between selectors.