Email server encryption has a slightly more complicated history than web HTTPS, with several ports and two different conventions for how encryption in practice starts — worth understanding clearly before configuring a mail server's TLS.
Implicit TLS versus STARTTLS
Ports like 465 and 993 use "implicit" TLS — the encrypted handshake happens immediately, before any protocol-specific communication, the same pattern as HTTPS on port 443. Ports like 25, 587, and 143 instead start as a plain connection, with a specific command (STARTTLS) used to upgrade that same connection to encrypted mid-stream. Both approaches result in an encrypted connection; STARTTLS's brief plain-text moment at the very start of the connection (before the upgrade command) is generally considered acceptable since no sensitive data is exchanged during that initial handshake phase.
Postfix (SMTP) configuration
smtpd_tls_cert_file = /etc/ssl/certs/mail-fullchain.pem
smtpd_tls_key_file = /etc/ssl/private/mail-key.pem
smtpd_tls_security_level = may
smtp_tls_security_level = maysecurity_level = may offers STARTTLS without requiring it, a reasonable starting point for compatibility with older connecting clients or servers; encrypt instead requires TLS for the connection to proceed at all, a stricter but more secure setting once you're confident all legitimate senders/receivers support it.
Dovecot (IMAP/POP3) configuration
ssl = required
ssl_cert = </etc/ssl/certs/mail-fullchain.pem
ssl_key = </etc/ssl/private/mail-key.pemWhich ports to actually expose
Modern mail server configuration generally recommends: port 587 (submission, with mandatory STARTTLS) for outgoing mail from end-user clients, port 993 (IMAPS) for retrieving mail, and disabling or restricting the older port 25 to server-to-server delivery only rather than end-user client submission, since port 25 traffic is treated differently by many networks (some ISPs block outbound port 25 entirely to reduce spam relay abuse).
Certificate considerations specific to mail
The certificate used for a mail server needs its Common Name/SAN to match the exact hostname mail clients are configured to connect to (often mail.yourdomain.com) — which may be a different hostname than your website's own certificate covers, meaning a separate certificate (or a SAN entry covering both) is often needed rather than assuming your website's certificate automatically applies to mail services too.
Server-to-server delivery: opportunistic TLS
Beyond client-to-server connections, mail servers also talk to each other when delivering mail between different providers — this server-to-server SMTP traffic on port 25 generally uses "opportunistic" TLS, attempting STARTTLS if the receiving server offers it but falling back to plain text delivery if it doesn't, since mail delivery has historically prioritized deliverability over strict encryption enforcement. This is a substantially different security posture than client-facing ports, where requiring TLS outright is both expected and practical.
What DANE and MTA-STS add as additional layers of mail server trust verification
DANE uses DNSSEC-secured DNS records to specify which certificate a mail server should present, while MTA-STS lets a domain publish a policy requiring TLS for incoming mail — both provide additional verification layers beyond standard certificate validation, though adoption remains less universal than for standard web HTTPS.
How to test mail server TLS configuration without needing a full email client setup
Connecting via `openssl s_client -connect mail.yourdomain.com:993` or the equivalent for other mail ports lets you verify certificate and TLS configuration, the same technique used throughout this site for web servers, without needing to configure a full email client just to test connectivity.
Why mail server certificate renewal needs coordination across multiple services simultaneously
Because a typical mail server runs both Postfix and Dovecot referencing the same certificate files, a renewal needs both services restarted or reloaded to pick up the new certificate — a renewal hook restarting only one service leaves the other still serving the old, soon-to-expire certificate.
What mail client autoconfiguration means for certificate hostname requirements
Modern mail clients use autoconfiguration protocols to automatically discover server settings from just an email address, commonly expecting a certificate matching a predictable hostname pattern like mail.yourdomain.com — deviating from these expected hostname conventions can cause autoconfiguration to fail even if manual configuration would work fine.
How to handle a transition period when migrating mail service to a new hostname
Migrating mail service to a new hostname benefits from a period where both the old and new hostnames remain valid and correctly certified simultaneously, giving existing mail clients configured with the old hostname time to be manually or automatically updated before the old hostname is eventually retired.
Why monitoring mail-specific certificate expiry separately from your website's certificate matters
A mail server certificate, often covering a different hostname than your main website, needs its own independent expiry monitoring — assuming your website certificate monitoring covers mail service too is a common oversight that leads to mail-specific outages going unnoticed until users actually report connection errors.
What the difference between implicit and explicit TLS means for mail port configuration
Implicit TLS (used on ports like 465 for SMTP or 993 for IMAP) encrypts the connection from the very first byte; explicit TLS, sometimes called STARTTLS (used on port 587 or 143), begins in plaintext and upgrades to encryption partway through the connection — both are secure when correctly configured, but mixing up which port expects which mode is a common, easily-fixed setup mistake.
How to verify STARTTLS is really being negotiated rather than silently falling back to plaintext
Connecting with openssl s_client -starttls smtp -connect mail.yourdomain.com:587 and confirming the TLS handshake completes successfully verifies STARTTLS is in reality being negotiated — a mail client silently failing to upgrade to TLS and continuing in plaintext is a real, historically documented downgrade risk worth explicitly testing for rather than assuming.
Why webmail interfaces need their own separate certificate verification from the mail protocols themselves
A webmail interface (Roundcube, an embedded hosting-panel webmail client) is typically served as its own separate HTTPS website, with its own certificate independent of your SMTP and IMAP server certificates — confirming webmail's own HTTPS configuration is correct is a distinct check from verifying the underlying mail protocol certificates.
What a quick closing checklist for mail server TLS looks like
Before considering mail server TLS complete, confirm: both Postfix and Dovecot (or your equivalent services) reference the current certificate, STARTTLS negotiation is verified via direct OpenSSL testing, and renewal automation restarts or reloads every relevant mail service, not just one.
Why mail server TLS often gets less attention than web TLS despite handling equally sensitive data
Email traffic frequently contains passwords, financial information, and other sensitive content forwarded through it, yet mail server TLS configuration often receives less scrutiny than web server TLS simply because there's no equivalent visible browser padlock reminding anyone to check it — worth treating mail server TLS with the same seriousness as any other sensitive-data-handling infrastructure.
What a complete Postfix and Dovecot configuration snippet looks like put together
A complete setup references the same certificate and key files consistently across Postfix's smtpd_tls_cert_file/smtpd_tls_key_file and Dovecot's ssl_cert/ssl_key directives, with both services restarted together after any certificate change — consistency across both configuration files is what prevents one service quietly serving a stale certificate.
How to handle a mail server also serving as an outbound relay for other systems
If your mail server also relays outbound mail on behalf of other internal systems or applications, confirm those systems' own SMTP client configuration is updated to expect and verify your mail server's current certificate, since a relay configuration pointed at an old, expired, or mismatched certificate expectation will fail silently in ways that can be hard to trace back to the actual cause.
Loading comments…