Enable TLS on a Linux Mail Server Without Breaking Delivery

By Greg Nowak. Updated 1 August 2026.

Mail-server TLS is not a switch you turn on once. Public SMTP, authenticated submission and mailbox access have different security requirements. Apply one strict policy everywhere and legitimate mail may stop arriving; leave everything optional and users or applications may expose credentials.

There is also a business decision to make first. If a server only sends website forms, password resets or application alerts, an established SMTP provider will often be easier to operate than a public mail server. Running your own MX makes more sense when you need direct control of inbound delivery, mailboxes or a specialised routing policy—and can commit to monitoring it.

Choose the TLS policy by service

Service	Typical port	Recommended posture	Main risk
Public SMTP receiver	25	Offer STARTTLS; allow fallback	Mandatory TLS can reject legitimate senders
Authenticated submission	587	Require STARTTLS before authentication	Credentials exposed by an incorrect AUTH policy
Implicit TLS submission	465	Encrypt from connection start	Clients configured for the wrong mode
IMAP mailbox access	993	Require TLS	Certificate-name errors and exposed passwords

The safe policy depends on the service. Public server-to-server SMTP cannot be treated like a controlled user login.

Keep public SMTP opportunistic

On a publicly referenced MX, Postfix should advertise STARTTLS without requiring every sending server to use it. The may policy encrypts when the other system supports TLS but preserves delivery compatibility when it does not.

# /etc/postfix/main.cf
smtpd_tls_security_level = may
smtp_tls_security_level = may
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.example.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.example.com/privkey.pem

The first setting covers mail arriving at your server. The second enables opportunistic TLS for outbound delivery. If you send through a controlled relay, configure a stricter outbound policy for that destination rather than assuming the open internet can always meet it.

Require encryption on authenticated submission

Port 587 serves users and applications that authenticate. Make TLS mandatory there and do not advertise AUTH before encryption. Keep these overrides in master.cf so the stricter policy does not leak onto port 25.

# /etc/postfix/master.cf
submission inet n - y - - smtpd
  -o smtpd_tls_security_level=encrypt
  -o smtpd_tls_auth_only=yes
  -o smtpd_sasl_auth_enable=yes

The precise service line can differ between Linux packages, so compare it with the distribution’s supplied master.cf. Confirm that SASL is connected to the intended authentication service and that submission is not accidentally configured as an unauthenticated relay.

Match Dovecot configuration to its installed version

Postfix TLS does not protect IMAP or POP logins. For Dovecot 2.4, the relevant server certificate settings are ssl_server_cert_file and ssl_server_key_file:

# Dovecot 2.4
ssl = required
auth_allow_cleartext = no
ssl_server_cert_file = /etc/letsencrypt/live/mail.example.com/fullchain.pem
ssl_server_key_file = /etc/letsencrypt/live/mail.example.com/privkey.pem

Dovecot 2.3 uses different setting names and syntax. Check dovecot --version before copying a configuration block, especially on long-term-support distributions. Then inspect the effective configuration with doveconf -n. Keep the private key readable only by root or the narrowly scoped system group that needs it.

Treat renewal and reload as one operation

A renewed certificate does nothing until Postfix and Dovecot start using the new files. Obtain the certificate with an authenticator appropriate to the host, test renewal, and install an executable deploy hook that reloads both services after a successful renewal.

sudo certbot certonly --webroot -w /var/www/html -d mail.example.com
sudo certbot renew --dry-run --run-deploy-hooks

A deploy-hook script in /etc/letsencrypt/renewal-hooks/deploy/ can contain:

#!/bin/sh
systemctl reload postfix
systemctl reload dovecot

Certbot does not run deploy hooks during a normal dry run unless --run-deploy-hooks is supplied. Test the hook during a controlled change window, confirm both reload commands succeed, and monitor certificate expiry independently so a failed renewal cannot remain invisible.

TLS still needs correct DNS and authentication

TLS encrypts a connection; it does not establish a good sending reputation. The server hostname should resolve to its public IP, and the IP’s PTR record should resolve back to that hostname. Inventory every website, CRM, helpdesk and SaaS platform that sends as the business domain. Configure SPF to cover authorised senders, sign with DKIM, and publish DMARC so receivers can evaluate alignment with the visible From: domain.

Test the external path before closing the change

Validate the effective configuration first, then test each exposed service from outside the server’s network. Using -servername checks the hostname clients actually present:

postfix check
postconf -n
doveconf -n
openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com
openssl s_client -starttls smtp -connect mail.example.com:587 -servername mail.example.com
openssl s_client -connect mail.example.com:993 -servername mail.example.com
sudo journalctl -u postfix -u dovecot -f

Finally, send inbound and outbound test messages, inspect the queue and confirm that a real mail client can authenticate. Keep the previous configuration available for rollback until those tests pass.

If this server supports customer communication or operational alerts, the valuable work is not merely enabling TLS. It is separating policies correctly, automating renewal, aligning DNS and leaving the team with a testable operating procedure. Contact Greg if you want the configuration reviewed or the change planned and implemented safely.

Related on GrN.dk

Need help with this kind of work?

Discuss your mail-server setup with Greg Get in touch with Greg.

Sources

Last modified

2026-08-12