DomainKeys Identified Mail (DKIM) Signatures

Cryptographically sign outgoing email messages with DKIM using aligned domains, minimum 2048-bit keys, canonicalization, and regular selector rotation.

What it is

DomainKeys Identified Mail (DKIM), standardized in RFC 6376, is an email authentication technology that uses asymmetric public-key cryptography to verify that an email message originated from the claimed domain and that its headers and body were not tampered with during transit.

When an email is sent, the outbound MTA computes a cryptographic hash over selected headers and the message body, encrypts the hash using the domain owner’s private key, and attaches the resulting signature as a DKIM-Signature header field.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;
 s=202608; t=1756155600;
 h=from:to:subject:date:message-id:content-type:mime-version;
 bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
 b=dK8v8W6m3Q...[base64 signature]...==

The receiving mail server extracts the signing domain (d=) and selector (s=) from the header, queries DNS for the corresponding public key at <selector>._domainkey.<domain>, and validates the signature.

202608._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0r+..."

Why it matters

Survives Message Forwarding and Relays: Unlike SPF (which relies on connecting client IP addresses and routinely fails when messages pass through mailing lists, forwarding services, or intermediate hops), DKIM signatures travel inside the message headers and remain valid across multiple relays as long as content is unmodified.
DMARC Cryptographic Alignment: DKIM provides the primary cryptographic proof required for DMARC alignment (d= domain matching the visible From: header domain). If SPF fails due to forwarding, a valid DKIM signature allows the message to maintain DMARC alignment and avoid the spam folder.
Tamper Evidence and Non-Repudiation: Signing critical headers (From, To, Subject, Date, Message-ID) and the body hash (bh=) guarantees that transit gateways or man-in-the-middle actors cannot alter recipient addresses, text content, or transactional payload data without breaking signature verification.

How to implement

1. Generate at least 2048-bit RSA keys (or Ed25519). RFC 8301 mandates a minimum RSA key size of 2048 bits. 1024-bit RSA keys are deprecated and flagged as insecure by modern mailbox providers. You may also dual-sign using modern Ed25519 keys (RFC 8463):

# Generate 2048-bit RSA private key
openssl genrsa -out dkim-202608.key 2048

# Extract public key for DNS publishing
openssl rsa -in dkim-202608.key -pubout -out dkim-202608.pub

2. Publish the public key record in DNS. Publish the public key as a TXT record under the _domainkey subdomain with selector naming:

; Selector: 202608 (organized by rotation date YYYYMM)
202608._domainkey.example.com. IN TXT (
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3..."
  "7xLz9...[continued string if >255 octets]..."
)

3. Configure Relaxed/Relaxed canonicalization. Set c=relaxed/relaxed in your MTA configuration. Relaxed canonicalization normalizes whitespace, header casing, and trailing blank lines before hashing, preventing minor formatting modifications by intermediate MTAs from breaking valid signatures:

Header Canonicalization: relaxed (converts header names to lowercase, unfolds lines, and compresses multiple spaces into one).
Body Canonicalization: relaxed (ignores trailing whitespace on lines and trailing empty lines at the end of the body).

4. Sign all core identity and routing headers. Explicitly include all critical headers in the h= signature list. At minimum, include: h=from:to:subject:date:message-id:content-type:mime-version:reply-to

5. Establish a regular selector rotation policy. Rotate DKIM keys at least every 6 to 12 months using date-stamped selectors (202608, 202701). When rotating:

Publish the new selector record in DNS.
Update the outbound MTA to sign with the new selector.
Keep the old selector record active in DNS for at least 14 days so in-flight and queued messages continue to verify cleanly.

Common mistakes

Signing with Third-Party Provider Domains without Alignment: Allowing transactional providers (SendGrid, Mailgun, Postmark) to sign with their own domain (d=sendgrid.net) instead of your domain (d=example.com). This fails DMARC DKIM alignment.
Post-Signing Content Modification: Inserting antivirus disclaimers, corporate footers, or tracking link rewrites after the MTA computes the DKIM body hash (bh=). Any byte altered after signing immediately invalidates the signature.
Splitting 2048-bit Keys Incorrectly in DNS: DNS TXT records limit individual character-strings to 255 bytes. 2048-bit keys exceed 255 bytes and must be published as multiple quoted strings within a single RRset.
Using Obsolete SHA-1 Algorithms: Using a=rsa-sha1 is insecure and prohibited by RFC 8301. Always use a=rsa-sha256 or a=ed25519-sha256.

Verification

1. Validate the DNS selector record:

dig +short TXT 202608._domainkey.example.com

2. Verify delivered email headers: Inspect raw email headers on a received message to confirm dkim=pass with exact domain alignment:

Authentication-Results: mx.google.com;
       dkim=pass [email protected] header.s=202608 header.b=dK8v8W6m;
       spf=pass (google.com: domain of [email protected] designates 198.51.100.10 as permitted sender);
       dmarc=pass (p=REJECT) header.from=example.com

3. Test tamper detection with a raw test harness: Send a message through a test tool (swaks), alter a single character in the body, and verify that the recipient mail server logs dkim=fail (body hash did not verify).