CyberFurl can load analytics only after you opt in. Core product features work without analytics consent.
What is DKIM? DomainKeys Identified Mail — Complete Guide (2025)
Email Security
DKIM Explained: How Cryptographic Email Signatures Stop Forgery and Protect Deliverability
DKIM (DomainKeys Identified Mail) cryptographically signs outbound email to prove the message was not altered in transit. Learn how DKIM signing works, how to configure selectors, when to use 1024-bit vs 2048-bit RSA keys, how to rotate keys safely, and how DKIM aligns with DMARC for complete email authentication.
DKIM (DomainKeys Identified Mail) cryptographically signs outbound email to prove the message was not altered in transit.
What is DKIM?
DKIM (DomainKeys Identified Mail) is the email authentication protocol that proves a message was signed by a specific domain using public-key cryptography. Unlike SPF, which validates the sending server's IP address, DKIM validates the message content itself — proving that the headers and body were not altered after the message left the signing system.
DKIM is mandatory for Google and Yahoo bulk sender compliance as of 2024 (5,000+ emails/day) and is a critical prerequisite for DMARC enforcement. Without valid DKIM, DMARC must rely entirely on SPF alignment, which breaks for forwarded email. Together, SPF, DKIM, and form the complete email authentication stack.
1. Signing (sender side):
The mail platform selects which headers to include in the signature (typically From, To, Subject, Date) and computes a cryptographic hash. This hash is then encrypted with the domain's private key, producing the digital signature. The signature and metadata are added as a DKIM-Signature header to the message.
2. Publishing (DNS):
The corresponding public key is published at selector._domainkey.yourdomain.com as a DNS TXT record. This record is public and accessible to any receiver.
3. Verifying (receiver side):
The receiving MTA reads the d= and s= tags from the DKIM-Signature header, fetches the public key from DNS, reconstructs the same canonical hash of the specified headers and body, and decrypts the signature to verify they match. If the hash matches, DKIM passes. If any signed header or the body was modified in transit, the hashes diverge and DKIM fails.
Selectors allow one domain to publish multiple DKIM keys simultaneously. The selector s= tag in the DKIM-Signature header tells the receiver which key to look up. This design enables:
Multi-provider signing: Google Workspace uses s=google, SendGrid uses s=s1, each with their own key
Safe key rotation: Publish a new selector, switch signing, retire old selector — no downtime
Traffic isolation: Different mail streams (transactional vs marketing) can use different signing keys
Good selector naming reflects ownership: google, sendgrid, mailchimp, s1-2025 are all better than selector1 shared across everything. When you are rotating keys or debugging authentication issues, clear selector naming tells you immediately which provider owns which key.
Key strength: 1024-bit vs 2048-bit DKIM keys
| Key Type | Status | Recommendation |
|----------|--------|---------------|
| 1024-bit RSA | Legacy | Migrate away — increasingly vulnerable |
| 2048-bit RSA | Current standard | Use for all new configurations |
| Ed25519 | Modern, preferred | Use where provider and DNS support it |
RFC 8301 (2018) deprecated 1024-bit DKIM keys and raised the minimum recommendation to 2048-bit. 1024-bit RSA keys are still present in many legacy mail deployments because providers never forced an upgrade. The practical risk: 1024-bit RSA can be factored by well-resourced attackers using distributed computing — making historical signed messages potentially forgeable.
DNS character limit note: 2048-bit RSA public keys generate very long base64 strings that often exceed the 255-character DNS TXT record limit. The key must be split across multiple quoted strings in the DNS record. Some DNS providers handle this automatically; others require manual splitting. A truncated key causes DKIM validation to fail silently.
DKIM rotation best practices
Key rotation is where mature DKIM programs separate from checkbox deployments. The most common failures:
Deleting the old selector too early — receivers that cached the old key (TTL may be 24-48 hours) suddenly see missing keys and fail validation for in-flight messages
Forgetting which provider owns which selector — undocumented selectors become orphaned in DNS and are never cleaned up
Rotating without testing — new selector is published but signing platform is not updated, so old selector keeps signing but is not updated with the new key
Safe rotation sequence:
Generate new key pair (new selector name, e.g., google-2026)
Publish new public key at google-2026._domainkey.example.com
Wait 48 hours for propagation
Update mail platform to sign with s=google-2026
Send test email — verify new selector in DKIM-Signature header
Wait 24-48 hours
Remove old selector DNS record
Update internal documentation
Common DKIM failures and how to debug them
dkim=fail (signature verification failed): The cryptographic signature does not match. Most common causes: mail gateway added or modified content after signing (added footer, changed encoding), the DNS public key does not match the private key currently used for signing, or the key was copy-pasted with characters missing.
dkim=fail (no key for signature): The selector referenced in s= does not exist in DNS. Either the DNS record was never published, was deleted prematurely, or is published at the wrong name.
dkim=neutral or dkim=none: No DKIM signature was found in the message. The sending platform is not configured to sign, or is signing with a selector for a different domain.
Forwarding failures: Forwarders rewrite content after signing. Use c=relaxed/relaxed canonicalization (normalizes minor whitespace differences) rather than c=simple/simple (requires exact byte match) to reduce forwarding breakage. For mailing lists and complex forwarding, ARC is the appropriate solution.
DKIM and DMARC alignment
DKIM by itself proves that a domain signed the message. DMARC requires that the signing domain aligns with the visible From header domain. A message signed with d=sendgrid.net does NOT satisfy DMARC alignment for from:@yourcompany.com — because the signing domain and From domain are completely different.
This is why DMARC requires domains to configure their email providers to sign DKIM with your domain (e.g., d=yourcompany.com), not the provider's own domain. For example, Google Workspace signs with your domain by default. Some marketing platforms require configuring custom DKIM signing to align with your From domain.
step 1─────────>
step 2─────────>
step 3─────────>
step 4─────────>
step 5
1. Step 1:Check the raw email headers of a message sent through your mail platform. The DKIM-Signature header contains d= (signing domain) and s= (selector). These tell you exactly where the public key should be in DNS: selector._domainkey.signing-domain.com. If you cannot find a DKIM-Signature header, your sender is not signing mail — this is the first problem to fix.
2. Step 2:Query selector._domainkey.yourdomain.com for the TXT record containing the public key (p= field). Verify the key is present, not truncated, and uses at least 2048-bit RSA or Ed25519. Use a DKIM lookup tool to parse the record and validate the syntax. A missing, truncated, or mismatched key is one of the most common causes of DKIM failures.
3. Step 3:In your mail platform settings (Google Workspace Admin, Microsoft 365 Admin Center, SendGrid dashboard, etc.), generate a new DKIM key pair for your domain. The platform provides a TXT record to publish in DNS. Publish it exactly as specified — DKIM keys are long base64 strings that can be corrupted by copy-paste errors or DNS provider character limits.
4. Step 4:After publishing the DNS record and enabling DKIM signing, send a test email from the configured platform. Inspect the full raw headers of the received message. Look for DKIM-Signature with the correct d= domain and s= selector. Also check the Authentication-Results header at the receiving end to confirm dkim=pass. A dkim=fail here means the signature is not validating — check for DNS propagation, key mismatch, or truncation.
5. Step 5:Create a rotation schedule (every 6-12 months). When rotating: generate a new key pair with a new selector name → publish the new public key in DNS → wait 48 hours → configure the mail provider to sign with the new selector → send test emails to confirm new selector is used → wait another 24-48 hours → remove the old selector DNS record. Document which selector belongs to which provider to avoid confusion during future rotations.
Technical Architecture
DKIM uses public-key cryptography at the MTA level:
Hash Generation: The sending MTA canonicalizes specified headers and body, then computes a SHA-256 hash.
Signature Creation: The hash is encrypted with the domain's RSA private key, producing the b= value in DKIM-Signature.
Public Key Retrieval: Receiving MTA reads d= and s=, fetches public key from selector._domainkey.domain.com.
Verification: Receiving MTA decrypts the signature using the public key and recomputes the hash from the received message.
Match Check: If hashes match, DKIM passes. If headers or body were modified, hashes diverge and DKIM fails.
DNS Record / Config
s1._domainkey.cyberfurl.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
Common Misconfigurations
Strict canonicalization (c=simple/simple): Any whitespace normalization by gateways breaks the signature. Always use c=relaxed/relaxed.
1024-bit RSA keys: Legacy keys with insufficient security strength — migrate to 2048-bit
DNS record truncation: 2048-bit keys often exceed the 255-character DNS limit and must be split across multiple quoted strings
Stale orphaned selectors: Old DKIM selectors left in DNS after provider migration can be exploited for replay attacks
Security Risks
Message Tampering: Without DKIM, an adversary-in-the-middle can modify invoice amounts, routing numbers, or instructions in transit — undetectable to the recipient
Domain Impersonation: While SPF protects the envelope, DKIM ensures that forwarded mail retains its authentication — protecting the domain from impersonation in forwarding chains
Replay Attacks: Captured DKIM-signed emails can sometimes be replayed to other targets if the x= expiry tag is missing and headers are not tightly scoped
Compliance Impact
Google and Yahoo (2024 mandate): DKIM authentication required for all bulk senders — failure causes hard bounces
NIST SP 800-177: Federal email trustworthiness standard requires DKIM for message integrity and non-repudiation
HIPAA Security Rule: DKIM helps ensure that PHI transmitted via email has not been altered in transit
Best Practices for DKIM in 2025/2026
2048-bit RSA minimum — never generate new 1024-bit keys; migrate all legacy infrastructure
Use c=relaxed/relaxed — ensures signatures survive benign modifications by gateways and forwarders
Rotate keys every 6-12 months — treat key rotation as routine, not emergency
Document selector ownership — map every selector in DNS to the provider and team that owns it
Include DKIM in onboarding for new ESPs — establish DKIM signing requirements before any new mail provider goes live
Tools to check your DKIM
Use the CyberFurl DKIM lookup as your primary DKIM record checker. A DKIM lookup tool lets you query any selector for any domain to confirm the public key is present, syntactically valid, and not truncated. For debugging DKIM failures on live mail, inspect the raw headers of received messages and compare the d= and s= values to what is published in DNS. Combine the live checker with Email Security monitoring for continuous validation across all your signing selectors.
CF
How CyberFurl Helps
Automated monitoring. Zero manual work.
CyberFurl continuously monitors DKIM health across all your signing domains and selectors. The platform automatically detects weak 1024-bit keys, identifies invalid or truncated DNS records, and alerts on DKIM alignment failures visible in DMARC aggregate reports - giving security teams the confidence to advance DMARC enforcement without disrupting critical business communications.
A DKIM selector is a label in the s= tag of the DKIM-Signature header that tells the receiving mail server which public key to fetch from DNS. The public key is published at selector._domainkey.yourdomain.com as a TXT record. Selectors allow a domain to publish multiple DKIM keys simultaneously — one per mail provider, one active and one retiring, or separate keys for different mail streams. When rotating keys, selectors are how you safely run both old and new keys in parallel until all receivers have cached the new one.
How do I find my DKIM record?
You need to know the selector first. Look at the raw headers of an email actually sent by your mail provider — the DKIM-Signature header shows both the signing domain (d=) and the selector (s=). For example, s=google means the public key is at google._domainkey.yourdomain.com. Once you have the selector, you can query that DNS name for the TXT record, or use a DKIM lookup tool to retrieve and validate it. If you use Google Workspace, the default selector is usually google. For Microsoft 365, it is selector1 and selector2.
Should I use 1024-bit or 2048-bit DKIM keys?
Use 2048-bit RSA keys for all new DKIM configurations. RFC 8301 (updated 2018) moved the ecosystem away from 1024-bit keys and recommends 2048-bit as the minimum for new deployments. 1024-bit RSA keys are increasingly vulnerable as computing power grows cheaper — well-resourced attackers can factor 1024-bit keys using cloud computing clusters. If you have legacy systems still using 1024-bit keys, schedule migration to 2048-bit as a high-priority security improvement. Some providers also support Ed25519 keys, which offer stronger security with smaller key sizes and fewer DNS record characters.
Why does DKIM fail after email forwarding?
DKIM signatures cover specific message headers and the body. When a forwarder or mailing list modifies the message — adding a footer, rewriting the Subject line, changing line endings, or altering MIME structure — the signature no longer matches the modified content, and DKIM validation fails. This is expected behavior, not a bug. Common causes include: mailing lists that add [ListName] to the Subject, email gateways that add footers or strip attachments, security tools that rewrite URLs for click tracking, and some spam filters that normalize whitespace. For forwarding scenarios, the ARC protocol (Authenticated Received Chain) preserves authentication results across hops.
How often should I rotate DKIM keys?
Best practice is to rotate DKIM keys every 6 to 12 months and immediately after any of these events: a mail provider or ESP is offboarded, a suspected key compromise or security incident, or a provider changes their signing infrastructure. The safe rotation pattern is: generate new key pair → publish new selector in DNS → wait 48 hours for propagation → switch the mail provider to sign with new selector → confirm successful signing by checking DKIM-Signature headers in test emails → retire the old selector after another 48 hours. Never delete an old DKIM record before the new one is fully propagated and sending.
What happens if my DKIM record is missing or returns no key?
If a DKIM selector is referenced in the DKIM-Signature header but no matching TXT record exists in DNS, the receiving server returns a 'no key for signature' error and DKIM fails with 'permerror'. This is functionally the same as an invalid key — the signature cannot be verified. Common causes: the DNS TXT record was never published, was published at the wrong name (e.g., the full hostname instead of selector._domainkey.domain.com), was deleted when an old provider was offboarded, or the selector in the sending configuration does not match what is in DNS. Use a DKIM lookup tool to query the exact DNS name and verify the record exists and is syntactically valid.
Does DKIM signing improve email deliverability?
Yes — DKIM has a direct positive impact on deliverability through two mechanisms. First, DKIM is a required signal for spam filter reputation scoring at Gmail, Microsoft, and Yahoo: messages without DKIM are more likely to be rejected or land in spam, especially since Google and Yahoo's 2024 bulk sender mandate. Second, DKIM enables DMARC alignment — without DKIM, forwarded mail loses SPF alignment and has no fallback authentication signal, causing DMARC failures for legitimate mail. Messages that consistently pass both DKIM and DMARC build positive domain reputation over time, improving inbox placement and reducing spam folder rates.
