Issue Plesk does not retain DKIM keys during server migration

[TorbHo]

Server operating system version

Ubuntu 24 LTS

Plesk version and microupdate number

Plesk Obsidian 18.0.70 Update 2

We recently migrated many domains from one Plesk server to another using the official Plesk Migrator. After the migration, we noticed that the existing DKIM keys were not transferred. Instead, Plesk automatically generates new DKIM private keys for each domain on the destination server.

This causes several issues:

• DKIM verification fails for previously sent emails still in the mail queue, as their signatures no longer match.
• New keys require updating the DNS default._domainkey TXT records for every domain.
• This breaks DKIM validation until DNS records are manually updated.

In our setup, we use an external DNS provider, not the built-in DNS server in Plesk. We also manage hundreds of domains per server, so manually updating each domain’s DKIM TXT record is not a viable option.

I found this support article describing the problem, which appears to be over two years old:

https://support.plesk.com/hc/en-us/...tion-fails-dkim-fail-body-hash-did-not-verify

According to that article, Plesk still does not support DKIM key transfer during migration, nor does it offer a workaround to import existing keys manually.

Here are my questions:

1. Why doesn’t Plesk preserve existing DKIM private keys during migration?
2. Is there any supported way to export and re-import DKIM keys so the same DNS records can be used after migration?
3. Is this issue still being worked on? If yes, when can we expect a proper fix?

This is becoming a serious problem for us in production environments when moving to a new server. Any insights or recommendations would be greatly appreciated.

 

[Bitpalast]

I can confirm that this is still an active issue and would also like to have it fixed.
The number of support tickets Plesk receives on an issue can determine whether a fix is prioritized. So if you are able to file a support case for it, please do so.

 

[TorbHo]

Since yesterday, GMX and Web.de – two of the largest email providers in Germany – have started strictly enforcing DKIM verification for incoming mail. This has led to major delivery issues after the migration, as emails without valid DKIM signatures are now being rejected.

This raises the urgent question:

• Is it possible to requeue or resend emails currently stuck in the mail queue so that they are signed again with the new valid DKIM key?

 

[Bitpalast]

With Postfix and OpenDKIM, the DKIM signature is added at the moment the message is sent via the smtp transport, not when the message is queued. Postfix sends the message to OpenDKIM via milter during the "smtp" delivery phase. OpenDKIM signs the message and passes it back to Postfix. The signed message is then transmitted to the recipient's mail server.

So if a message is in the Postfix queue:
- It is not DKIM-signed yet.
- When it is finally sent (retried from the queue), the DKIM signature is added fresh at that time.

If you inspect the message in the mail queue (postqueue -p or postcat -vq <queue_id>), you will not see a DKIM-Signature header yet. Please verify my response by checking this on your server.

 

[TorbHo]

@Bitpalast Thank you.

I’ve checked this on my server using postcat -vq <queue_id> and can confirm that there is no DKIM-Signature header present in the queued messages. This confirms that Postfix indeed seems to sign the message at the time of actual SMTP delivery, not at the time of queuing.

However, despite that, the affected emails remain stuck in the mail queue and are not being retried successfully. They are repeatedly rejected by the recipient server (in this case, web.de).

The bounce message includes a reference to this page:

451 Requested action aborted Reject due to policy restrictions

postmaster.web.de

This page explains that messages without valid DKIM signatures are now being rejected, and recommends proper DKIM configuration.

Even though DKIM is now properly enabled on the new server, queued messages sent before DKIM was activated are not signed when retried – and are rejected due to missing or broken DKIM.

So far, Postfix does not seem to automatically reprocess or re-sign these messages upon retry.

Is there any reliable way to force Postfix to re-sign queued messages with DKIM, now that DKIM is active?

Any suggestions would be appreciated.

 

[Bitpalast]

Proper DKIM configuration is only required for web.de and GMX if the incoming traffic from your IP is high (e.g. if you are sending mass mails to their services).

As I understand from the documentation of Postfix and other sources, outgoing messages are signed when it is attempted to transmit them to the recipient's mail server. This will happen each and every time a message is sent. Whether it is queued or not (actually, ALL messages are queued, but for the first queueing you just won't notice that; email is never sent without going through the outgoing message queue). As far as I understand it, re-signing a mail is not necessary (and not possible), because there is actually no signature in the queued mail. It is auto-signed upon the next transmission attempt.

Have you considered using mail-tester.com to verify that your setup is correct?

 

[TorbHo]

Thank you for your input.

However, in our case the situation is a bit more nuanced.

We’re operating a system with around 200 customers on a single server, and many of them have auto-forwarding from their business address to private GMX or Web.de mailboxes. That means we’re not sending mass marketing emails, but we are generating a steady stream of forwarded messages to GMX/Web.de domains throughout the day — and especially at night when batch systems trigger report mails, etc.

While this may not qualify as "mass mailing" in the classic sense, GMX and Web.de apparently interpret the volume as “high” enough to enforce stricter checks, including mandatory DKIM verification, regardless of DMARC policy (even when it's set to p=none).

We’ve already:

• Verified that DKIM is correctly configured and working
• Seen that ARC headers are present, as messages pass through a Mailcow-based MX gateway
• Confirmed that the forwarded messages are being signed upon delivery attempts

Yet, messages still pile up in the mail queue, and delivery to GMX/Web.de is repeatedly deferred or rejected. Last night, mails were finally accepted — but it took many hours. Now, the queue is growing again.

This suggests that DKIM compliance alone may not be enough if the upstream reputation or retry behavior doesn't meet GMX/Web.de’s expectations. Also, their interpretation of “high traffic” seems quite strict — possibly on a per-IP or behavioral basis.

We’ve also tested with mail-tester.com (good suggestion!) and consistently get a 10/10 score, so from a technical perspective everything looks fine — but real-world delivery behavior is still problematic.

So while in theory everything works as expected, in practice forwarded mail volumes to GMX/Web.de are triggering enforcement that goes beyond documentation, and that’s what we’re struggling with.

If you (or anyone) has experience tuning Postfix or OpenDKIM for better performance with GMX/Web.de — or has suggestions regarding SRS or ARC handling — we’d be very interested.


This entire issue only arose because DKIM was already correctly configured on the source server. During migration, Plesk failed to retain the existing DKIM private keys and instead generated new ones — without providing any option to preserve or import the original keys. As a result, hundreds of mail accounts that were previously correctly configured are now sending messages with invalid DKIM signatures, since the public DNS records still point to the old keys. This is not a misconfiguration on our side, but a direct consequence of a long-standing limitation in Plesk’s migration process.

We therefore urge the Plesk development team to finally address this issue by implementing a reliable way to retain or import DKIM keys during server migrations. This problem has been known for years, and it continues to cause real-world deliverability issues in production environments.

 

[Bitpalast]

Forwarded messages are not DKIM signed.

GMX and other United Internet freemail services are famous for temporarily banning IPs from where excess traffic is seen. There is nothing one can do about it and GMX are nit interested in changing that either. It's nit at all DKIM issue. That's just their long stabding policy.

 

[TorbHo]

To return to the original topic:

When will the DKIM migration issue finally be addressed?
This problem has been known for years, and it's still affecting anyone who relies on external DNS and expects consistent DKIM functionality after migrating between Plesk servers.

In the meantime, is there any supported way to export the existing DKIM private keys from the source server and import them on the new server, so that the same default._domainkey DNS records remain valid?

A manual workaround would at least help prevent large-scale mail delivery issues immediately after migration — especially now that mail providers enforce DKIM much more strictly.

 

[Sebahat.hadzhi]

Hello, guys. Our team is currently working on introducing a fix for the issue with the DKIM records migration. The ETA is the end of August. Unfortunately, there is no workaround apart from moving the records manually.

 

[TorbHo]

@Sebahat.hadzhi Thank you for this information, good to hear they are working on this now. I understand these things take time, but I quietly hope for a quicker resolution, as we have several server migrations coming up soon due to aging software.