DKIM (DomainKeys Identified Mail)

DKIM lets a sending mail server attach a cryptographic signature to every outgoing message. The receiving server retrieves the sender's public key from DNS and verifies that the message has not been tampered with in transit.

How DKIM Works

When a mail server sends a message, it computes a hash of selected headers and the message body, then signs that hash with a private key. The signature is added as a DKIM-Signature header. The receiving server extracts the d= (domain) and s= (selector) values from this header, looks up the corresponding public key in DNS, and verifies the signature. If the signature is valid, the receiver knows the message was authorized by the domain owner and was not modified after signing.

DKIM DNS Record

The public key is published as a TXT record at <selector>._domainkey.<domain>. The selector allows a domain to have multiple active keys, for example one per mail system or for key rotation.

google._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0G..."

Key fields in the record:

• v=DKIM1 - version identifier (required).
• k=rsa - key type. RSA is the most common, though Ed25519 is gaining adoption.
• p= - the base64-encoded public key. An empty p= value means the key has been revoked.

DKIM Alignment

For DMARC to consider DKIM as passing, the d= domain in the DKIM signature must align with the From: header domain. Alignment can be strict (exact match) or relaxed (organizational domain match, meaning a subdomain of the From domain is acceptable). Most DMARC policies use relaxed alignment by default.

For example, if the From header is user@example.com and the DKIM signature has d=mail.example.com, relaxed alignment passes because both share the organizational domain example.com. Strict alignment would fail because the domains are not identical.

Common Issues

• Key rotation. DKIM private keys should be rotated periodically. During rotation, publish the new key under a new selector before switching the signing configuration, then remove the old key after a grace period. Failing to overlap the old and new keys causes verification failures for messages in transit.
• Selector misconfiguration. The selector in the DKIM-Signature header must exactly match the DNS record name. A typo or missing record means the receiver cannot find the public key, and DKIM fails.
• DNS record too long. RSA 2048-bit keys produce TXT record values that exceed the 255-byte limit for a single DNS string. The value must be split into multiple quoted strings within one TXT record. Most DNS providers handle this automatically, but manual edits can introduce errors.
• Third-party signing. When using a third-party email service, you typically CNAME a selector record to the provider's DNS. If that CNAME is missing or points to the wrong target, DKIM verification fails for all messages sent through that service.

Look up DKIM selectors with the DNS tool →