Discovering that your DKIM private key may have been exposed is a serious security event. Unlike a compromised password, a leaked DKIM key can be used silently - an attacker can sign fraudulent emails that pass DKIM verification and potentially satisfy DMARC, making phishing campaigns against your customers and partners far more convincing. The good news: you can respond quickly and effectively. This guide walks you through every step, from generating a replacement key pair to verifying the fix and hardening your setup against future exposure.

How a DKIM Key Gets Compromised

DKIM relies on asymmetric cryptography. Your mail server holds a private key that it uses to sign outgoing messages. The corresponding public key is published in DNS as a TXT record under a selector subdomain (for example selector1._domainkey.example.com). Receiving servers fetch the public key and verify the signature - if it checks out, DKIM passes.

The private key must remain secret. Common ways it gets exposed include:

  • Server breach. An attacker gains access to your mail server or the filesystem where private key files are stored. Key files are often found in predictable locations such as /etc/opendkim/keys/ or inside mail server configuration directories.
  • Leaked configuration files. Private keys embedded in configuration files - or accidentally committed to a version control repository - become permanently accessible once the repository history is exposed.
  • Shared hosting environments. On shared hosting, inadequate filesystem permission controls can allow other tenants to read your key material.
  • Old backups. Backup archives that include mail server configuration are a frequent but overlooked source of key leakage, especially when backups are stored in less-secured locations such as unencrypted cloud buckets.
  • Compromised ESP accounts. Email service providers manage DKIM keys on your behalf. If your ESP account is taken over, an attacker may be able to retrieve or rotate keys to ones they control.

Once an attacker has your private key, they can produce valid DKIM signatures on any email they craft. Those messages will pass DKIM checks at receiving servers and, if the signing domain aligns with your Header-From, they will also satisfy DMARC - even if you have a reject policy. From the outside, those fraudulent emails look completely legitimate.

Immediate Steps: Don't Panic, But Act Fast

A compromised DKIM key is serious, but it is fully recoverable. The response process has a clear sequence: generate a new key pair, publish the new public key in DNS, update your mail server to sign with the new key, then revoke the old key by invalidating its DNS record. The entire process can be completed in under an hour for most setups - the main variable is DNS propagation time.

Do not simply delete the old DNS record as your first action. If you remove the old public key before your mail server has switched to the new signing key, any in-flight messages signed with the old key will immediately fail DKIM verification. Follow the steps below in order.

Step 1: Generate a New DKIM Key Pair

Start by generating a new RSA key pair with a minimum key size of 2048 bits. 512-bit and 1024-bit keys are considered weak and many receiving servers reject them outright. Choose a new selector name - using a date-based convention such as 20260415 makes rotation history easy to track.

On a server running OpenDKIM, you can generate the key pair with:

opendkim-genkey -b 2048 -d example.com -s 20260415

This produces two files: 20260415.private (the new private key) and 20260415.txt (the DNS TXT record to publish). Store the private key file with strict filesystem permissions - readable only by the mail server process, never world-readable.

If you use an email service provider such as Google Workspace, Microsoft 365, Mailchimp, or SendGrid, the key generation step happens inside the ESP's admin dashboard rather than on your own server. Look for a DKIM settings or domain authentication section and generate a new key there. The ESP will give you the DNS TXT record value to publish.

Step 2: Publish the New Public Key in DNS

Create a new DNS TXT record at the selector subdomain for your new key. The record format is:

20260415._domainkey.example.com  IN  TXT  "v=DKIM1; k=rsa; p=<base64-encoded-public-key>"

Replace 20260415 with your chosen selector name and example.com with your domain. The value of p= is the Base64-encoded public key, which is included in the .txt file generated by opendkim-genkey or provided by your ESP.

Set the TTL for this record to a low value - 300 seconds (5 minutes) is recommended during active key rotation. A short TTL ensures that changes propagate quickly. You can raise it back to a higher value (3600 or more) once the rotation is complete and stable.

Do not touch the old selector's DNS record yet. It must remain valid until you have confirmed your mail server is fully using the new key.

Step 3: Update Your Mail Server to Sign with the New Key

Once the new DNS record is live and propagating, update your mail server configuration to sign outgoing messages with the new private key and the new selector. In OpenDKIM, this means updating your key table and signing table to reference the new selector and key file, then reloading the service:

systemctl reload opendkim

For ESP-managed DKIM, this step is typically completed by activating or enabling the new key in the dashboard - the ESP will start signing with the new key immediately after activation.

Send a test message (to a Gmail address works well) and inspect the raw message headers to confirm the DKIM-Signature header references your new selector. Look for s=20260415 (or whatever selector name you chose) in the signature header.

Step 4: Revoke the Old Key

Once you have confirmed that your mail server is signing with the new key, invalidate the old selector's DNS record. The correct way to revoke a DKIM key is not to delete the DNS record entirely - instead, update the record to use an empty public key value:

old-selector._domainkey.example.com  IN  TXT  "v=DKIM1; p="

Setting p= to an empty string is the standard revocation mechanism defined in RFC 6376. It signals to receiving servers that the key has been revoked and that any message signed with it should be treated as having no valid DKIM signature. This is preferable to full deletion because some DNS resolvers cache negative responses and may fail to re-check a deleted record promptly.

Wait for the old selector's TTL to expire before proceeding. If the old record had a TTL of 3600 seconds, wait at least one hour after publishing the revocation record before you consider any cached copies fully stale. After that, you may leave the revoked record in place indefinitely or remove it entirely - either is safe once the TTL has passed.

Step 5: Verify the Rotation

Verify that the new key is correctly published and the old key is revoked using dig:

# Check the new selector
dig TXT 20260415._domainkey.example.com +short

# Check the old selector (should return p= with empty value)
dig TXT old-selector._domainkey.example.com +short

You can also use the DMARCFlow DKIM Checker to validate your new selector from outside your network. Enter your domain and new selector name to confirm the public key is correctly formatted, the record is syntactically valid, and the key length meets the 2048-bit minimum. The checker will flag any issues with the record structure before they affect your mail flow.

Verify your DKIM setup for free
Check that your new selector is correctly published and your key meets current security standards - in seconds.
Check Your DKIM

Step 6: Monitor DMARC Reports

In the days following a key rotation, watch your DMARC aggregate reports closely. A spike in DKIM failures immediately after rotation is a signal that some sending path is still using the old key - for example, a secondary mail server or an ESP integration that was not updated. DMARC reports show you exactly which source IP addresses are producing DKIM failures and which selector they are using, making it straightforward to identify any stragglers.

If you are not already receiving and reviewing DMARC reports, DMARCFlow parses your aggregate reports automatically and surfaces DKIM failure patterns with per-source breakdowns. After a rotation, you want to see DKIM pass rates return to their pre-incident baseline within 24–48 hours. If they do not, the report data will show you precisely where the remaining failures are coming from.

Also check whether the compromised key was actively abused. If an attacker used the old private key to sign fraudulent messages before you revoked it, those messages will appear in DMARC reports as passing DKIM from your domain but originating from IP addresses you do not recognise. Document any such activity and consider notifying affected parties.

Preventing Future Key Compromise

A reactive response is necessary, but the goal is to prevent the scenario from recurring. The following practices significantly reduce your exposure:

  • Restrict private key file permissions. Key files should be readable only by the user account running your mail server daemon (for example, the opendkim user). Mode 600 or 640 with the correct ownership is the minimum. Never set key files to world-readable.
  • Never commit private keys to version control. Add key file patterns to your .gitignore. Scan existing repositories for accidentally committed secrets using tools like truffleHog or git-secrets. If a key has been committed, treat it as compromised regardless of whether the repository is private.
  • Use 2048-bit keys as the minimum. RFC 8301 deprecates keys shorter than 1024 bits, but 2048 bits is the practical minimum for meaningful security. Consider 4096-bit keys for long-lived selectors, accepting the slight increase in DNS record size and verification CPU cost.
  • Establish a regular rotation schedule. Even without a suspected compromise, rotating DKIM keys on a regular cadence - every 6 to 12 months - limits the window of exposure from any past undetected compromise. Use date-stamped selectors to make the rotation history visible.
  • Store backups securely and separately. Encrypt backup archives that contain mail server configuration. Store them in access-controlled locations separately from the production server. Rotate keys after restoring from a backup if the backup's age or provenance is uncertain.
  • Monitor ESP account access. If your DKIM keys are managed by an ESP, enable multi-factor authentication on that account and review access logs periodically. An account takeover can be as damaging as a server breach for DKIM security.
  • Review DMARC reports continuously. Unexpected DKIM passes from unfamiliar IP addresses in your DMARC reports may indicate that a compromised key is being used - even before you are aware of the breach. Regular review gives you early warning.