What does DKIM stand for?

DKIM stands for DomainKeys Identified Mail. It is an email authentication protocol that uses cryptographic signatures to verify that an email was authorized by the domain owner and was not modified in transit.

What key size should I use for DKIM?

Use a minimum of 1024-bit keys, but 2048-bit keys are recommended for better security. Some providers now require 2048-bit keys. Keys larger than 2048 bits may not fit in a single DNS TXT record.

How often should I rotate DKIM keys?

Rotate DKIM keys at least annually. Some security policies recommend rotating every 6 months. When rotating, publish the new key before switching your signing configuration, and keep the old key published for at least a week after the switch.

Can DKIM signatures break?

Yes, DKIM signatures can break if the message is modified after signing. Mailing lists, email forwarding services, and security gateways that alter message content or headers can invalidate DKIM signatures.

What Is DKIM and How Does It Work?

While SPF tells receivers which servers can send your email, DKIM proves that the email content is authentic and unchanged. Together with SPF and DMARC, DKIM forms the foundation of modern email authentication.

We implement DKIM for organizations sending millions of messages, and proper configuration is essential for deliverability. This guide explains how DKIM works, how to set it up, and how to avoid common implementation mistakes.

How DKIM Works

DKIM uses public key cryptography. Your mail server holds a private key that signs outgoing messages. You publish the corresponding public key in DNS. Receiving servers use this public key to verify that the signature is valid.

The Signing Process

Your mail server selects specific headers and the message body to sign
It creates a hash of this content
It encrypts the hash using your private key
It adds the encrypted hash as a DKIM-Signature header

The Verification Process

Receiving server reads the DKIM-Signature header
It queries your DNS for the public key using the selector specified in the signature
It decrypts the signature hash using your public key
It independently calculates a hash of the signed content
If the hashes match, DKIM passes. If not, it fails.

The DKIM-Signature Header

DKIM adds a header to every signed message. Understanding its components helps with troubleshooting:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=example.com; s=selector1;
 h=from:to:subject:date:message-id;
 bh=base64hash...;
 b=signature...

v=1: DKIM version (always 1)
a=rsa-sha256: Signing algorithm
c=relaxed/relaxed: Canonicalization method for headers/body
d=example.com: Signing domain
s=selector1: Selector for finding the public key in DNS
h=: List of signed headers
bh=: Hash of the message body
b=: The actual signature

Setting Up DKIM

Step 1: Generate a Key Pair

Generate a public/private key pair. Most email services provide this automatically. If generating manually, use OpenSSL:

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

Use 2048-bit keys for security. The private key stays on your mail server. The public key goes in DNS.

Step 2: Publish the Public Key in DNS

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

The value contains your public key:

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

v=DKIM1: DKIM version
k=rsa: Key type
p=: The public key (base64 encoded)

Step 3: Configure Your Mail Server

Configure your mail server or email service to sign outgoing messages with your private key. Each email service has its own configuration method. Check your provider's documentation for specific steps.

Step 4: Test and Verify

Send a test email and check the Authentication-Results header. You should see dkim=pass. Use online tools to verify your DKIM DNS record is correctly published.

DKIM Selectors

Selectors allow you to have multiple DKIM keys for the same domain. This is useful for:

Different email services (marketing, transactional, corporate)
Key rotation without disruption
Identifying which system sent a message

Common selector naming conventions:

google or google1 for Google Workspace
s1, s2 for sequential selectors
2024q1 for date-based rotation

Key Rotation

Rotate DKIM keys periodically to maintain security:

Generate a new key pair with a new selector
Publish the new public key in DNS
Wait for DNS propagation (at least 24 hours)
Switch your signing configuration to use the new key
Keep the old public key published for 1-2 weeks
Remove the old DNS record once you are confident all emails are using the new key

Why Keep Old Keys Published?

Emails in transit or delayed for retry may still carry signatures from the old key. Removing the old public key immediately causes these messages to fail DKIM verification.

Canonicalization

Canonicalization defines how the message is normalized before hashing. Two methods exist:

Simple: Almost no changes allowed. Very strict.
Relaxed: Allows minor whitespace changes. More forgiving.

The c=relaxed/relaxed setting applies relaxed canonicalization to both headers and body. This is the recommended setting because some mail servers and gateways make minor formatting changes that would break simple canonicalization.

Common DKIM Problems

Signature Breaks After Forwarding

Email forwarding and mailing lists often modify messages, breaking DKIM signatures. This is a known limitation. ARC (Authenticated Received Chain) was developed to address this by preserving authentication results through forwarding chains.

Key Not Found Errors

If receivers cannot find your public key, check:

The selector in your signature matches your DNS record
The DNS record is properly formatted
DNS propagation is complete
There are no typos in the public key

Body Hash Mismatch

This indicates the message body was modified after signing. Common causes include security gateways adding footers, antivirus scanners modifying content, or encoding changes during transit.

DKIM and DMARC Alignment

For DKIM to contribute to DMARC pass, the signing domain (the d= value in the DKIM signature) must align with the domain in the From header. Alignment can be relaxed (subdomains allowed) or strict (exact match required).

If you sign with d=mail.example.com but send from [email protected], relaxed alignment passes but strict alignment fails.