DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to emails, allowing receiving servers to verify the message hasn't been tampered with and came from an authorized sender.

How DKIM Works

The Problem

Email can be modified in transit. Without verification, receivers can't know if the email they received is the same as what was sent.

The Solution

DKIM uses public-key cryptography:

1. Signing: Your mail server signs outgoing emails with a private key
2. Publishing: You publish the public key in DNS
3. Verification: Receiving servers verify the signature using your public key

The Signing Process

Your Mail Server                              DNS
      │                                        │
      │  1. Create email                       │
      │                                        │
      │  2. Generate signature                 │
      │     (hash of headers + body)           │
      │                                        │
      │  3. Add DKIM-Signature header          │
      │                                        │
      │  4. Send email ──────────────────────> │
      │                                        │
                                         Receiving Server
                                               │
                                 5. Extract selector from signature
                                               │
                                 6. Look up public key in DNS
                                               │
                                 7. Verify signature
                                               │
                                 8. Pass or fail DKIM

DKIM Record Format

DKIM records are TXT records at:

selector._domainkey.example.com

Example record:

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

Record Tags

Tag	Required	Description	Example
v	No	Version (assumed DKIM1)	v=DKIM1
k	No	Key type (default: rsa)	k=rsa or k=ed25519
p	Yes	Public key (base64)	p=MIIBIjAN...
h	No	Hash algorithms	h=sha256
t	No	Flags	t=y (testing mode)
s	No	Service type	s=email

Key Types

Type	Description	Key Size
RSA	Traditional, widely supported	1024-4096 bits
Ed25519	Modern, shorter keys	256 bits

Recommendation: Use RSA with a 2048-bit key. Many receivers can't verify Ed25519 signatures yet, so only use Ed25519 as a second signature next to an RSA one, never on its own.

Selectors

A selector is a name that identifies a specific DKIM key. This allows:

• Multiple keys for different services
• Key rotation without downtime
• Different keys for different purposes

Each service picks its own selector names. For the selectors common providers use, see Third-Party Senders.

Finding Your Selectors

Selectors are specified in the DKIM-Signature header of emails:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=google;
    c=relaxed/relaxed; ...

The s= tag contains the selector name.

The DKIM-Signature Header

When email is signed, a header like this is added:

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

Signature Tags

Tag	Description
v	Version (always 1)
a	Algorithm (e.g., rsa-sha256)
c	Canonicalization (header/body)
d	Signing domain
s	Selector
h	Signed headers
bh	Body hash
b	Signature

Canonicalization

Canonicalization defines how the email is normalized before hashing:

Header Canonicalization

Mode	Description
simple	Headers unchanged
relaxed	Convert to lowercase, collapse whitespace

Body Canonicalization

Mode	Description
simple	Body unchanged
relaxed	Collapse whitespace, remove trailing whitespace

Recommendation: Use relaxed/relaxed for best compatibility with mail systems that may modify whitespace.

Key Rotation

Periodically rotating DKIM keys improves security:

Rotation Process

1. Generate new keypair with new selector
2. Add new public key to DNS
3. Wait for DNS propagation
4. Configure mail server to use new selector
5. Keep old key active for in-flight emails
6. Remove old key after grace period

Rotation Frequency

• Minimum: Annually
• Recommended: Quarterly for high-security environments
• After breach: Immediately if private key compromised

Key Strength

RSA Key Sizes

Size	Status	Recommendation
512-bit	Insecure	Never use
1024-bit	Weak	Upgrade recommended
2048-bit	Standard	Recommended minimum
4096-bit	Strong	Good for high security

Note: Some DNS providers have TXT record size limits that may prevent 4096-bit keys.

Ed25519

• Fixed 256-bit key size
• Security comparable to a 3072-bit RSA key
• Much shorter DNS records
• Not verified by many receivers yet: sign with RSA as well

DKIM Alignment for DMARC

For DMARC, the DKIM signing domain (d=) must align with the From header domain:

Relaxed alignment (default):

• Signing domain can be a subdomain or parent
• d=mail.example.com aligns with From: @example.com

Strict alignment:

• Domains must match exactly

Common Issues

Invalid Signature

Causes:

• Email modified in transit
• DNS record doesn't match signing key
• Selector not found

Solutions:

• Check DNS record is correct
• Verify mail server configuration
• Use relaxed canonicalization

Key Too Weak

Cause: Using 1024-bit RSA or smaller

Impact:

• Weaker protection: 1024-bit keys are within reach of well-funded attackers
• Fewer points in your MailShield security score

Solution: Upgrade to 2048-bit RSA

Selector Not Found

Cause: DNS record missing or incorrect

Solutions:

• Verify selector name matches signature
• Check DNS propagation
• Confirm record is TXT type

Testing Mode

Cause: Record has t=y flag

Impact:

• Receivers may ignore signature failures
• Not production-ready

Solution: Remove t=y when ready for production

Setting Up DKIM

Every service that sends as your domain needs its own DKIM setup. The general pattern:

1. Generate a key in the service (or on your mail server), preferably 2048-bit RSA.
2. Publish the record it gives you: a TXT record with the public key, or CNAME records that point to the provider's keys.
3. Wait for DNS to propagate, then turn on signing in the service.

Publish the records before you turn on signing: Microsoft 365, for example, won't enable DKIM until its CNAME records resolve. Step-by-step instructions for Google Workspace, Microsoft 365 and other common services are in Third-Party Senders.

Testing DKIM

With MailShield

1. Add your domain to MailShield.
2. Wait for selectors to appear from your DMARC reports, or add them under Checks → DKIM → Add Selector.
3. The DKIM page shows each selector's key type, key size and validation status.

Manual Testing

# Look up DKIM record
dig +short TXT selector._domainkey.example.com

# Example for Google
dig +short TXT google._domainkey.example.com

Best Practices

Do

✅ Use 2048-bit RSA keys minimum
✅ Configure DKIM for all sending services
✅ Use unique selectors per service
✅ Rotate keys periodically
✅ Monitor for invalid signatures \

Don't

❌ Use 1024-bit or smaller keys
❌ Share private keys across services
❌ Leave testing mode enabled in production
❌ Ignore selector discovery from DMARC reports