Ahh, @9peppe, test+evaluation is usually not done in the production environment. Would You think me a good sysop when I did these experiments on the live mailserver?
I fact I am doing them on the live environment 
- but moon is not the name it actually answers to for smtp. (You could have looked for the mx of daemon.contact.)
Let me help You out:
# openssl s_client -connect webs-e.intra.daemon.contact:25 -starttls smtp
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = moon.daemon.contact
verify return:1
---
Certificate chain
0 s:CN = moon.daemon.contact
i:C = US, O = Let's Encrypt, CN = R3
1 s:C = US, O = Let's Encrypt, CN = R3
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
i:O = Digital Signature Trust Co., CN = DST Root CA X3
3 s:O = Digital Signature Trust Co., CN = DST Root CA X3
i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
But we knew that already.
What's more interesting is the -rarely read- documentation of sendmail:
When acting as a serv er, sendmail requires X.509 certificates to support ST ARTTLS: one
as certificate for the server (ServerCertFile and corresponding pri vate Serv erKeyFile) at least
one root CA (CACertFile), i.e., a certificate that is used to sign other certificates, and a path to a
directory which contains (zero or more) other CAs (CA CertPath). The file specified via CA C-
ertFile can contain se veral certificates of CAs. The DNs of these certificates are sent to the
client during the TLS handshake (as part of the CertificateRequest) as the list of acceptable CAs.
However, do not list too many root CAs in that file, otherwise the TLS handshake may fail; e.g.,
error:14094417:SSL routines:SSL3_READ_BYTES:
sslv3 alert illegal parameter:s3_pkt.c:964:SSL alert number 47
You should probably put only the CA cert into that file that signed your own cert(s), or at least
only those you trust.
What I learned, is, that of these three files
cacert.pem
host.cert
host.key
the key is the key, the cert is the cert, and the cacert.pem is the chain, i.e. the collection of intermediate certificates that are needed for the adversary to get to one of their known root ca certs, which obviousely must be sent to the adversary during handshake.
But here the doc talks about something different: it appears to say that the cacert.pem contains a "list of acceptable CAs".
The outdated DST ROOT should proably not be in such a list.