What is DKIM (DomainKeys Identified Mail)?

DomainKeys Identified Mail (DKIM) is an email authentication method that allows the sending domain to attach a cryptographic signature to outgoing messages. The receiving mail server can verify this signature using a public key published in the sender’s DNS records, confirming that the message was authorized by the domain owner and was not modified in transit.

DKIM is defined in RFC 6376 and is one of three core email authentication mechanisms alongside SPF and DMARC.

How DKIM works

The DKIM process involves a signing step at the sender’s side and a verification step at the receiver’s side:

Signing (sender)

1. The sending mail server generates a hash of the message body and selected headers (typically From, To, Subject, Date, and MIME-Version).
2. It signs this hash using a private key that only the sending organization holds, producing a digital signature.
3. It attaches the signature as a DKIM-Signature header to the message, along with metadata about which headers were signed, the hashing algorithm used, and a selector that identifies which public key to look up.

Verification (receiver)

1. The receiving mail server reads the DKIM-Signature header and extracts the domain (d=) and selector (s=).
2. It performs a DNS TXT lookup at {selector}._domainkey.{domain} to retrieve the public key.
3. It recomputes the hash of the signed headers and body using the same algorithm.
4. It verifies the signature against the computed hash using the public key.
5. If they match, DKIM passes. The result is recorded in the Authentication-Results header.

What a DKIM-Signature header looks like

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=sendstreak.com; s=mail2024;
    h=from:to:subject:date:message-id:mime-version;
    bh=LPJNul+wow5m1qOXaWAPShx3loJOEObat9eP+rN7X7Y=;
    b=dHRXMG2BqRTg...

Breaking this down:

Setting up DKIM

Setting up DKIM requires two steps: generating a key pair and publishing the public key in DNS.

1. Generate a key pair

Most email services (including SendStreak, AWS SES, and Gmail) generate DKIM keys for you and provide the DNS record to publish. If generating your own:

openssl genrsa -out dkim_private.pem 2048
openssl rsa -in dkim_private.pem -pubout -out dkim_public.pem

2. Publish the public key in DNS

Create a TXT record at {selector}._domainkey.yourdomain.com:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhki...

The private key stays on the sending server and is never published. If you rotate keys, publish the new public key under a new selector before switching the signing configuration, so messages in transit can still be verified.

Why DKIM survives forwarding

Unlike SPF, which validates the sending server’s IP address, DKIM validates the message content itself. When a message is forwarded through an intermediary, the IP address changes (breaking SPF), but the DKIM signature remains intact as long as the message body and signed headers are not modified.

This is why DKIM and SPF are complementary: SPF catches unauthorized senders at the network level, while DKIM catches message tampering at the content level. DMARC requires at least one of them to pass with domain alignment.

Common DKIM issues

Signature verification fails after message modification. Mailing lists and some forwarding services modify headers or append footers to the message body, breaking the DKIM signature. The c=relaxed/relaxed canonicalization setting helps tolerate minor whitespace changes, but any substantive modification will invalidate the signature.

DNS record too long for a single TXT record. 2048-bit RSA keys produce public keys that exceed the 255-character limit of a single DNS TXT string. The solution is to split the value across multiple strings within the same TXT record — most DNS providers handle this automatically, but it is a common source of misconfiguration.

Selector mismatch. The s= field in the DKIM-Signature header must exactly match the selector subdomain in DNS. A typo or misconfigured selector means the receiving server cannot find the public key, and DKIM fails.

Key rotation without overlap. When rotating DKIM keys, the old public key must remain in DNS until all messages signed with it have been delivered. Removing the old key too early causes verification failures for in-flight messages.

DKIM in the authentication stack

DKIM works alongside SPF and DMARC to provide layered email authentication:

1. SPF checks if the sending IP is authorized by the domain’s DNS record.
2. DKIM checks if the message content is authentic and untampered.
3. DMARC enforces policy by requiring that at least one of SPF or DKIM passes and aligns with the From header domain.

For transactional email, DKIM is non-negotiable. Gmail, Yahoo, and Microsoft all factor DKIM results into spam filtering, and as of 2024, Gmail and Yahoo require DKIM authentication for bulk senders.