DKIM (DomainKeys Identified Mail)
Cryptographically sign your emails to prove authenticity and prevent tampering.
DKIM adds a cryptographic signature to your emails, proving they originated from your domain and haven't been tampered with in transit. Unlike SPF, DKIM survives email forwarding.
How DKIM Works
- Generate a public/private key pair for your domain
- Publish the public key in DNS as a TXT record
- Your mail server signs outgoing emails with the private key
- Receiving servers retrieve your public key from DNS
- They verify the signature matches the message content
DKIM Record Structure
# DKIM record location selector._domainkey.example.com # Example DKIM record v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ... # Breakdown: # v=DKIM1 - Version (required) # k=rsa - Key type (rsa is most common, ed25519 emerging) # p= - Public key (base64 encoded) # t=s - Strict mode (optional, subdomain restriction) # t=y - Testing mode (optional)
Common DKIM Selectors
Different email services use different DKIM selectors. Here are the most common ones:
| Service | Selector(s) | Record Type |
|---|---|---|
| Google Workspace | TXT | |
| Microsoft 365 | selector1, selector2 | CNAME |
| SendGrid | s1, s2, smtpapi | CNAME |
| Mailchimp | k1, k2, k3 | CNAME |
| Amazon SES | [unique]._domainkey | CNAME |
| Mailgun | smtp, mailo, k1 | TXT |
| Postmark | [unique timestamp] | TXT |
| Zoho | zoho, zmail | TXT |
| HubSpot | hs1, hs2, hubspot | CNAME |
| Salesforce | sf, salesforce | CNAME |
Key Size Recommendations
| Key Size | Status | Recommendation |
|---|---|---|
| 2048-bit RSA | Recommended | Current standard, use for new deployments |
| 1024-bit RSA | Weak | Upgrade to 2048-bit when possible |
| Ed25519 | Emerging | Modern, compact, but limited support |
DNS TXT Record Size Limits
2048-bit RSA keys are longer than 255 characters, exceeding the single TXT string limit. Most DNS providers automatically split the key into multiple strings, but some require manual splitting. Check your provider's documentation.
What DKIM Protects
A DKIM signature covers specific parts of the message:
- From header — The sender address users see
- Subject — The email subject line
- Body — The message content (usually a hash)
- Other headers — Date, Message-ID, etc. (configurable)
If any signed content is modified after sending, the signature becomes invalid.
DKIM Header Example
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=google; h=from:to:subject:date:message-id; bh=abc123...; # Body hash b=xyz789...; # Signature # Fields: # v=1 - DKIM version # a=rsa-sha256 - Algorithm # c=relaxed - Canonicalization (header/body) # d= - Signing domain # s= - Selector # h= - Signed headers # bh= - Body hash # b= - Signature
Key Rotation
Regularly rotating DKIM keys is a security best practice:
- Generate a new key pair with a new selector
- Publish the new public key in DNS
- Configure your mail server to use the new key
- Keep the old key in DNS for a transition period (emails in transit)
- Remove the old key after the transition (typically 24-48 hours)
Microsoft 365 Key Rotation
Microsoft automatically rotates DKIM keys. By using CNAME records pointing to Microsoft's infrastructure, key rotation happens seamlessly without any DNS changes on your part.