DKIM Key Rotation with OpenDKIM on Postfix

Why is DKIM key rotation essential for email deliverability?

You’ve set up DKIM with OpenDKIM on Postfix. The headers verify. Inboxes accept your messages. But what happens when your private key is exposed — not today, not tomorrow, but months or years from now?

Signing keys that never change become a liability. If an attacker gains access to your private key, they can forge emails that appear legitimate — not just any email, but ones that look like they came from you. And if that happens, your sender reputation suffers, inbox placement drops, and your deliverability crumbles.

DKIM key rotation isn’t a checkbox. It’s a core part of maintaining trust. Even with strong authentication, static keys erode security over time. Regular rotation is how you reduce exposure, reset risk, and preserve deliverability.

Key takeaways

Stale DKIM private keys increase the risk of forgery if compromised.
Forged messages can damage sender reputation and reduce inbox placement.
Regular key rotation is a critical step in maintaining long-term email deliverability.

What happens if DKIM keys aren’t rotated on Postfix with OpenDKIM?

If you don’t rotate your DKIM keys on Postfix with OpenDKIM, you leave your domain exposed to prolonged attacks and increase the chance of spoofing. A static key can be brute-forced over time, and if compromised, attackers can forge emails that appear to come from your domain. Reputable receivers may also flag your domain for poor key hygiene, which increases the odds of your messages being rejected or marked as spam.

Brute-force attacks grow more likely over time

Using the same DKIM key for months or years creates a larger attack surface. Attackers can systematically test keys against known patterns or use computational resources to crack them, especially if the key is short or the signing algorithm is weak. The longer a key remains in use, the more time attackers have to break it — even a 1024-bit key can be vulnerable with enough effort and time. RFC 6376 recommends regular key rotation as a best practice for maintaining security resilience.

Forged emails undermine trust and sender reputation

Should an attacker obtain your DKIM private key, they can sign malicious emails with your domain’s name. These forged messages appear legitimate to receiving servers that validate DKIM signatures. Even if the content is harmless, the act of forging email from your domain harms your sender reputation. Reputable filters may temporarily block your domain or flag it for inspection, leading to higher bounce rates and reduced inbox placement — especially on platforms that prioritize authenticated sending, like Gmail and Microsoft 365.

And it’s not just technical risk. Without key rotation, you fall out of alignment with industry standards around email security. Many enterprise-grade email providers and security vendors monitor key lifecycle behavior as part of their reputation scoring. A domain that hasn’t rotated keys in over a year may be viewed as careless, even if no attack has happened yet.

Verify your senders, detect risks before they escalate

Before you rotate keys, ensure your mailing list is clean. Invalid, disposable, or role-based addresses can degrade your sending reputation. You can verify your list in real time with bulk verification to remove risks before deployment. Even after you rotate keys, keeping your address list accurate helps prevent unnecessary delivery issues.

How does DKIM key rotation impact email deliverability?

Rotating DKIM keys regularly helps maintain email deliverability by signaling to receiving servers that you’re actively managing your security posture. Failing to rotate keys—especially for high-volume senders—can trigger reputation-based filters, increasing the risk of messages being marked as spam. Reputable mail providers and spam filters expect key rotation, and skipping it may lead to reduced inbox placement or even temporary blocking.

Security diligence shows up in reputation metrics

You’re not just protecting your domain; you’re reinforcing trust with inbox providers. Receiving servers use cryptographic signals like DKIM to assess sender reliability. A static key used over months or years raises red flags—especially if the key is exposed in a breach. Rotating keys demonstrates ongoing security hygiene, which correlates with better sender reputation over time.

Let’s be clear: automated systems monitor for patterns like long-term key usage. If your domain’s DKIM record hasn’t changed in two years while other senders rotate every 90 days, it’s a signal of neglect—something spam filters take seriously. This isn’t about perfection; it’s about consistency, especially if you’re sending 10,000+ messages per day.

Receiving servers expect rotation, especially at scale

High-volume senders are under more scrutiny. The DKIM spec (RFC 6376) doesn’t mandate a rotation schedule, but the operational reality is that most reputable mail providers expect it. A static key is a known risk vector—breach recovery often requires key reissuance anyway, so rotation is just part of responsible operations.

When a server detects a persistent DKIM key, especially paired with poor authentication practices (like weak SPF or missing DMARC), it may lower your score in reputation databases. This can lead to higher spam classification, even if your content is clean and your open rates are good. Some providers, like Microsoft and Gmail, use these signals in their filtering algorithms, though exact thresholds are not public.

If you’re managing your own Postfix server, don’t delay key rotation. Even if your current setup is secure, a single breach can expose an unchanged key for months. Rotating every 90 to 180 days aligns with industry norms and protects your ability to reach inboxes. Tools like MailTester’s bulk verification can help you validate sender integrity by checking list health before sending—keeping your sender profile clean and reducing risk.

How to rotate DKIM keys with OpenDKIM on Postfix: a step-by-step guide

You rotate DKIM keys with OpenDKIM on Postfix by generating a new private key, updating the signing directory and configuration file, restarting the OpenDKIM service, verifying the new signature in logs, updating the DNS TXT record with the new selector and public key, waiting 24–48 hours for propagation, and monitoring deliverability and bounce rates. This sequence maintains email integrity and prevents authentication failures during transitions.

Step-by-step key rotation process

Generate a new private key using opendkim-genkey. Run opendkim-genkey -d example.com -s mail (replace example.com and mail with your domain and desired selector). This creates a new key pair, where the private key is stored in a file like mail.private.
Place the key in the signing directory—typically /etc/opendkim/Keys. Ensure the file has correct permissions: owned by opendkim, readable only by the service (e.g., chmod 600 /etc/opendkim/Keys/example.com/mail.private).
Update opendkim.conf to reference the new key. Set KeyTable and SigningTable to point to the new selector. For example: mail._domainkey.example.com in the SigningTable maps to mail in the KeyTable.
Restart OpenDKIM to load the new configuration. Use systemctl restart opendkim. The service must reload the updated key table and signing rules.
Verify the new key is active by checking recent mail logs. Look for DNSKEY or DKIM-Signature headers in outgoing messages. You should see the new selector (e.g., mail._domainkey.example.com). Use journalctl -u opendkim -f to watch in real time.
Update your DNS TXT record to include the new public key and selector. Replace the old record with one that matches the mail.txt file output by opendkim-genkey. Include the full v=DKIM1; k=rsa; p=... format.
Wait 24–48 hours for DNS propagation and receiver caches to update. Some email providers cache DNS records for longer durations; waiting ensures all receivers accept the new key.
Monitor deliverability and bounces for any spikes. Check your mail logs for failed signature validation and review bounce reports. A sudden drop in inbox placement may indicate a misconfiguration during rotation.

Why timing and testing matter

DKIM key rotation can break email flows if done too abruptly. Let’s say you update the DNS record without allowing caches to expire — some receivers may still use the old key, leading to failed validation. According to RFC 6376, DKIM signature validation is strict: a mismatched public key results in rejection or spam filtering.

The 8 steps described in “Step-by-step key rotation process”, in order.

Use inbox placement testing after rotation to confirm messages reach inboxes across providers. This helps catch alignment or DNS issues before they affect campaigns.

What should the DKIM key rotation interval be?

Rotate your DKIM keys every 90 to 180 days. For high-volume or high-security domains, aim for 90-day rotation. Shorter cycles reduce exposure if keys are compromised but increase operational load. The balance between risk and effort defines your optimal interval.

Why 90 to 180 days is the standard

Most security guidelines suggest rotating cryptographic keys every three to six months—aligning with 90 to 180 days. This window strikes a practical midpoint between minimizing long-term exposure and avoiding excessive administrative overhead. If a key is leaked, it will only be exploitable for a limited time, reducing the window for abuse.

Standards like RFC 6376, which defines DKIM, don’t prescribe a fixed rotation period. Instead, they emphasize the importance of key lifecycle management. Organizations that follow industry best practices—including those in financial services, healthcare, and large-scale email senders—typically implement automated rotation within this timeframe. You can find guidance on key management in resources from the Internet Engineering Task Force (IETF).

What drives shorter intervals?

If you're sending large volumes of email—thousands per day—or handling sensitive data, you may want tighter control. Rotating keys every 90 days reduces the risk surface if a key is somehow compromised through a misconfigured system, insider threat, or supply chain attack.

But shorter intervals mean more work. You must ensure that every sending server updates its key, that DNS records are refreshed without downtime, and that your monitoring systems track the transition. Failures here can lead to delivery failures or authentication errors. Tools like OpenDKIM support automated key generation and renewal, but you still need to manage the process. Consider this: if you automate it carefully, the added effort becomes manageable.

On the other end, longer cycles—like 365 days—make sense only for low-volume senders with minimal risk exposure. This is rare in production systems. A key held too long increases the chance of undetected compromise, which might go unnoticed until a breach or blocklist entry occurs.

Check your domain's email delivery health with a real inbox placement test. See how your DKIM setup affects deliverability before and after rotation using MailTester's inbox placement checker. It tests real inboxes across providers and reports whether authentication issues are affecting your results.

How to ensure a smooth transition during DKIM key rotation?

Run both old and new DKIM keys in parallel for 72 hours, use a DNS selector that supports coexistence (like selector1.example.com and selector2.example.com), monitor outgoing mail for signature failures during overlap, and only remove the old key from DNS and system files after confirming the new key is consistently accepted by receivers. This prevents email rejection due to key mismatches during transition.

Key steps for a seamless DKIM key rotation

Generate a new DKIM key pair and configure it in Postfix alongside the existing key.
Use a selector that allows concurrent existence, such as selector2 alongside selector1, so both keys can coexist in DNS until the transition is complete.
Update your DNS TXT record to include both the old and new DKIM records with their respective selectors, ensuring they’re both publicly visible and resolvable.
Allow a 48–72 hour overlap period during which both keys are active to avoid issues with email receivers that cache DNS records or enforce strict signature validation.
Monitor logs in real time using mail.log or your SIEM to detect DKIM signature failures during this window.
Check the DKIM specification (RFC 6376) to ensure your setup aligns with standard behavior regarding key selection and verification.
Verify that receiving servers are applying the new key correctly by testing email delivery through tools like inbox placement testers or sending to known domains with strict verification policies.

Finalize the transition safely

Only after confirming that all outgoing messages are successfully signed with the new key and accepted by major providers (Gmail, Outlook, etc.), remove the old DKIM record from DNS.
Remove the old key configuration from Postfix’s opendkim.conf and reload the service.
Wait 24–48 hours after DNS changes to ensure global propagation and complete invalidation of cached records.
Use a DNS lookup tool like MxToolbox to verify the old record is no longer accessible.
Re-run inbox placement tests to confirm deliverability remains stable post-change.

What role does MailTester play in verifying your DKIM setup after rotation?

You can use MailTester’s real-time verification API to test individual addresses and validate the entire delivery path post-rotation, run inbox-placement tests to confirm messages land in inboxes (not spam), inspect email headers to verify DKIM signatures are correctly applied, and monitor large lists for unexpected bounces or delivery delays. These checks ensure your DNS changes and key rotation didn’t break email security or deliverability.

Test individual addresses and path integrity

After rotating your DKIM key, immediately verify a few high-value addresses using the MailTester verification API. This confirms mail flow still works end-to-end — not just at the DNS level, but from your server to the recipient’s inbox. You’re looking for valid status, not just "accepted" — a valid address means delivery is possible, and the signature is present in the header.

Confirm inbox placement and signature validity

Even with correct DNS records, your mail might still land in spam or get silently dropped. Run an inbox-placement test through MailTester’s inbox tester to see how your messages appear in real inboxes across major providers. This reveals if the DKIM signature — and the full chain of authentication — is still trusted by receiving servers.

Use MailTester’s header inspection tool to open a sample message and check the DKIM-Signature header. Ensure it shows the new key’s identifier and that the “b” signature hash is valid. If it’s missing or stale, your rotation failed silently — and your email may be marked as suspicious.

For large lists, check for sudden spikes in bounces or delays after rotation. MailTester can process bulk lists via bulk verification to identify problematic domains or catch-all addresses that may have been affected by the change in signing policy.

DKIM key rotation is a necessary security step. But without verification, you risk breaking trust. Tools like MailTester help you audit the outcome — not just the setup. As defined in RFC 6376, DKIM relies on consistent cryptographic validation; a failed or mismatched signature breaks the chain. Always test the new key in real mailflow, not just DNS lookup.

Common pitfalls during DKIM key rotation and how to avoid them

You’ll cause delivery failures if you forget to update DNS, drop old keys too soon, misconfigure the selector, or restart OpenDKIM before the new key is live. These mistakes break alignment with email authentication standards and trigger spam filters. Let’s walk through the real-world traps and how to bypass them without downtime.

Before you rotate: ensure DNS and config match

Double-check your TXT record in DNS after updating. Use MxToolbox or the dig command to verify the record is published and matches your selector and key.
Never delete the old DKIM key from your DNS until you’re confident the new one is working across all your mail servers. Some clients cache DNS, and dropping the old key prematurely can cause bounces, especially with older or less aggressive mail delivery pipelines.
Ensure the Selector in /etc/opendkim.conf exactly matches the one in your DNS record. A typo here—like mail vs mail2—means no authentication validation, and your messages will fail SPF/DKIM alignment.

Timing is everything during the transition

Do not restart OpenDKIM until your new key is fully published and tested. The system needs time to propagate. Run a test with an inbox placement test using a real email address to confirm deliverability post-change.
Wait 24–48 hours after DNS update before removing the old key. Mail delivery systems vary in how quickly they refresh DNS; some can take up to 48 hours to fully adopt the new key.
Enable logging in OpenDKIM to monitor signing attempts during the switch. Look for lines like signature verified or no signature found to validate that the new key is being used.
Use RFC 6376 as a reference for DKIM signing practices—specifically the requirements around key validity and selector syntax.

The key to smooth DKIM rotation is patience and verification. Automation fails when assumptions go unchecked.

Most issues stem from assuming DNS updates apply instantly or that config changes are flawless. Treat every rotation like a production rollout: validate, test, wait, then decommission. With proper steps, you can rotate keys monthly without a single bounce.

How do SPF, DKIM, and DMARC work together during key rotation?

During DKIM key rotation, SPF remains unchanged because it authorizes mail servers, not cryptographic keys. DKIM signs messages with a private key; its public key is updated in DNS, but SPF policies aren't affected. DMARC checks both SPF and DKIM alignment—until the new DKIM key is fully propagated, misaligned results may trigger DMARC failures, risking deliverability. Proper coordination prevents inbox placement drops.

SPF stays steady—because it's about servers, not keys

SPF defines which IP addresses are allowed to send mail for your domain. It doesn’t care about cryptographic signatures, so rotating DKIM keys doesn’t require changing SPF records. You’re not authorizing new servers—you’re updating a digital fingerprint.

That means if your SPF record says “v=spf1 ip4:192.0.2.1 -all,” it stays that way through key rotation. No need to update it, and no reason to. SPF’s role is static: list authorized senders. It doesn’t track signatures or key lifetimes.

DKIM shifts only in DNS—never in policy

DKIM works by signing outgoing messages with a private key. The corresponding public key lives in DNS as a TXT record under a selector (like default._domainkey.example.com). When you rotate keys, you generate a new private/public pair and update the DNS record.

The old key stays active until you disable it and confirm the new one is working. This is where overlap matters: for a short window, both keys may validate messages. You must ensure your mail server is signing with the new private key while the DNS public key is live and accessible.

Think of it like changing a lock: the door still opens the same way, but the key you use to unlock it changes. The old key stops working when you’re fully migrated. A single misstep in this transition can break DKIM validation.

DMARC relies on alignment—mismatch means failure

DMARC evaluates whether SPF or DKIM aligns with the sender’s domain. During key rotation, misaligned DKIM signatures or temporary SPF misconfigurations can cause DMARC to fail, even if the message is legitimate.

For example, if your new DKIM key signs a message but the domain in the “From” header doesn’t match the selector’s domain, DMARC fails. This can lead to messages being rejected or quarantined—even if your email is valid.

That’s why you monitor DMARC reports during rotation. The RFC 7483 specification details how DMARC alignment works—check RFC 7483 for the full alignment rules. Also, use tools like inbox placement testing to validate deliverability before and after the change.

What to monitor after DKIM key rotation to ensure success?

After rotating your DKIM keys, verify that emails are still being signed correctly, delivered reliably, and not being flagged as spam. Check logs, bounces, and DMARC reports immediately. Use MailTester’s bulk verification to catch invalid addresses caused by DNS or key misconfigurations before they hurt your sender reputation.

Immediate post-rotation checks

Inspect Postfix logs (e.g., /var/log/mail.log) for 'signature not valid' or 'DKIM verify failed' messages — these indicate signing issues or configuration drift.
Look for sudden spikes in bounce reports, especially soft bounces like "550 5.1.1 User unknown" or "554 5.7.1 Message rejected due to policy.", which may signal misconfigured DNS or failed signature validation.
Use MailTester’s bulk email verification to scan your sending list for addresses that now fail due to DNS errors or key mismatches — this helps you clean your list proactively.

Longer-term validation

Review aggregate DMARC reports (via tools like dmarcian or your email service provider) to confirm no increase in failures after the rotation. A spike in policy.evaluated = fail with DKIM=FAIL suggests the new key isn’t being accepted by receivers.
Confirm your public DKIM DNS record is properly published and aligned with your domain’s SPF and DMARC policies. A mismatch may cause valid emails to be rejected.
Monitor inbox placement over 48–72 hours — use MailTester’s inbox placement test to check if your messages are landing in spam or junk folders post-rotation.

Proper DKIM key rotation is not a one-time fix — it’s a checkpoint in continuous deliverability hygiene. Even brief misconfigurations can trigger long-term sender reputation damage.

Let’s be clear: no system is immune to human error. A missing DNS TXT record entry or an expired key in a stale configuration file can cause undetected failures. Use tools designed to test real-world delivery — like MailTester’s verification suite — to catch issues before your first campaign goes live. You’re not just rotating keys. You’re maintaining trust with inbound mail servers. That requires visibility.

Key takeaway: security and deliverability go hand-in-hand

DKIM key rotation isn’t optional—it’s part of responsible sender management. Neglecting it increases the risk of key compromise and undermines trust with receiving mail servers.

Proactively rotating keys protects sender reputation and prevents delivery failures. Even a brief window of exposure can trigger filtering or rejection, especially if a key is breached or misconfigured.

Tools like MailTester help you monitor the outcome of key rotation. Verify that your domain remains trusted, that messages pass authentication, and that inbox placement stays stable across major providers.

Sources

The number of top domains at DMARC enforcement grew from 233,249 in 2023 to 411,935 in 2026 — a 77% increase driven largely by mailbox-provider sender mandates. — EasyDMARC 2026 DMARC Adoption & Enforcement Report (2026)
Since May 5, 2025, Microsoft Outlook requires SPF, DKIM, and DMARC from domains sending 5,000+ emails per day, rejecting non-compliant mail outright at the SMTP level with error 550 5.7.515. — Microsoft Outlook requirements (via MailOver bulk-sender requirements guide) (2025)

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

How often should I rotate DKIM keys on Postfix with OpenDKIM?

Rotate every 90 to 180 days. High-security domains may rotate quarterly to reduce exposure.

What happens if I don’t rotate my DKIM key?

The key may be compromised, leading to email forgery and sender reputation damage. Receiving servers may reject your messages.

Can I rotate DKIM keys without downtime?

Yes. Use parallel keys with overlapping DNS records to maintain delivery during the transition.

How do I know if the new DKIM key is working?

Check outgoing email headers for the new selector and valid DKIM-Signature. Use MailTester’s inbox-placement testing to verify delivery.

What's a DKIM selector?

It’s a label in the DKIM DNS record (e.g., default._domainkey.example.com) that identifies which public key to use for signature verification.

Should I keep old DKIM keys after rotation?

Yes, keep them for 48–72 hours during transition. Remove only after confirming the new key is fully in use.

Does DKIM key rotation affect my SPF record?

No. SPF defines authorized sending servers. DKIM key rotation only affects the signing key in DNS, not SPF policy.

How do I test if my DKIM setup is still valid after rotation?

Use MailTester’s inbox-placement or real-time API checks to verify the DKIM signature is present and valid in outgoing messages.

What if my emails are being marked as spam after rotation?

Check that DNS records are correct, signatures are valid, and DMARC policy is aligned. Use MailTester to test end-to-end delivery.

Can I automate DKIM key rotation?

Yes, use scripts in combination with a monitoring system. Tools like Puppet, Ansible, or custom cron jobs can help schedule and publish changes.

Why does my domain need both DKIM and SPF?

SPF checks sender authentication at the IP level. DKIM verifies message integrity. Together, they strengthen email authentication and improve deliverability.

Is MailTester required for DKIM key rotation?

No, but it helps verify that your new key is working and that deliverability remains stable post-rotation.