DKIM uses asymmetric cryptography — the private key signs outgoing messages, the public key in DNS verifies them — but the cryptographic chain of trust depends on keeping the private key genuinely private, and the specific ways private keys get compromised in email infrastructure are different from what most people expect
The previous articles on this site covered DKIM basics, key rotation and selectors, the full email authentication audit, DKIM and mailing list forwarding, key length recommendations, and the DKIM replay attack problem. This article addresses DKIM private key security — where private keys live, how they get exposed, and the operational practices that protect the most critical component of DKIM's security model.
Where DKIM private keys actually live
DKIM private keys must be accessible to the mail server at send time — unlike HTTPS certificates where the private key can be stored in a hardware security module (HSM) with hardware-enforced access controls, DKIM signing happens inline during SMTP delivery, requiring the key to be quickly accessible by the MTA (Mail Transfer Agent).
Common storage locations:
Plain files on the mail server: Postfix and Exim configurations typically reference private key files at paths like /etc/opendkim/keys/example.com/mail.private. The key is a plaintext PEM file readable by the mail server process.
In the MTA configuration: some simpler setups embed key material directly in configuration files — making the key present in configuration management, version control, and deployment pipelines.
Secrets management systems: more security-conscious setups use HashiCorp Vault, AWS Secrets Manager, or similar, retrieving the key at runtime. This reduces the attack surface but adds operational complexity.
Cloud email services: when using Google Workspace, Microsoft 365, Mailchimp, or SendGrid, the ESP (Email Service Provider) manages the DKIM private key internally. You only interact with the public key (added to DNS). This is more secure than self-managed keys — the ESP's infrastructure handles key storage.
The private key exposure vectors
Four specific scenarios expose DKIM private keys:
1. Version control inclusion: a developer commits the mail server configuration including the private key to a Git repository. If the repository is public (or later made public), or if the repository is breached, the private key is exposed. This is the most common category of key exposure.
Detection method: tools like git-secrets, truffleHog, and GitHub's push protection scan for private key patterns (PEM-formatted keys have recognisable headers: -----BEGIN RSA PRIVATE KEY-----).
2. Backup and archive exposure: server backups that include /etc/opendkim/keys/ copy the private key to backup storage. If backup storage has weaker access controls than the production server, the key is at risk. Many backup systems are less carefully secured than the servers they back up.
3. Server decommission: when a server is decommissioned, the private key on that server's filesystem may not be explicitly revoked (the DNS record deleted) or destroyed. If the server's storage is later reused, the key persists.
4. Shared hosting environments: in some shared hosting configurations, multiple accounts share a mail server, and private key file permissions may allow cross-account access. This is rare in reputable hosting but has occurred.
What an attacker can do with a stolen DKIM private key
A stolen DKIM private key enables an attacker to create DKIM-signed email from your domain, which:
- Passes DKIM validation at receiving mail servers
- Passes DMARC (if DKIM alignment is achieved — the From domain matches the DKIM signing domain)
- May display a BIMI logo (if BIMI is configured and DMARC passes)
- Appears trusted to spam filters that weight DKIM signatures positively
In practice this enables: phishing campaigns from your domain that bypass authentication checks, spoofed invoices from your domain to your customers, email fraud that appears to originate from your organization.
Unlike certificate revocation for HTTPS, DKIM doesn't have an equivalent of OCSP — there's no real-time revocation mechanism. The only way to invalidate a compromised DKIM key is to remove or change the DNS TXT record for that selector, which takes effect as soon as the TTL expires (typically minutes to hours).
Key rotation as the primary defence
Regular DKIM key rotation is the most important operational security practice for DKIM, and the previous rotation article covered the mechanics. From a security perspective, the reasons for rotation:
Limits exposure window: even if a private key is exfiltrated, rotating every 3-6 months limits the period during which a stolen key is useful for active attacks.
Detects compromise through anomaly detection: if outgoing DKIM signatures are being created that you didn't send, monitoring signing volume across selectors can reveal anomalous activity.
Implements cryptographic agility: rotating periodically enables moving from RSA-2048 to RSA-4096 or from RSA to Ed25519 as algorithm recommendations change.
The rotation selector naming convention: naming selectors with a date prefix (mail-2024-01, mail-2024-07) makes rotation status immediately visible from the DNS record — any selector with a date more than 12 months ago warrants investigation.
Ed25519 vs RSA: algorithm choice for DKIM
RSA (the traditional DKIM algorithm) has been the standard since DKIM's inception. RSA-2048 is currently widely supported; RSA-1024 is deprecated and should not be used.
Ed25519 (an elliptic curve algorithm, RFC 8463 for DKIM) has several advantages:
- Much shorter keys (32 bytes vs 256 bytes for RSA-2048) — producing shorter DNS TXT records
- Faster signing and verification
- No known weaknesses to quantum algorithms beyond RSA's general vulnerability
- Less sensitive to random number generator quality during signing (RSA signature generation requires a good random number generator; Ed25519 uses deterministic signing)
The limitation: Ed25519 DKIM is not yet universally supported by all receiving mail servers. Support has been added by major providers (Gmail, Microsoft), but some older or less common MTA implementations may not verify Ed25519 signatures.
The dual-signing approach: some high-security senders configure both an RSA and an Ed25519 DKIM selector, signing messages with both keys. Receivers that support Ed25519 use it; others fall back to RSA. This is the most forwards-compatible approach.
How to use the DKIM Checker on sadiqbd.com
- Verify public key presence: check that your DKIM selector's public key is published in DNS and matches what your mail server is using to sign — a mismatch causes signature verification failures even when the private key is valid
- Check key algorithm and length: the tool shows the key algorithm (RSA/Ed25519) and bit length — verify RSA keys are at least 2048 bits; any 1024-bit key should be rotated immediately
- Audit old selectors: check any old selector names you know were used historically — if the DNS record still exists for a decommissioned selector, the corresponding private key may still be valid for forging signatures; remove unused selectors from DNS
Frequently Asked Questions
How often should I rotate DKIM keys? Every 6 months is the commonly recommended interval for most organizations; more frequently for high-security environments. Google recommends at least annual rotation; security-focused guidance suggests quarterly or biannual. The rotation schedule should align with: your key storage security (more secure storage can rotate less frequently), your email volume (higher volume senders are higher-value targets), and your threat model (financial institutions, healthcare providers, and government domains benefit from more frequent rotation). The rotation process — adding new selector to DNS, updating mail server config, waiting for DNS propagation, then removing old selector — takes about 48 hours and should be scripted for consistency.
Is the DKIM Checker free? Yes — completely free, no sign-up required.
Try the DKIM Checker free at sadiqbd.com — verify any domain's DKIM public key record for any selector.
