I use postfix/dovecot as our mail server on grepa.ca. There is no issue with everything that is browser related. However, each time the certificates expire, Apple clients (mail on Mac OS, Mail on Apple OS, etc.) complain that the certificates can no longer be trusted. The problem does not seem to pervade to Windows/Linux clients, or third party mail clients installed on Android (e.g. Nine).
I have found two "solutions" thus far:
Asking clients to delete and re-install their email accounts. (known to work).
Each time the certificates are renewed, restart postfix and dovecot. I think this second option reloads both daemons with the latest certificates, but I do not know yet if it works (I will have to wait three months).
Obviously, workaround 1 is not a viable one from a client/customer perspective. As my server is not hosted with Plesk the discussion on the plesk forum is not really applicable to my case. My assumption is also that Apple has some better knowledge than me on the management of certificates, which leads me to think that I probably have a configuration issue.
That being said, the problem is beyond my expertise. I am happy to provide any details to help resolve the matter.
This is always required after certificate renewal and that includes webservers too. However, not everyone knows this, as for example the nginx and apache installer plugins of the certbot ACME client reload the webserver during the installation part of their activities, including at renewals. So for some users, this just happens without their knowledge. However, a reload is always mandatory and for services such as Postfix/Dovecot, this has to be done manually or through a --deploy-hook in certbot.
This, in some form, is going to be necessary with any service that uses a certificate--when you get a new cert (and a "renewal" is still a new cert--same information, different dates), you need to tell the service to use the new cert. Some services (most web servers, for example) have a mechanism to "reload" the configuration, which will re-read the server's configuration files and certificate(s) without service interruption--I don't know if postfix or dovecot support this. Otherwise, simply restarting the service should work.
The problem this will solve is if your mail server is still serving the old cert after a new cert has been issued. If the problem is instead that the new cert isn't being recognized (i.e., you're serving the new cert, but the client system doesn't like it for some reason), this won't help you.
Edit: At the moment, postfix is serving a certificate issued a month ago to your domain name:
dan@Dan-MacBook-Pro-2013 ~ openssl s_client -starttls smtp -crlf -connect grepa.ca:587
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
depth=1 C = US, O = Let's Encrypt, CN = R3
depth=0 CN = grepa.ca
1 s:/C=US/O=Let's Encrypt/CN=R3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
No client certificate CA names sent
Server Temp Key: ECDH, X25519, 253 bits
SSL handshake has read 3286 bytes and written 324 bytes
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
No ALPN negotiated
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - 7a 81 a5 e4 7a 32 cb 9f-14 48 6f f3 58 4d 20 a2 z...z2...Ho.XM .
0010 - 8a e6 cf 5b 4c 73 a1 ad-55 c0 70 d2 84 6d cf 69 ...[Ls..U.p..m.i
0020 - 78 9f 5d f2 ac 8b dd 9e-9c 09 06 8c 6f c7 e8 83 x.].........o...
0030 - 61 43 c9 ab 0a 37 99 7a-35 f1 a5 06 07 64 86 1b aC...7.z5....d..
0040 - 98 04 16 bf 5a f2 c6 ec-c2 bf 91 82 ad 39 4d 83 ....Z........9M.
0050 - 34 da d2 c9 1e 10 7d 46-0f 3b c8 b5 6e 2a da b7 4.....}F.;..n*..
0060 - 8b d9 a4 c1 ff 82 11 6b-6d e7 07 c4 de c8 f3 00 .......km.......
0070 - 94 19 13 ba 1b ef ee ce-a2 e8 73 78 c9 c3 37 fb ..........sx..7.
0080 - 29 6f 04 06 c3 99 3f 00-ce 1d 1a 64 cc 61 ee 82 )o....?....d.a..
0090 - 3c 6e 6f 0a 3b 82 27 c0-86 63 49 ad 75 cc f1 e6 <no.;.'..cI.u...
Start Time: 1622129071
Timeout : 7200 (sec)
Verify return code: 0 (ok)
I then pasted the cert into Certificate Decoder - Decode certificates to view their contents to get the valid dates; openssl can do this for you as well, but I don't remember the incantation to make it do so. But right now, it's looking good. To test before three months are up, you could force-issue a cert now, reload postfix, and try the same check to see if it's serving the new cert.