A typical mail server setup involves two separate services — Postfix (SMTP, for sending/receiving mail) and Dovecot (IMAP/POP3, for retrieving mail) — each needing its own TLS configuration pointed at the certificate, even though they can share the same certificate file.
Postfix configuration
smtpd_tls_cert_file = /etc/ssl/certs/yourdomain-fullchain.pem
smtpd_tls_key_file = /etc/ssl/private/yourdomain-key.pemDovecot configuration
ssl_cert = </etc/ssl/certs/yourdomain-fullchain.pem
ssl_key = </etc/ssl/private/yourdomain-key.pemAfter updating either configuration, restart the corresponding service (not just reload, for some mail server versions) for the new certificate to take effect. If you're using Let's Encrypt with automated renewal, add both services' restart commands to your renewal hook so they pick up the renewed certificate automatically each cycle.
What to do if Postfix and Dovecot report different certificate errors from the same underlying issue
Postfix and Dovecot are entirely separate services each reading their own independent configuration — an error in one but not the other usually means the certificate path was updated in one service's configuration file but not the other's, requiring both to be checked and corrected consistently.
How to test both services independently to isolate which one has the actual issue
Connecting directly to each service's specific port (25/587 for Postfix, 993/995 for Dovecot) using OpenSSL's s_client with the appropriate STARTTLS flag tests each service in isolation, immediately revealing which specific service has the certificate issue rather than needing to infer it from a general mail client error.
What smtpd_tls_security_level controls beyond just having a certificate installed
This Postfix setting controls how strictly TLS is enforced for incoming connections, ranging from optional (encryption offered but not required) to encrypt (required) — simply installing a certificate doesn't by itself enforce its use, this separate setting determines actual enforcement behavior.
How to configure Dovecot's separate settings for IMAP versus POP3 if you run both
Dovecot's ssl_cert and ssl_key directives apply globally across both IMAP and POP3 by default, though protocol-specific overrides are possible in Dovecot's configuration if you have a genuine need for different certificates per protocol — most setups use the same certificate for both without needing protocol-specific configuration.
Why testing mail delivery end-to-end after certificate changes catches issues a connection test alone might miss
A successful TLS connection test confirms the certificate itself is valid and correctly presented, but doesn't confirm actual mail delivery is working correctly end to end — sending and receiving an actual test message after any certificate change catches an issue in the broader mail delivery chain that a connection-only test wouldn't reveal.
What to do if mail delivery fails specifically for messages to certain domains after enabling TLS
Mail delivery failures to specific external domains after enabling TLS enforcement sometimes indicate the receiving mail server has its own certificate issues on their end — checking whether the failure is specific to certain destination domains (rather than affecting all mail) helps distinguish your own configuration issue from a receiving server's separate problem.
How to check whether your mail server's TLS configuration meets current best practices
Running your mail server's hostname and port through a dedicated mail-specific TLS testing tool, or using the same OpenSSL techniques covered throughout this site with STARTTLS flags, confirms your configuration against current recommended protocol versions and cipher suites, the same standard applied to web server TLS elsewhere on this site.
A closing note on mail server TLS as infrastructure that deserves the same care as web TLS
Given how much sensitive information flows through email, treating mail server TLS configuration with the same care, current best practices, and ongoing monitoring applied to web server TLS throughout this site is a reasonable, worthwhile standard rather than a lower priority.
A final thought on unified monitoring across every service
Building mail server certificate checks into the same monitoring and renewal automation covering your web certificates, rather than treating mail infrastructure as a separate, easily-overlooked category, ensures consistent coverage across every service depending on TLS.