Engineering Guide to DKIM: Securing Email Integrity with Digital Signatures

DKIM Explained: How Email Digital Signatures Protect Your Domain

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing email to verify that the message was authorized by the domain owner. Defined in RFC 6376, it remains the most resilient authentication mechanism in the email stack because it survives message forwarding.

Why This Matters

In technical environments, intermediate mail servers such as mailing lists or antivirus gateways frequently modify message whitespace or headers, which can invalidate strict cryptographic signatures. DKIM addresses this reality through canonicalization algorithms, though improper configuration—such as using the deprecated 1024-bit RSA keys or the vulnerable l= body length tag—can lead to total authentication failure or header injection attacks.

Key Insights

• RFC 8301 (2018) officially deprecated 1024-bit RSA keys, requiring a 2048-bit minimum for secure DKIM signatures.
• Ed25519-SHA256 (RFC 8463) provides 128-bit security with significantly smaller DNS TXT records (~60 bytes) compared to RSA-2048 (~400 bytes).
• The l= tag is a known security vulnerability that allows attackers to append malicious content after the signed portion of an email.
• Dual-signing with RSA-2048 and Ed25519 enables high-performance verification for modern receivers like Gmail while maintaining universal backward compatibility.
• An empty p= tag in a DNS record serves as the official RFC 6376 revocation signal, distinguishing a retired key from a temporary DNS failure.

Working Examples

Anatomy of a standard DKIM-Signature header including version, algorithm, and canonicalization tags.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.com; s=selector1; t=1712880000;
x=1713484800; h=from:to:subject:date:message-id:mime-version;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=LjxLMKpHN2kQz...

Example of a successful DKIM and DMARC verification as seen in Gmail message headers.

Authentication-Results: mx.google.com;
dkim=pass [email protected] header.s=selector1 header.b=LjxLMKpH;
spf=pass (google.com: domain of [email protected] designates 198.51.100.42 as permitted sender);
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com

Practical Applications

• Use Case: Multi-provider environments use unique selectors (e.g., google._domainkey or s1._domainkey) to manage distinct public keys for different services on a single domain.
• Pitfall: Selecting ‘simple’ canonicalization often results in DKIM failures because it requires byte-identical headers, whereas ‘relaxed’ canonicalization tolerates common whitespace changes by intermediate servers.
• Use Case: Over-signing headers by listing fields like ‘Reply-To’ twice in the h= tag prevents attackers from injecting secondary spoofed headers after the signature is generated.
• Pitfall: Relying on default third-party ESP signatures (d=esp-domain.com) breaks DMARC alignment; custom DKIM must be configured so the d= tag matches the From: header domain.

References:

• https://dev.to/toolbox_starnomina/dkim-explained-how-email-digital-signatures-protect-your-domain-1i9i