Skip to content 
I'll show you how to Mail server TLS in Postfix and select strong cipher suites so that SMTP connections are consistently protected. Based on proven parameters for TLS 1.2/1.3, DANE, MTA-STS and modern key pairs, I will guide you step by step through configuration, testing and tuning so that your mail security grips cleanly.
Key points
- Postfix Configure securely: Activate TLS, restrict protocols, set logging.
- Cipher prioritize: ECDHE + GCM/CHACHA20, enforce PFS, block legacy data.
- Certificates keep clean: RSA+ECDSA, full chain, strong curves.
- DANE/MTA-STS use: Anchoring guidelines and reducing downgrade risks.
- Tests and monitoring: Check OpenSSL, TLS scanner, MTA logs regularly.
SMTP via TLS: what is really secured
I secure SMTP with STARTTLS, so that e-mail transport does not take place in plain text. Opportunistic TLS via smtpd_tls_security_level = may ensures that incoming connections use encryption as soon as the remote station offers it. For outgoing deliveries, I use smtp_tls_security_level = dane DNSSEC-supported policy checks to make downgrade attacks more difficult. Without TLS, emails could be read and manipulated in transit, which is particularly dangerous for forms, orders or account data. With TLS active throughout, I significantly reduce the risk of eavesdropping and MITM, and I achieve better delivery rates because large providers rate secure connections positively.
Keys, certificates and protocols in Postfix
I have two certificates ready: one RSA-certificate and an ECDSA certificate so that old and new MTAs are optimally connected. I set the paths in Postfix clearly, for example smtpd_tls_cert_file for RSA and smtpd_tls_eccert_file for ECDSA, each with a matching key. For clean authentication, I pay attention to the complete chain, a CN/SAN that matches the host exactly, and a curve like secp384r1 for the ECDSA key. I strictly deactivate older protocols, i.e. SSLv2 and SSLv3, to prevent forced downgrades. If you are weighing up the type of certificate, a quick look at DV, OV or EV, so that you choose the right level of confidence.
Cipher selection: Priorities for TLS 1.2/1.3
I prioritize cipher suites with PFS, i.e. ECDHE before DHE, and use GCM or CHACHA20-POLY1305. Under TLS 1.3, the stack relieves you of many legacy tasks, while TLS 1.2 still requires a clear list. Insecure or weak suites like RC4, I delete 3DES, CAMELLIA, aNULL, eNULL. For Postfix I use smtpd_tls_ciphers = high and a restrictive tls_high_cipherlist, so that no outdated algorithms slip through. If you go deeper, the Cipher Suites Guide an easy-to-understand classification without ballast.
| TLS version | Preferred cipher suites | Status | Note |
|---|---|---|---|
| TLS 1.3 | TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_GCM_SHA256 | active | Selection firmly in the protocol, no more legacy issues. |
| TLS 1.2 | ECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-RSA-AES256-GCM-SHA384, ECDHE-ECDSA-CHACHA20-POLY1305 | active | Prioritize PFS, prefer GCM/CHACHA. |
| Obsolete | RC4, 3DES, CAMELLIA, AES128-SHA, aNULL/eNULL | locked | Deactivate completely for security reasons. |
Postfix: concrete parameters for main.cf
I set a clear configuration so that the MTA speaks securely both inbound and outbound. For ephemeral ECDH, I use smtpd_tls_eecdh_grade the curve quality and I deactivate compression to avoid CRIME-like attacks. A strong DH file with 4096 bits prevents weak DHE negotiations. I place hard restrictions on protocols and enforce high cipher quality, preferring to use TLS 1.3. At the start, a moderate log level helps me to check handshakes without flooding the journal.
# Activation and policy
smtpd_tls_security_level = may
smtp_tls_security_level = dane
# Certificates (example paths)
smtpd_tls_cert_file = /etc/ssl/certs/mail.example.de.cer
smtpd_tls_key_file = /etc/ssl/private/mail.example.de.key
smtpd_tls_eccert_file = /etc/ssl/certs/mail.example.de_ecc.cer
smtpd_tls_eckey_file = /etc/ssl/private/mail.example.de_ecc.key
# protocols and ciphers
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_ciphers = high
tls_high_cipherlist = !aNULL:!eNULL:!RC4:!3DES:!CAMELLIA:HIGH:@STRENGTH
tls_ssl_options = NO_COMPRESSION
smtpd_tls_eecdh_grade = ultra
# DH parameters
smtpd_tls_dh1024_param_file = /etc/postfix/dh_4096.pem
# DNSSEC/DANE (if available)
smtp_dns_support_level = dnssec
# Logging
smtpd_tls_loglevel = 1
I keep the certificate chain complete, pay attention to correct rights for private key files and check the logs after the reload. If TLS 1.2 is required for legacy partners, I stick strictly to GCM/CHACHA and block everything else. For TLS 1.3, I rely on the standards of the stack and avoid special paths that make maintenance more difficult. OCSP stapling only plays a role with SMTP if an upstream proxy provides it, so I only check this for corresponding setups. After every change, I validate with OpenSSL to detect side effects early on and to check the email encryption consistent.
Transport authenticity with DANE, MTA-STS, SPF, DKIM and DMARC
I combine TLS with DANE, by publishing signed TLSA records under DNSSEC. In addition, I set MTA-STS so that remote peers know that my host requires TLS and which MX they should adhere to. For identity binding, I sign outgoing mails with DKIM and secure domain delivery via SPF rules. Finally, DMARC defines how recipients should deal with deviations, which makes spoofing much more difficult. These components work together: TLS protects the transport, while authentication strengthens the sender and noticeably increases the delivery rate.
If performance is a bottleneck, I optimize session resumption, hardware features and the handshake itself. You can get started with practical tricks with TLS handshake faster, to reduce the latency when establishing a connection. Important: I keep cipher selection and resumption in balance, because weak compromises do not pay off in terms of security. Especially with high mail volumes, fast TLS negotiation brings significant savings. This way Throughput and security in balance.
Testing, monitoring and audits
I check handshakes locally with openssl and check the protocol version, cipher and certificate chain. The command openssl s_client -connect mail.example.de:25 -starttls smtp shows me live what the remote server is negotiating. After configuration changes, I use postfix check and look specifically at smtpd_tls_loglevel, to isolate error patterns. External TLS scanners help to classify public visibility, especially after certificate changes. A regular audit cycle protects against creeping deterioration, for example if a library change affects cipher priorities.
Frequent misconfigurations and quick fixes
I often see outdated ciphers like AES128-SHA, which are still active and prevent PFS. A strict cipher string and the clear blocking of LOW/MD5/RC4/3DES helps here. Second pattern: missing intermediate certificates, which prevents remote stations from verifying the chain; I add the bundle file and test again. On appliances such as a Synology, I set the TLS profile to modern and remove legacy options so that the SMTP server speaks modern. With Microsoft Exchange, I specifically check TLS 1.2/1.3 policies, certificate assignment per connector and any cipher overrides in the host configuration so that the Handshake-selection is right.
Preview: TLS 1.3, 0-RTT and Post-Quantum
I prefer TLS 1.3 because the handshake is shorter and old options are eliminated, which reduces attack surfaces. The selection of the cipher is clearly limited there, and modern stacks provide good defaults. I do not use 0-RTT in the SMTP context, as replay attacks bring unnecessary risks here. For the future, I am keeping an eye on hybrid post-quantum procedures, which could find their way into the mail environment as soon as standardization and support mature. It remains important that I set up policies and monitoring in such a way that new procedures can be integrated later without disruption.
Performance and delivery rate at a glance
I measure the Latency of the TLS handshake and optimize caches to enable reuse. Session resumption (tickets/IDs) reduces the computing load and speeds up recurring connections between MTAs. For certificate revocation, I rely on stackable information at the upstream proxy, if available, to save additional accesses. Large recipients rate secure transports positively, which increases the delivery rate, while insecure paths increase the risk of spam and rejection. With a clear TLS policy, solid DNS entries and a clean signature chain, I create a reliable basis for Deliverability.
My setup schedule
I start by obtaining the certificate from a trustworthy CA, generate ECDSA and RSA and store both cleanly on the host. Then I customize the main.cf with the TLS parameters, set strong ciphers and deactivate old protocols. A fresh DH file with 4096 bits is added, followed by a reload and the first OpenSSL checks. I then set up DANE, add MTA-STS and verify SPF/DKIM/DMARC for validity. Finally, I run tests against external targets, check logs during operation and schedule regular audits so that the Configuration remains secure in the long term.
Missing modules: Submission, SMTPS and SNI
I not only secure port 25, but also submission (587) and optionally SMTPS (465). For submission, I enforce encryption and authentication so that user passwords are never sent in plain text. In master.cf I activate the services and set targeted overrides:
# submission (port 587) with STARTTLS and auth obligation
submission inet n - y - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_tls_auth_only=yes
-o smtpd_sasl_auth_enable=yes
-o milter_macro_daemon_name=ORIGINATING
# SMTPS (port 465) as wrapper mode, if required
smtps inet n - y - - smtpd
-o syslog_name=postfix/smtps
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o milter_macro_daemon_name=ORIGINATING
If I serve several mail domains on one host with my own certificates, I use SNI. I use an SNI map to assign the appropriate certificate path for each target host and ensure that MUA clients also see the correct certificate. This is how I ensure client separation with consistent TLS identity.
Per-domain policies: fine-grained control
In addition to the global policy, I also manage smtp_tls_policy_maps Exceptions and tightening per recipient domain. This allows me to gradually migrate legacy partners or enforce particularly strict requirements for sensitive targets.
# main.cf
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
# /etc/postfix/tls_policy (example entries)
example.org dane-only
legacy.example.net may
secure.example.com secure
dane-only enforces DANE protection without CA dependency, secure requires a valid CA chain and refuses plain text delivery, may remains opportunistic. After changes, I build the map with postmap and reload Postfix.
DANE and MTA-STS: concrete implementation
For DANE I publish TLSA records under DNSSEC. I prefer to use DANE-EE (3 1 1) because it allows pinning to the public key and facilitates certificate changes with the same key. An exemplary TLSA record under _25._tcp.mail.example.de looks like this:
_25._tcp.mail.example.de. IN TLSA 3 1 1
I generate the hash from the ECDSA or RSA certificate and make sure to rotate it before it expires. It is important that the DNS zone is signed and that the chain of delegations is validated without gaps.
For MTA-STS I host the policy file via HTTPS and add the TXT DNS entry. This way, I specify that remote peers speak TLS and are only accepted with a defined MX. A minimalist policy file:
version: STSv1
mode: enforce
mx: mail.example.de
max_age: 604800
A TXT entry is added in the DNS under _mta-sts.example.de with the current version. Optionally I set up TLS-RPT via TXT under _smtp._tls.example.de to receive reports on policy violations. This telemetry helps me to detect failures, downgrades and faulty certificates at an early stage.
Tighten protocols, specify cipher
I tighten protocol limits and enforce server preference. TLS 1.0/1.1 are dispensable today; I only allow TLS 1.2 and 1.3 in depth and on an outgoing basis. For TLS 1.2, I define an explicit positive list to exclude mixed stocks of old ciphers:
# Additional hardening (main.cf)
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
# Explicit TLS 1.2 cipher list (PFS + AEAD only)
tls_high_cipherlist = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:!aNULL:!eNULL:!MD5:!RC4:!3DES:!CAMELLIA
# Use server preference
tls_preempt_cipherlist = yes
I make sure that ECDHE is preferred and DHE is only a fallback. I keep my DH file up to date; under TLS 1.3 it doesn't play a role, but it is still useful for rare DHE actions.
Session resumption and caches
To speed things up, I activate session caches for the client and server to make reconnections cheaper. CPU load and latency are noticeably reduced, especially with high mail throughput:
# Session cache (main.cf)
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache
smtp_tls_connection_reuse = yes
I monitor the hit rate in the logs and make sure that none are too short. ticket_lifetimes in the TLS library to slow down resumption. Important: Resumption must not weaken the policy; I stick to the same cipher requirements.
Certified company: Rotation and chain maintenance
I automate the renewal and reload of the MTA so that no expired certificates end up in operation. After each renewal, I check whether the leaf and intermediate certificates are completely in the bundle. For ECDSA/RSA dual operation, I make sure that both pairs rotate before a mass change causes problems for clients. I test the SNI path and submission separately because MUAs can show different error patterns than MTAs.
Deepen logging and diagnostics
I temporarily increase the log depth when a problem occurs and use on-board tools for cross-checks:
# targeted logging (main.cf)
smtp_tls_loglevel = 1
smtp_tls_note_starttls_offer = yes
With posttls-finger target.example.com I check which policy a remote MTA expects and which ciphers/protocols are negotiated. I use postconf -n | grep tls, to see only explicitly set TLS parameters; I can find deviations from defaults more quickly this way. In the logs, I search for terms such as no shared cipher, certificate verify failed or protocol version, that directly indicate cipher mismatch, chain problems or protocol limits that are too strict/too lax.
Managing compatibility without sacrificing security
I plan transitions consciously: I stay in-depth with may, to avoid losing mails from legacy servers across the board, but log plain text deliveries. Outgoing I remain strict (DANE/MTA-STS/secure) and use smtp_tls_policy_maps for individual cases. If individual partners can only manage TLS 1.2 with AES-GCM, that is acceptable; I manage everything below that via agreed exceptions with a limited runtime, document them and include them in the migration planning. This keeps the overall level high without blocking business operations.
TLS defaults of the system at a glance
Note that Postfix uses the system's TLS library. Updates to OpenSSL/LibreSSL can change cipher priorities and TLS 1.3 behavior. After system updates, I therefore randomly check handshakes and compare output from postconf -n with my target values. A set compatibility_level in Postfix helps to maintain stable defaults, but I do not blindly rely on it and document explicit deviations in main.cf/master.cf.
Quick summary for administrators
I would like to emphasize that strong ciphers with PFS, clean certificates and clear policies are essential for SMTP crucial. TLS 1.3 relieves you of legacy issues, while TLS 1.2 requires a disciplined cipher list. DANE and MTA-STS harden the transport path, SPF/DKIM/DMARC secure identity and reporting. Regular tests and log analyses show early on whether a change has undesirable side effects. With this guide, you can set up your mail server to be secure, high-performance and future-proof - without unnecessary Risks.
