Which ports need a certificate
A mail server speaks TLS on several ports, and each one serves a certificate. For mail clients these are SMTP submission on 587 with STARTTLS, SMTPS on 465 with implicit TLS, IMAP on 993 (implicit TLS) and 143 (STARTTLS), and POP3 on 995. For inbound mail from other servers, port 25 with STARTTLS is added to the list.
With Postfix and Dovecot these are two separate services with separate configurations that may point to the same file, but do not have to. It happens regularly that IMAP serves a fresh certificate while SMTP serves an expired one, because only one service was reloaded.
What happens when it expires
Outlook, Apple Mail and Thunderbird show a dialog on the next fetch that unsettles most users and fills the support channel. Mobile clients are less consistent: some ask, some simply abort with "cannot connect" without mentioning the certificate. The user only sees that no new mail arrives.
For inbound mail from other servers it depends on the sender. Most mail servers use opportunistic TLS: if certificate validation fails, they deliver anyway, if necessary in plaintext. But if the domain has published MTA-STS in enforce mode or DANE with TLSA records, compliant senders such as Google and Microsoft refuse delivery until the certificate is valid again. The domains with the best mail security are therefore the most vulnerable here.
Why website monitoring does not notice
An HTTPS check validates the certificate on www.example.com, port 443. The mail server is called mail.example.com, runs on a different machine, has its own certificate and often its own renewal logic. With managed mail such as Microsoft 365 or Google Workspace the provider takes care of it. With self-hosted Postfix and Dovecot, with Plesk servers and with mail servers at smaller hosting companies, it is the agency or the client, and that is where it gets forgotten.
A typical scenario: the website moved long ago to a host with automatic certificates, while the mail server still runs on the old root server with a certificate someone installed by hand a year ago.
Testing with openssl
For ports with implicit TLS (465, 993, 995) a plain openssl s_client is enough. For STARTTLS ports (25, 587, 143) openssl first has to speak the plaintext protocol and then upgrade to TLS, which is what the -starttls option does. Pass -servername so the server picks the right certificate via SNI.
# SMTP submission with STARTTLS
openssl s_client -connect mail.example.com:587 -starttls smtp -servername mail.example.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subject
# IMAP with implicit TLS
openssl s_client -connect mail.example.com:993 -servername mail.example.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subject
# IMAP with STARTTLS
openssl s_client -connect mail.example.com:143 -starttls imap -servername mail.example.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subjectCheck every port individually, because the discrepancy between services is the most common fault. The SSL checker does this for any host and port, including STARTTLS.
The hostname must match what clients use
The certificate must be issued for the name clients enter, so mail.example.com or imap.example.com. The internal hostname of the server (srv042.hosting.example) does not help if the client's Outlook says mail.example.com. For clients who use the hosting company's MX name, the certificate must cover that name too.
For domains with several mail hostnames, a certificate with multiple SANs is the simplest solution. For inbound mail with MTA-STS the certificate must additionally match the MX hostname, not the domain name, or the policy fails.
Let's Encrypt and the forgotten reload
Let's Encrypt works on mail servers just like on web servers. The HTTP-01 challenge does need a web server on port 80 of the mail hostname, or you use DNS-01. Plesk and many panels offer this with one click; on a hand-built Postfix you set up certbot with a deploy hook.
The classic: the certificate was renewed on disk, but Postfix and Dovecot keep the old one in memory until they are reloaded. certbot renews, the cron runs, everything looks green, and the services still serve an expired certificate. A deploy hook that reloads both services fixes this permanently.
# /etc/letsencrypt/renewal-hooks/deploy/mail.sh
#!/bin/sh
systemctl reload postfix
systemctl reload dovecotIn Postfix, smtpd_tls_cert_file and smtpd_tls_key_file point to fullchain.pem and privkey.pem; in Dovecot it is ssl_cert and ssl_key with a leading less-than sign. Verify both from outside after the first reload.
Monitoring the ports
A certificate check on 443 alone leaves the mail server in the dark. For every client domain with its own mail server, monitor at least 587 and 993, plus 25 and 465 if they are in use. Check not only the expiry date but also whether the hostname matches and the chain is complete.
Staggered thresholds at 30, 14 and 7 days give enough lead time to fix the forgotten reload or the broken challenge before a client sees the first certificate dialog.
Frequently asked questions
- Can I use the same certificate for web and mail?
- Yes, if both services run on the same machine and the certificate lists all hostnames in the SAN. With separate servers, one certificate per server is simpler, because otherwise files have to be copied around.
- Is a self-signed certificate on the mail server enough?
- For inbound mail from other servers it usually works, because few of them validate. But your clients' mail apps show a warning on every connection, and with MTA-STS or DANE it is unusable. A free Let's Encrypt certificate is the better choice.
- Why does IMAP show the new certificate but SMTP the old one?
- Because only Dovecot was reloaded, not Postfix, or because the two services point to different certificate files. Check the paths in both configurations and reload both services.