Mustapha Hadid

Hi Palijn,

We noticed that you are using an incorrect value for the DB_CHARSET config since utf8mb4_unicode_ci is a collation, not a character set. To find the acceptable values, run the “show character” command you mentioned and refer to the first column of the generated table.

Please use the following configuration for a correct setup:

define('DB_CHARSET', 'utf8mb4'); 
define('DB_COLLATE', 'utf8mb4_unicode_ci');

Also, keep in mind that changing the DB_CHARSET and DB_COLLATE configs may cause data corruption or unexpected behavior if your existing tables are not converted to the desired charset/collation combination before changing the relevant configs.

Follow the official documentation to convert your database character sets properly.

• This reply was modified 1 year, 9 months ago by Mustapha Hadid.
• This reply was modified 1 year, 9 months ago by Mustapha Hadid.

Hello @kashmiri, thank you for taking the time to post about this.

This is expected as the DKIM key mailpoet1 is actually a retired key (inactive). The only active key we’re using for DKIM signing, as of today, is mailpoet2.

We are following the M3AAWG recommendation to retire inactive DKIM keys after rotation by setting the ‘p’ field to empty (‘…p=’). Therefore, any DKIM with an empty ‘p’ field indicates that the key was intentionally retired.

Thank you, again, for bringing what you have considered an issue to our attention.