DKIM - DomainKeys Identified Mail

DKIM (DomainKeys Identified Mail) is an email authentication standard that was formalized in 2011 as RFC 6376. It adds a cryptographic signature to the header of every outgoing email. The receiving mail server can verify this signature using the public key in the sender domain’s DNS—and thus determine whether the email actually originated from the specified domain and whether it was tampered with en route.

DKIM, together with SPF and DMARC, is one of the three pillars of modern email authentication.

How DKIM works

Signing (sender side):

1. The sender’s mail server calculates a cryptographic hash of defined email headers and the body
2. This hash is signed with the private DKIM key
3. The signature is inserted into the email as a DKIM-Signature header

Verification (recipient side):

1. The receiving server reads the DKIM-Signature header
2. It queries the DNS for the public key: selector._domainkey.example.com
3. It verifies the signature using the public key
4. If they match: DKIM pass—the email is unaltered and originates from the domain

Anatomy of the DKIM-Signature Header

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.de; s=mail2024;
  h=from:to:subject:date:message-id;
  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=QjxnBMFXeOZJBj...

Tag	Meaning
v=1	DKIM version
a=rsa-sha256	Signature algorithm
c=relaxed/relaxed	Canonicalization for headers and body
d=example.de	Signing domain (must match the From header for DMARC alignment)
s=mail2024	Selector - determines which DNS key is used
h=	Signed header fields
bh=	Body hash
b=	Signature

Key Management and Selector

The selector allows for multiple DKIM keys for the same domain—an important feature for:

• Key rotation: Introduce a new key without interrupting service
• Multiple mail sources: Each mail service provider (Google Workspace, HubSpot, Mailchimp) gets its own selector

DNS record for selector mail2024:

mail2024._domainkey.example.de. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4..."

Key size: RSA-2048 as a minimum requirement

RFC 8301 (2018) classified RSA-1024 as insecure. RSA-2048 is the current minimum standard; RSA-4096 offers higher security. Many email service providers now also offer Ed25519 (Elliptic Curve) as an alternative—more compact keys with the same or higher security.

Check: dig TXT selector._domainkey.domain.com - check if p= is at least 256 characters long (= RSA-2048).

Key rotation - how often?

Best practice: every 6–12 months. Process:

1. Generate a new key (e.g., selector mail2025)
2. Publish a new DNS record with the new selector
3. Switch the mail server to the new selector
4. Delete the old DNS record after 48–72 hours (wait for the DNS TTL to expire)

Important: Do not delete the old key immediately—otherwise, emails that are still in transit will no longer be verified.

DKIM Limitations

Forwarding: When emails are forwarded (e.g., alias addresses), the body may be altered (e.g., footer appendix), which breaks the DKIM signature. DMARC accounts for this through relaxed canonicalization.

From header not required: DKIM signs the domain in the d= tag—this does not have to match the From header. Only DMARC alignment establishes this connection.

No protection against replay attacks: A validly signed email can be intercepted and resent. The signature remains valid.

DKIM in the Email Security Ecosystem

• SPF - Who is authorized to send from which server?
• DKIM - Was the email tampered with in transit?
• DMARC - Does everything match? What happens if it doesn’t?

All three protocols complement each other. Since February 2024, Google and Yahoo have required all three for bulk senders (>5,000 emails/day). Without proper DKIM signing and an SPF record, emails are sorted into spam or rejected.

Further information: SPF Wiki article | DMARC Wiki article