Issue Plesk Forwarding & DKIM Authentication: How to Ensure Matching Signatures?

[HoracioS]

Server operating system version

Ubuntu 24.02

Plesk version and microupdate number

18.0.65

Hi!

I'm facing an issue with DKIM authentication when forwarding emails in Plesk. When I forward an email, the "From" field is correctly modified to reflect the new sender, but the DKIM signature remains tied to the original domain.

Why doesn't Plesk automatically update the DKIM signature to match the new domain when the "From" field is changed during forwarding? The current behavior is causing email delivery issues, as the DKIM signature doesn't align with the actual sender domain.

I'm looking for a way to configure Plesk so that it generates a new DKIM signature that matches the Plesk domain client whenever an email is forwarded and the "From" field is modified. This would ensure that the DKIM authentication passes successfully and prevents emails from being rejected.

4520C100323 3381355 Wed Nov 6 19:36:27 SRS0=U2Xq=SB=gmail.com=[email protected]
(host gmail-smtp-in.l.google.com[2607:f8b0:4004:c21::1a] said: 421-4.7.30 Your email has been rate limited because DKIM authentication didn't 421-4.7.30 pass for this message. Gmail requires all bulk email senders to 421-4.7.30 authenticate with DKIM. 421-4.7.30 421-4.7.30 Authentication results: 421-4.7.30 DKIM = did not pass 421-4.7.30 To set up DKIM for your sending domains, visit 421-4.7.30 Set up DKIM - Google Workspace Admin Help 421-4.7.30 To learn more about Gmail requirements for bulk senders, visit 421 4.7.30 Email sender guidelines - Google Workspace Admin Help. d75a77b69052e-462ff45b37fsi11666851cf.176 - gsmtp (in reply to end of DATA command))
[email protected]

Best regards,
Horacio Stolovitzky

 

[Aslanj]

If Plesk updates the DKIM signature when forwarding a message, wouldn't that defeat the purpose of ARC preserving the original DKIM signature for verification? I might be confused about this, to be honest. I can see in my tests that ARC is preserving the body hash of the original message, however, probably because of a slight alteration of the body content, the b= tag is different and hence the expected body hash isn't matching the preserved one. If that's the case, wouldn't we simply need a way to preserve the original content in an absolute manner? Or do the differences in encoding make it impossible to have one solution for all of this? Very interested in learning more, though.