• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Resolved Location > DKIM verification > Plesk milter (Postfix) / Postfix within Plesk

learning_curve

Silver Pleskian
Slightly detailed explanation, but at least there's only one question at the end :) and we're sure that somebody on here, will know the answer. We're almost at the stage of successfully applying DKIM to all PHPMailer sent e-mails on some of our domains that now require this option. We're testing and running trials on one specific domain at present, until the whole mail service (with all the required options available) is operating at 100%. When this is achieved, we'll then implement it on all the others. We use 3rd party provided DNS, not the Plesk service. This isn't an issue however, as the Plesk Docs confirm:
Important: If you use an external DNS service, DKIM signing will work for outgoing messages, but the receiving mail server will not be able to validate these messages. As a workaround, you can switch off Plesk DNS server and add a corresponding DKIM-related DNS record on the external DNS service. In this case, the receiving server will be able to validate the messages.
To successfully run DKIM on PHPMailer, we needed new public and private keys for each domain that would need the DKIM / PHPMailer. That's easy to do and put in place, i.e. a new DKIM-related DNS record and a new location for the private key.

DKIM / PHPMailer then does work perfectly but... all the normal (i.e. all the Non-DKIM / PHPMailer provided) test e-mails (depending on which e-mail client is being used) then suffer from dkim=fail reason=“signature verification failed” or dkim=permerror (bad sig) or dkim=fail errors, which, we're pretty sure (in our case anyway) is related to Plesk milter (Postfix) and/or Postfix (within Plesk) not seeing the new, updated domain DNS for some reason :(

The DKIM errors remain, even after reloading, restarting both Plesk milter (Postfix) and/or Postfix and even after a server restart / reboot. If we restore the original DKIM-related DNS record, then all the Non-DKIM / PHPMailer provided test e-mails are correct once again, but the DKIM / PHPMailer provided test e-mails now fail. This is easy to follow, because they now have incorrect location data for the DKIM private key... (and to answer the obvious question; no, obviously we don't know where it is either, hence the new DKIM keys at the start etc)

So our question is... ;) Where exactly and/or how is the original DKIM-related DNS record verified by Plesk milter (Postfix) and/or Postfix? Once we know that, we're thinking we can solve this quite quickly... Sorry if we've missed this information elsewhere, we've searched but can't quickly see it anywhere - yet :p
 
Last edited:
We tried a more "simplistic" approach by switching the domain level setting: Use DKIM spam protection system to sign outgoing email messages on and off (effectively a reset) which didn't work and then trying the same thing with the server level setting: DKIM spam protection > Allow sigining outgoing mail which didn't work either, so it's not solved yet. With DKIM turned off in either case, there are obviously no errrors (apart from a lack of DKIM being reported :D) Frustrating, as it seems to be just an internal config setting / update that needs to be carried out...somewhere.... after the previous DNS change...

Interesting to see this previous (similar) thread also remains unanswered at present...
 
Update... The original DKIM DNS Record etc is applied by Plesk / Postfix as described here The extract being:
After you have activated DKIM for a domain, Plesk adds the following two records to the DNS zone of the domain:
  • default._domainkey.<example.com> - contains the public part of the generated key.
  • _ domainkey.<example.com> - contains the DKIM policy.
There's no mention of where the private key is stored / located ;) which is why we didn't know for the original DKIM DNS Record. We only know for the replacement DKIM DNS Record which we created (outside of Plesk) and so we stored it etc.

FAO @themew Ref Your Post and FWIW To make PHP mailer run properly (and reliably), we DID need the private key (and it's location etc) but this then unfortunately causes the previously mentioned error in all the Non-PHPMailer created e-mails, as the access to the new private key isn't given by default and it's (presumably) still looking / referring to the original (hidden) key which means all the Non-PHPMailer created e-mails fail DKIM checks. The Plesk Mystery Location... We will find it soon :cool:
 
Sometimes... it's far more simple than at first thought... The 'hidden' location for the original Plesk issued DKIM private key is actually 'hidden in plain sight' :D All the various domains have their DKIM private keys stored as follows: "Private keys are located in the corresponding domain directory in /etc/domainkeys/ For example, /etc/domainkeys/example.com/default (for selector "default")"

This is shown on THIS Plesk Support page, which was produced for people wanting to re-create their Plesk issued DKIM public key from the existing private key. That's not what we are/were doing ;) but handily enough for us, the location is given on that page. Surprised that nobody from Plesk didn't just tell us that earlier, but maybe nobody had time back then, which is understandable during busy forum times.

We replaced the original private key with the new one that we had created outside Plesk and tested everything on the trial domain, with sucess on all the tests.

This means @themew that we can now succesfuly, apply DKIM to ALL e-mails (including all the PHPMailer created e-mails, which we couldn't before...) from any correctly setup domain on our server.

Happy with that and with hindsight, it can be done within Plesk, using the exising public / private keys but with just a PHP mailer config edit. We'll post that shortly...
 
@themew FYI here's the DKIM data for you. This is for domains (in our case) that are using PHPMailer as part of a package povided by e-commerce suppliers and we are not using Plesk DNS at all on our server currently. Your experience may differ. After lots of different trial and error tests , our approach was:

1) Generate new DKIM keys (You can do that very easily HERE and test everything afterwards)
2) Use the public key within our 'external to Plesk' DNS setup
3) Use the private key and save this as 'default' within the correct domain having first saved and removed the Plesk file that is already there, the result being: /etc/domainkeys/example.com/default
4) Also save a separate copy of this private key elsewhere, just in case this one is overwritten by Plesk in the future (it can be for example, if you turn DKIM on and off at Domain level within Plesk, even if you're not using Plesk DNS...)
5) Then amend the PHPMailer file as follows:

Code:
/**
     * DKIM selector.
     * @var string
     */
    public $DKIM_selector = 'default'; //Prefix for the DKIM selector

    /**
     * DKIM Identity.
     * Usually the email address used as the source of the email.
     * @var string
     */
    public $DKIM_identity = ''; //Not needed in our case

    /**
     * DKIM passphrase.
     * Used if your key is encrypted.
     * @var string
     */
    public $DKIM_passphrase = ''; //Leave blank if no Passphrase utilised

    /**
     * DKIM signing domain name.
     * @example 'example.com'
     * @var string
     */
    public $DKIM_domain = 'example.com';

    /**
     * DKIM private key file path.
     * @var string
     */
    public $DKIM_private = '/etc/domainkeys/example.com/default';

    /**
     * DKIM private key string.
     * If set, takes precedence over `$DKIM_private`.
     * @var string
     */
    public $DKIM_private_string = '';

6) Test everyting; i.e. DNS, e-mails (PHPmailer and all NON-PHP mailer) - It should all work perfectly (does for us)

With the benefit of hindsight, it's actually simple (in our case anyway), but not originally having the Plesk original private key location, was a hindernace until we found it. Then it was straightforward after that.
 
Last edited:
The issue is the perms on the default private key file preventing phpmalier from reading I guess. anyone know what they should be.
 
The issue is the perms on the default private key file preventing phpmalier from reading I guess. anyone know what they should be.
The default Plesk permissions on their own private keys are 440. We (wrongly) assumed that we would need to use the same permissions when adding our Port25 / Non-Plesk private keys... but that produced the phpmailer key access issues similar to those that you're having... We use the permissions shown on the attached image, which allows phpmailer in our setups to operate sucessfully.
 

Attachments

  • Key.png
    Key.png
    47.4 KB · Views: 33
Last edited:
Thanks for reply. I am definately not an expert in Linux permissions but as this is private key is public read permissions a good idea ?
I added the plesk apache user to the permissions list for the file as follows which works but dont know which is better option.

Code:
sudo setfacl -m u:pleskuser:rx /etc/domainkeys/example.com/default
 
...I added the plesk apache user to the permissions list for the file as follows which works but dont know which is better option
Code:
sudo setfacl -m u:pleskuser:rx /etc/domainkeys/example.com/default
We've edited our last two posts, the idea being that others may find this thread useful in the future. The initial question asked was about the location of /etc/domainkeys which was self-resolved but then expanded for using DKIM with phpmailer etc

Your post above has made us change our mind ;) Initially we too had a DKIM private key access issues for phpmailer (but not exactly the same as yours and we didn't post about it until you raised the question later in the thread) which after some tracing, we resolved by allowing execute permission for the groups that the various phpmailers (via APIs) were a members of. Hence the 450 not 440 permission requirements as posted previously. No problem with that solution, if we're honest because it's secure and works fine. However, we've now re-configured it all, because altering all the ACLs that are involved is probably better, all things considered.

So, in our case, we needed to amend ACLs on both the phpmailers (via APIs) and on the DKIM private keys, then return the DKIM private keys' permissions to 440 again, then test everything again. https://port25.com/ has DKIM tests equal to those of DKIM, SPF, and Spam Assassin Validator - dkimvalidator.com but all was fine on both anyway.

To finish it (belt and braces) we then re-created new DKIM pairs of keys, altered all the new ACLs and replaced all the existing DKIM pairs of keys, so that the whole setup was fully overhauled. CLI usage: chown | chgrp | getfacl | setfacl

Just as an example once complete, here's one of the DKIM private keys (but sanitised e.g. keyfile) when viewed via getfacl
Code:
/etc/domainkeys/my-domain.com# getfacl keyfile
# file: keyfile
# owner: ownername
# group: groupname
user::r--
group::r--
group:addedgroup1:r--
group:addedgroup2:r--
mask::r--
other::---
and when viewed via ls -la
Code:
-r--r-----+ 1 root popuser 1674 Sep 29 16:12 keyfile
with the + showing there are additional groups (in this case) and root | popuser being the default Plesk assigned values
 
Back
Top