Enable TLS on a Linux Mail Server Without Breaking Delivery

By Greg Nowak. Last updated 2026-06-30.

Enabling TLS on a Linux mail server is not a cosmetic security task. It protects credentials in transit, gives remote systems a basic signal that the server is maintained, and prevents a whole class of avoidable support calls. The trap is thinking that one TLS setting solves the whole mail problem. A server can encrypt traffic and still fail because the wrong port is strict, the certificate name does not match, renewals are not reloaded, or DNS tells receivers a different story.

For business owners, operations leads, and agency teams, the first decision is whether you should run mail on this server at all. If a site only sends password resets, form notifications, or operational alerts, a reputable SMTP relay is often simpler and safer. If you operate your own MX, mailbox access, or authenticated submission for users and applications, treat TLS as part of a larger operating model: service separation, certificate renewal, sender authentication, logging, and tests.

Start with the mail role

Mail role	Common ports	TLS posture	What to watch
Outbound application host	Local sendmail or relay submission	Use a relay with authenticated TLS where possible	Avoid accidentally becoming a public mail server
Public MX	25	Advertise STARTTLS opportunistically	Do not require TLS from the whole internet
Authenticated submission	587, sometimes 465	Require TLS before authentication	Protect usernames, passwords, and app credentials
Mailbox access	993 for IMAP over TLS	Require encrypted sessions	Keep certificate names aligned with client settings

Choose the role first. The right TLS setting for a public MX is not the same as the right setting for user submission.

Configure Postfix by port, not by habit

For public SMTP on port 25, keep TLS opportunistic. Postfix documents smtpd_tls_security_level = may as the setting that advertises STARTTLS without requiring every remote sender to use it. That matters because some legitimate mail still arrives from systems with limited or broken TLS support. Requiring encryption on a publicly referenced MX can turn a security improvement into a delivery outage.

# /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

Authenticated submission is different. This is where clients and applications log in, so TLS should be mandatory before credentials are accepted. Keep that stricter policy on the submission service instead of applying it globally to the public listener.

# /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

On Postfix 3.4 and newer, smtpd_tls_chain_files is the newer combined key-and-chain interface. Use it deliberately if your deployment process creates a root-only PEM file with the private key followed by the certificate chain. Do not mix it casually with the older algorithm-specific certificate settings; if you need broad distribution compatibility, the separate smtpd_tls_cert_file and smtpd_tls_key_file pattern is still common and understandable.

Protect Dovecot logins too

If users read mail through IMAP or POP, Postfix is only half the job. Current Dovecot configuration uses ssl_server_cert_file and ssl_server_key_file. If you inherit older snippets using ssl_cert or ssl_key, review them before carrying them into a newer Dovecot setup.

# Dovecot SSL baseline
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

The practical goal is simple: clients connect to the same hostname that appears on the certificate, cleartext passwords are not accepted on exposed connections, and the key file remains restricted to root or the operating system group intended for private key access.

Make certificate renewal operational

For most Linux mail servers, Certbot remains a straightforward way to obtain certificates without letting the tool rewrite Postfix or Dovecot configuration. Use certbot certonly with the authenticator that fits the host, then test renewal before you depend on it.

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

Renewal is not finished until services reload the renewed files. Put a small executable hook in /etc/letsencrypt/renewal-hooks/deploy/, or use a tested --deploy-hook, to reload Postfix and Dovecot after successful renewal. This is the difference between a certificate that renews and a mail stack that actually uses the renewed certificate.

Align DNS and sender authentication

TLS encrypts the connection; it does not prove that your domain is a good sender. For serious business mail, align these items before blaming the mail software: the mail hostname should be a real FQDN such as mail.example.com, its A or AAAA record should point to the sending IP, the PTR record for that IP should point back to the same hostname, and SPF or DKIM should authenticate every system that sends for the domain. Add DMARC so receivers can evaluate alignment with the visible From: domain.

This is especially important for agencies managing several client sites. Hidden senders are where SPF records become brittle and DKIM coverage becomes uneven. Keep a short inventory of every website, CRM, helpdesk, invoicing tool, and server that sends mail for the brand domain.

Test what users and remote servers see

Do not stop after a successful reload. Test the active configuration, the certificate chain, and each exposed service from the outside path users and remote servers will take.

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

If this mail server supports business-critical workflows, the value is in the operational details: the right TLS posture per port, certificates that renew and reload, DNS that matches the server identity, and sender authentication that reflects reality. Need that reviewed or implemented cleanly? Contact Greg for a practical mail-server check or implementation plan.

Related on GrN.dk

Need help with this kind of work?

Get mail TLS and DNS reviewed Get in touch with Greg.

Sources

Last modified

2026-06-30