DKIM (DomainKeys Identified Mail)
DKIM is an email authentication method that uses cryptographic signatures to verify the integrity and origin of emails.
DKIM (DomainKeys Identified Mail) is an email authentication standard (RFC 6376) that ensures an email actually originates from the specified sender and has not been tampered with during transmission. Unlike SPF, which is based on IP addresses, DKIM uses asymmetric cryptography and thus also protects against certain forwarding scenarios.
How DKIM works
DKIM uses an asymmetric key pair: The sending mail server signs outgoing emails with a private key. The receiving mail server verifies the signature using the public key stored in the DNS of the sending domain.
DKIM Process:
1. Key generation:
Sending domain generates an RSA or Ed25519 key pair
→ Private key: remains securely on the mail server
→ Public key: is published as a DNS TXT record
2. Signing (outgoing):
Mail server calculates a hash of defined email headers + body
→ Algorithms: rsa-sha256 (standard) or ed25519-sha256 (more modern)
→ Hash is encrypted with private key → Signature
→ Signature is appended to the email as a DKIM-Signature header
3. Validation (incoming):
Receiving mail server reads DKIM-Signature header
→ Extracts selector (s=) and domain (d=)
→ DNS lookup: [selector]._domainkey.[domain] → public key
→ Recalculates hash using the same headers + body
→ Decrypts signature with public key
→ Comparison: Hash matches → DKIM pass | does not match → DKIM failDKIM-Signature Header in Detail
If an email is signed with DKIM, it contains a header like this:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.com; s=mail2024;
h=from:to:subject:date:message-id:mime-version:content-type;
bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
b=mFN3KcZj8Qh4...long-base64-string...==Parameter Explanation:
v=1 DKIM version (always 1)
a=rsa-sha256 Signature algorithm (RSA with SHA-256)
c=relaxed/relaxed
Canonicalization: Header/Body normalization
relaxed: tolerates minor format changes (recommended)
simple: strict validation (more sensitive to relays)
d=example.com
Signing Domain: must match the From: header (for DMARC)
s=mail2024 Selector: pointer to the correct DNS record
Allows multiple keys for a domain (rotation!)
h=from:to:subject:date:...
Signed headers: must include at least the From header
bh= Body hash: SHA-256 hash of the email body
b= The actual signature (Base64-encoded)DNS Record Structure
The public key is published under the following DNS name:
[selector]._domainkey.[domain]
Example:
mail2024._domainkey.example.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqG..."DNS TXT Record Parameters:
v=DKIM1 Protocol version (required)
k=rsa Key type: rsa (default) or ed25519
p= Public key (Base64-encoded)
Leave blank (p=) = Key revoked → all signatures invalid
Optional parameters:
h=sha256 Hash algorithm restriction
s=email Service type restriction (email or *)
t=y Test mode: DKIM errors are not enforced
t=s Subdomains not allowed (strict)Complete example with Ed25519 (more modern, shorter keys):
# Ed25519 DKIM record (recommended for new deployments):
selector2024._domainkey.example.com IN TXT "v=DKIM1; k=ed25519; p=11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo="Selectors and Key Rotation
A key advantage of DKIM over other methods is its support for multiple keys simultaneously through so-called selectors:
Selector strategy:
Multiple mail systems:
smtp._domainkey.example.de → Main mail server (Postfix)
crm._domainkey.example.de → CRM system (Salesforce)
newsletter._domainkey.example.de → Email marketing (Mailchimp)
Key rotation (Best practice: every 6–12 months):
Step 1: Generate a new key, publish it as "mail-new" in the DNS
Step 2: Switch the mail server to the new private key
Step 3: Keep the old DNS record for another 72 hours (wait for the TTL to expire)
Step 4: Remove the old DNS record or set p= to empty (revocation)
Why rotation?
→ A stolen private key can be misused for signing
→ Rotation limits the window of time during which a compromised key can be usedDKIM Alignment
DKIM alignment is crucial for DMARC: The domain in the d= tag of the DKIM signature must match the domain in the From: header (at least at the organizational domain level for relaxed alignment).
DKIM Alignment Examples:
Relaxed Alignment (Standard):
From: absender@beispiel.de
DKIM d=mail.example.de → PASS (same org domain: example.de)
DKIM d=otherdomain.de → FAIL
Strict Alignment:
From: absender@beispiel.de
DKIM d=example.de → PASS (exactly the same)
DKIM d=mail.example.de → FAIL (subdomain is not sufficient)
Typical DMARC scenario:
Email marketing via third-party providers:
From: newsletter@beispiel.de
DKIM signed by: mailchimp.com → DKIM alignment FAIL for DMARC!
Solution: Set up custom domain signing with the provider
→ DKIM signed by: k2._domainkey.example.de (via CNAME)Limitations of DKIM
DKIM is not a panacea and has known vulnerabilities:
What DKIM does NOT protect against:
Replay attacks:
→ A validly signed email can be resent
→ DKIM does not check whether the email has already been delivered
→ Countermeasure: DMARC + very short signature validity (t=)
Compromised mail server:
→ If the sending server is compromised, the attacker can
sign any emails with the private key
→ DKIM only proves: "This server signed it" — not: "No abuse"
Forwarding issues (DKIM usually remains intact):
→ Unlike SPF, DKIM usually survives forwarding
→ Exception: mailing lists that modify the subject or body
→ DKIM fails due to a changed body hash
Header injection via unsigned headers:
→ An attacker can insert additional From: headers (over signed ones)
→ Recipient sees second From: → Social engineering
→ Countermeasure: Include all important headers in h=DKIM and DMARC
DKIM alone has no policy effect: A DKIM failure does not automatically lead to an email being rejected. Only in combination with DMARC does DKIM have an enforceable effect.
DKIM in the DMARC Context:
DMARC Check (simplified):
Does the email pass SPF AND/OR DKIM with correct alignment?
→ Yes: DMARC pass (regardless of the p= policy)
→ No: DMARC fail → Apply policy (none/quarantine/reject)
Why DKIM is better than SPF for DMARC:
→ SPF fails during forwarding (Return-Path changes)
→ DKIM signature remains intact during forwarding
→ Best practice: Secure DMARC via DKIM, use SPF as an additional layer
Complete email authentication stack:
SPF: "Which servers are authorized to send for this domain?" (IP-based)
DKIM: "Is this email unaltered and correctly signed?" (Crypto-based)
DMARC: "What happens in case of authentication errors?" (Policy-based)DKIM is now an indispensable component of any professional email infrastructure. Major email providers such as Google and Microsoft actively factor DKIM signatures into their spam scoring and deliverability assessments—missing DKIM signatures increase the risk that legitimate emails will end up in the spam folder.
