How Often Should You Generate a New DKIM Key?

How often should you generate a new DKIM key? For most organizations, a sensible default is every 6 to 12 months, using a new DKIM selector for each rotation. Rotate sooner when a private key may have been exposed, when you change sending infrastructure, or when you need to replace an old or weak signing configuration.

There is no universal DKIM expiration date built into the protocol. Instead, key rotation is an operational security practice: it limits how long a leaked private key can be abused and gives you a structured way to retire outdated cryptography without interrupting valid mail.

The short answer: use a risk-based DKIM rotation schedule

A practical rotation policy depends on who controls your key, how much mail you send, and the consequences of a signing-key compromise. For a typical SaaS product, ecommerce business, or application sending transactional mail, rotate a DKIM key once every 12 months. For organizations with stronger security controls, high-value brands, regulated data, many sending systems, or frequent staff and vendor changes, rotate every 6 months.

Use this baseline:

• Every 12 months: a reasonable default for a small or medium organization with a managed email provider and no sign of compromise.
• Every 6 months: appropriate for higher-volume senders, security-conscious companies, or teams with several mail streams and vendors.
• Every 90 days: useful where internal policy requires frequent credential rotation or where DKIM private keys are managed directly in self-hosted infrastructure.
• Immediately: required after suspected key exposure, unauthorized DNS access, compromised mail servers, an employee or vendor incident, or discovery of an obsolete key configuration.
• During a migration: recommended when moving a sending domain between relays, ESPs, or mail platforms, especially if the old provider generated or retained the private key.

The important distinction is that you should not simply overwrite a live DKIM record with a replacement key. Safe rotation means creating a new selector, publishing its DNS record, switching signing to that selector, validating real messages, and only then retiring the old selector after a suitable overlap period.

What DKIM key rotation actually changes

DKIM, or DomainKeys Identified Mail, adds a cryptographic signature to an email. The receiving server retrieves the sender's public key from DNS and uses it to verify that the signed parts of the message have not been altered and that the signing domain accepts responsibility for the message.

A DKIM signature includes a domain value and selector. A simplified header might look like this:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=example.com; s=mail2026a;
 h=from:to:subject:date:message-id:mime-version;
 bh=Base64BodyHashHere;
 b=Base64SignatureHere

The two fields that matter most during rotation are:

• d=example.com — the signing domain.
• s=mail2026a — the selector, which identifies the public key DNS record.

A recipient combines those values into this DNS lookup name:

mail2026a._domainkey.example.com

That name points to a TXT record containing the public key. DKIM uses DNS TXT records for this key-distribution mechanism, and selectors exist specifically so one domain can publish more than one key at once. (rfc-editor.org)

The corresponding DNS record can look like this:

mail2026a._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..."

The p= value is the Base64-encoded public key. Your sender retains the matching private key and uses it to generate signatures. Do not publish the private key in DNS, source control, deployment variables, tickets, chat transcripts, or application logs.

Rotating DKIM means replacing that private/public key pair for future signing. It does not invalidate email that has already been delivered, and it does not rewrite signatures on messages already in recipient mailboxes.

Why generating a new DKIM key matters

A long-lived private DKIM key creates a larger exposure window. If someone obtains it, they may be able to sign fraudulent messages that appear to pass DKIM for your domain until you remove or replace the associated public key in DNS.

The primary reasons to rotate are security, cryptographic hygiene, infrastructure hygiene, and operational clarity.

Limit the damage from a leaked private key

DKIM private keys can be exposed in more places than teams expect. Common failure modes include a backup containing mail-server configuration, an accidentally public repository, a copied environment variable, an over-permissioned secret store, a compromised deployment host, or a former provider retaining credentials beyond the expected period.

Rotation does not undo a past breach, but it cuts off continued use of the old key once recipients can no longer retrieve its public key. The shorter your routine rotation cycle, the less time a silently leaked key remains useful.

Replace weak or legacy cryptography

For new RSA DKIM keys, use 2048-bit RSA where your sender and DNS provider support it. RFC 8301 updates DKIM cryptographic guidance, requires signing with rsa-sha256, and requires verifiers to support RSA keys from 1024 through 4096 bits. (datatracker.ietf.org)

A 1024-bit key may still verify in some environments, but it is an aging baseline rather than a good default for a new deployment. Do not assume a selector name such as dkim2048 proves the actual key size; inspect the generated key or provider documentation instead.

A 2048-bit DKIM public key is long, so DNS interfaces may show it as two or more quoted strings. That is valid DNS syntax: adjacent quoted TXT strings are concatenated by the resolver. For example:

mail2026a._domainkey.example.com. IN TXT (
  "v=DKIM1; k=rsa; "
  "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArExampleFirstChunk"
  "ExampleSecondChunkAndRemainingPublicKeyDataIDAQAB"
)

Do not add spaces inside the Base64 public-key data unless your DNS provider explicitly formats the record that way. A space added to p= can make the key unparsable.

Separate mail streams and vendors cleanly

A single domain often sends mail through multiple systems: an application relay, a help desk, a marketing platform, an invoice service, and Google Workspace or Microsoft 365. Each system can sign using a different selector.

That is not inherently a problem. In fact, per-platform selectors make investigations much easier. A naming scheme such as the following is often more useful than generic labels like default:

app2026a._domainkey.example.com
support2026a._domainkey.example.com
marketing2026a._domainkey.example.com
workspace2026a._domainkey.example.com

Use selector names that reveal the sending stream and rotation generation without exposing sensitive implementation details. You should be able to answer, months later, which system owned app2026a, when it was activated, and who is accountable for rotating it.

Recommended schedules by environment

The right schedule should be deliberate rather than copied blindly from another company. Use the following patterns as starting points.

Managed transactional email provider

If a provider manages the private key and signs outbound email through a REST API or SMTP relay, an annual rotation is usually a practical baseline. You still need to understand whether the provider creates keys automatically, lets you add selectors, or requires you to update DNS manually.

Before changing anything, inventory every verified sending domain and subdomain. A transactional stream might sign as mail.example.com, while the visible From address is billing@example.com. For DMARC alignment, the domain in d= must align with the RFC 5322 From domain under your DMARC policy; a DKIM pass alone is not always enough.

When evaluating a provider workflow, consult its email API reference and setup guides for the exact signing-domain and DNS steps rather than assuming every SMTP or REST sender behaves the same way.

Self-hosted MTAs and direct key management

If your organization runs Postfix, OpenDKIM, Rspamd, Haraka, Exim, or another MTA and stores private keys itself, rotate at least every 6 to 12 months. A six-month cycle is preferable when keys live on general-purpose servers, are accessible to multiple administrators, or are deployed through configuration management.

A 90-day cycle can be justified in higher-security environments, but only if it is automated and tested. Frequent manual rotation invites mistakes: an unpublished selector, an incomplete DNS record, a signer still using the old key, or a deleted key before mail queues have drained.

Large organizations with multiple business units

Organizations operating many mail streams should rotate keys on a staggered schedule. Do not rotate every sender, every region, and every business unit during one maintenance window unless there is an incident that requires it.

Staggering reduces blast radius. It also provides a controlled test of your runbook: if receipts2026b fails verification, you can fix that stream without disrupting password resets, support notifications, and corporate mail at the same time.

Regulated or high-risk brands

Financial services, healthcare organizations, government contractors, marketplaces, and brands frequently targeted by phishing should generally use a six-month schedule or their stricter internal key-management policy. Their priority is not merely a successful DKIM result; it is reducing the duration for which stolen signing material can be abused.

The schedule should be tied to an owner, calendar date, change record, DNS access procedure, validation checklist, and emergency contact. A key-rotation policy that exists only in someone’s memory is not a reliable control.

Rotate immediately when one of these events happens

Routine rotation is planned. Emergency rotation is incident response. Do not wait for the next scheduled date if there is a credible reason to believe the old private key is no longer trustworthy.

Generate a new key and switch to a new selector immediately after:

1. A private key may have been exposed. Examples include a public Git commit, leaked server backup, compromised CI/CD secret, malware alert on a signing host, or a pasted key in an unprotected support ticket.
2. DNS access may have been compromised. An attacker who can edit your DNS can publish their own DKIM selector or remove yours, which can disrupt authentication and enable other forms of abuse.
3. You leave an email provider or revoke a vendor relationship. If the provider generated or operated the key, assume access and lifecycle control changed until you confirm otherwise.
4. You discover a weak key or obsolete algorithm. Move away from configurations that cannot support modern signing requirements, particularly if they use deprecated rsa-sha1 signatures.
5. A key is shared across systems that should be isolated. Splitting one shared key into distinct selectors per platform reduces future blast radius.
6. Authentication reports or message headers show unexpected signing. An unfamiliar d= domain, selector, or signing system is a reason to investigate before assuming it is harmless.

An emergency rotation should be accompanied by access review. Replacing a DKIM key while leaving the original secret exposure path open only creates a new key that may be exposed the same way.

How to rotate a DKIM key without breaking delivery

The safest process is an overlap, not a swap. Publish the future public key before any sender uses the corresponding private key, then observe real mail signed with the new selector before removing the old DNS record.

Step 1: inventory the current state

Record the following for every sender:

• Sending domain and visible From domain.
• Current selector, for example app2025a.
• Signing algorithm and RSA key length.
• System or provider that holds the private key.
• DNS zone and account that publishes the public key.
• Current TTL value.
• DMARC policy and alignment mode.
• Owners for engineering, deliverability, DNS, and security response.

Send a test message to a mailbox you control and inspect the full headers. Look for a result similar to:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=app2025a;
       spf=pass smtp.mailfrom=mail.example.com;
       dmarc=pass header.from=example.com

Header layouts vary by recipient, but a successful result should identify the signing domain and selector. This provides a baseline before you make changes.

Step 2: create a new selector and key pair

Choose a new selector that cannot collide with an existing one, such as app2026b. Generate a fresh key pair through your email provider, MTA tooling, or approved cryptographic workflow.

For an RSA key, the public DNS record should include at least v=DKIM1 and p=. The k=rsa tag is optional because RSA is the default in the DKIM key record grammar, but including it can improve readability:

app2026b._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=YOUR_BASE64_PUBLIC_KEY"

Avoid copying examples literally. YOUR_BASE64_PUBLIC_KEY must be the public half of the newly generated pair, with no PEM header such as -----BEGIN PUBLIC KEY----- and no private-key material.

Step 3: publish the TXT record and verify DNS

Create the TXT record in the authoritative DNS zone. The exact field names vary by DNS host, but the essential values are always the hostname, record type, and TXT content:

Host/name: app2026b._domainkey
Type: TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkq...
TTL: 300 or 3600 seconds during a planned change

Some DNS dashboards automatically append your domain. In those systems, entering the full hostname app2026b._domainkey.example.com may accidentally create app2026b._domainkey.example.com.example.com. Check the rendered record name after saving.

Use independent DNS checks before enabling signing. Examples include dig, nslookup, MXToolbox, and a DKIM lookup service. With dig, query the full selector name:

dig +short TXT app2026b._domainkey.example.com

You want to see the expected v=DKIM1 record and complete public key. If the output is split across quoted strings, that can be normal. What matters is that the DNS response contains the exact record and that a DKIM parser accepts it.

Step 4: switch signing to the new selector

After DNS is visible, configure the sender to use the new private key and s=app2026b. In a managed system, this may involve activating a new domain-signing configuration. In a self-hosted system, it may mean deploying a new private-key file and updating the signing table or selector mapping.

Do not delete app2025a yet. At this point, newly generated messages should contain s=app2026b, while recipients can still validate older messages and delayed mail that reference app2025a.

Step 5: send real validation messages

Test more than one recipient ecosystem if possible. Send to Gmail, Outlook.com or Microsoft 365, Yahoo Mail, and a mailbox hosted on a different provider. A staging mailbox is useful, but real recipient infrastructure catches DNS, signature, canonicalization, and alignment issues that local tests may miss.

Review full headers and confirm:

• dkim=pass appears for the intended signing domain.
• The message uses the new selector.
• SPF and DMARC still pass where expected.
• The visible From domain aligns with DKIM or SPF for DMARC.
• HTML and plain-text versions render correctly.
• Attachments or message modifications are not causing signature failures.

You can also send a test to mail-tester.com for a practical deliverability-oriented report. Use it as a diagnostic aid, not as the sole authority on inbox placement or authentication correctness.

Step 6: keep the old selector during an overlap period

Leave the old public key published for at least several days after switching. A common operational choice is 7 to 14 days, with longer overlap for low-volume systems, long retry queues, or uncertain DNS propagation behavior.

Why retain it? Mail can sit in outbound queues, be retried after temporary failures, be forwarded, or be inspected after delivery. The key record does not need to remain forever, but removing it immediately makes troubleshooting harder and can cause verification failures for messages signed just before the change.

Step 7: retire the old key deliberately

Once you have confirmed that all active mail streams use the new selector and the overlap period has passed, remove the old private key from the signing system and delete or revoke access to all copies. Then remove the old DNS TXT record.

Retiring the private key is as important as deleting the public DNS record. If old keys remain in backups or configuration directories, document that fact and ensure backup access is controlled. A deleted DNS record prevents ordinary verification of signatures using that selector, but it does not erase an exposed private key from an attacker’s possession.

DNS TTL, caching, and timing considerations

DNS changes are not always visible everywhere at once. A TTL tells resolvers how long they may cache a response, but actual behavior can also be affected by resolver caching, negative caching, authoritative-server timing, and provider configuration.

For a planned rotation, reduce the TTL before the change if your DNS provider allows it and if you have enough lead time. A value such as 300 seconds can make iterative testing faster. After the change is stable, return to a normal TTL that fits your operations, often 3600 seconds or more.

Do not treat a short TTL as a guarantee of instant global propagation. Verify from more than one resolver and wait for actual signed messages to arrive with DKIM passing. The correct sequence is publish, verify, enable, validate, overlap, retire.

A common mistake is deleting the old TXT record and then discovering that a separate sender—such as a CRM integration or legacy application—still signs with that selector. Inventory first, and use DMARC aggregate reports to detect unexpected ongoing DKIM identifiers.

DKIM rotation and DMARC alignment

DKIM is most valuable when it contributes to DMARC alignment. DMARC checks whether the domain used by a passing DKIM signature aligns with the domain in the visible From header.

For example, this can align:

From: Acme <receipts@example.com>
DKIM d=example.com

This can also align under relaxed alignment because mail.example.com is a subdomain of example.com:

From: Acme <receipts@example.com>
DKIM d=mail.example.com

But this normally does not align:

From: Acme <receipts@example.com>
DKIM d=provider-mail.net

The message may show dkim=pass, yet fail DMARC if SPF does not align either. This is why a DKIM rotation is a good time to review the actual d= value on delivered mail, not merely confirm that a TXT record exists.

Google’s sender guidelines require bulk senders to Gmail to use SPF, DKIM, and DMARC, while also requiring alignment for DMARC. (support.google.com) A key rotation that changes the signing domain unexpectedly can therefore create a deliverability problem even when the new cryptographic signature is technically valid.

Common DKIM rotation failures and how to diagnose them

Most DKIM rotation incidents are configuration and coordination issues, not cryptographic failures. The following symptoms point to different parts of the process.

dkim=neutral or “no key for signature”

This often means the recipient could not find a usable TXT record at selector._domainkey.domain. Check the selector in the message header, the full hostname in DNS, accidental doubled domains, and whether the DNS record is published in the correct zone.

Also confirm that you did not use a CNAME where your platform expected a TXT record, or vice versa. Some providers use CNAME delegation for DKIM, while others provide a direct TXT value. Follow the provider’s exact instructions rather than converting one record type into the other.

dkim=fail after the new selector is visible

A visible record does not prove that it matches the private key used for signing. A DKIM fail commonly means the wrong public key was pasted, the private key and public key belong to different pairs, a DNS value was truncated, or the message was altered in a signed part after signing.

Inspect the DKIM-Signature header and compare the selector with the DNS name. Then regenerate a clean key pair if you cannot establish that the private and public values match.

dkim=permerror

A permanent error usually indicates a malformed or unsupported DKIM setup rather than temporary DNS trouble. Examples include malformed tags, invalid Base64 content, multiple conflicting records, or a key record that cannot be parsed.

Check for smart quotes, hidden line breaks, copied PEM labels, and an extra space inserted into p=. DNS editors that wrap long text can be safe, but only when they use valid TXT-string splitting.

SMTP success does not mean DKIM success

An SMTP server response of 250 2.0.0 Ok generally means the receiving server accepted the message for further handling. It does not guarantee inbox placement, a valid DKIM signature, or a DMARC pass.

Likewise, an HTTP email API response such as 202 Accepted commonly means a service accepted your request for asynchronous processing. It is not proof that the message was signed correctly or delivered. Treat API acceptance, SMTP acceptance, delivery events, and authentication results as different checkpoints.

A rejection such as 550 5.7.26 from Gmail can be associated with unauthenticated mail that fails sender requirements, but exact responses vary by recipient and configuration. Use the complete SMTP transcript, recipient feedback, and message headers when diagnosing an authentication failure.

Build DKIM rotation into normal operations

The best time to design a rotation procedure is before an incident. Make it routine, boring, and reversible.

A durable operational policy includes:

• A selector naming convention, such as serviceYYYYletter.
• A documented owner for each sender and DNS zone.
• Separate selectors for separate providers or sending purposes.
• A calendar reminder and ticket created before the expiration target.
• A tested change checklist with rollback instructions.
• Header-based validation from real recipients.
• DMARC aggregate-report review after every rotation.
• Secure storage and access logging for private keys.
• A written emergency process that does not depend on one administrator.

If you send from an application, include DKIM verification in release and infrastructure checks. For example, an integration test can trigger a password-reset email through the production-like SMTP relay or API, retrieve it from a test mailbox, and assert that the intended d= and s= values appear with dkim=pass.

Before adding new addresses to important transactional flows, use an email address verification tool to reduce obvious address-quality issues. That is separate from DKIM, but separating recipient validation, sender authentication, and delivery monitoring makes email operations easier to diagnose.

A practical policy you can adopt today

If you need one simple policy, adopt this:

Generate a new 2048-bit RSA DKIM key every 12 months, rotate using a new selector, maintain the prior selector for 7–14 days after cutover, and rotate immediately after a suspected compromise or provider change.

Adjust that to every six months when your risk profile, volume, compliance requirements, or internal key-management policy warrants it. The goal is not rotation for its own sake. The goal is to reduce the useful life of compromised signing material while preserving uninterrupted authentication and DMARC alignment.

A rotation is successful only when the new selector is visible in DNS, new messages are signed with it, recipients report dkim=pass, DMARC remains aligned, and the old key is retired after overlap. If one of those conditions is missing, the work is incomplete.

FAQ

How often should you generate a new DKIM key?

For most senders, generate a new DKIM key every 6 to 12 months. Use 12 months as a practical default and six months for higher-risk, higher-volume, or more regulated environments.

Do DKIM keys expire automatically?

No. DKIM does not include a universal automatic expiration date for keys. A selector remains usable while the matching private key signs mail and the public key remains available in DNS.

Should I overwrite my existing DKIM TXT record?

Usually no. Create a new selector and publish a new TXT record first. Switch signing to the new selector, validate it in real message headers, keep the old selector during an overlap period, and then retire the old key.

How long should I keep an old DKIM record after rotation?

Keep it for at least several days; 7 to 14 days is a practical overlap period for many senders. Use a longer period if you have long delivery queues, low-volume systems, or multiple teams that may still use the old selector.

Does a DKIM pass guarantee good deliverability?

No. DKIM proves that a signature can be validated, but inbox placement also depends on DMARC alignment, SPF, sender reputation, complaint rates, content, engagement, recipient behavior, and provider-specific filtering.