Postfix TLS: Beyond Opportunistic Encryption
Most mail servers support TLS but don't enforce it. DANE, MTA-STS, and proper protocol configuration close the gap between "encrypted sometimes" and "encrypted always.
The Default Is Not Enough
A default Postfix installation supports TLS but does not enforce it. The smtp_tls_security_level parameter defaults to empty (no TLS), and smtpd_tls_security_level defaults to none. This means mail is sent and received in plaintext unless the remote server happens to offer STARTTLS.
The first hardening step is to enable opportunistic TLS for inbound connections and enforce it where possible for outbound:
smtpd_tls_security_level = may
smtp_tls_security_level = dane
DANE: Certificate Pinning via DNS
Setting outbound TLS to dane is significant. Rather than blindly trusting any certificate presented by a remote server (which is what may and encrypt do), DANE verification checks the server's TLS certificate against TLSA records published in DNSSEC-signed DNS.
This is defined in RFC 7672 — SMTP Security via Opportunistic DANE TLS. The practical effect: if a certificate authority is compromised and issues a fraudulent certificate for a remote mail server, a DANE-verifying Postfix instance will reject the connection because the certificate does not match the TLSA record pinned in DNS.
DANE requires DNSSEC support on the sending side:
smtp_dns_support_level = dnssec
DANE adoption remains limited — primarily concentrated among government institutions, financial entities, and European providers with strong DNSSEC infrastructure, particularly in Germany and the Netherlands (Review My Emails — Is DANE Widely Adopted?). But for servers that do publish TLSA records, DANE provides a level of transport security that no other mechanism can match.
Protocol Version Enforcement
SSLv3, TLS 1.0, and TLS 1.1 have known vulnerabilities and should be disabled entirely:
smtpd_tls_mandatory_protocols = >=TLSv1.2
smtp_tls_mandatory_protocols = >=TLSv1.2
smtpd_tls_mandatory_ciphers = high
This ensures that every connection — inbound and outbound — uses modern cryptography. Servers that only support deprecated protocols will fail to connect, which is the correct behavior.
MTA-STS: The DANE Alternative
Mail Transfer Agent Strict Transport Security (MTA-STS) is the complement to DANE for servers that do not support DNSSEC. It publishes a policy via HTTPS (at /.well-known/mta-sts.txt) that tells sending servers to require TLS when delivering mail to the domain.
The policy should be set to enforce mode — not testing, not none. As of January 2024, only 0.3% of surveyed domains had implemented MTA-STS, and 19.5% of those implementations contained errors (URIports — MTA-STS Survey 2024). Correct implementation is a meaningful differentiator.
The Combined Effect
With DANE for outbound, MTA-STS for inbound, and TLS 1.2+ enforced on both sides, the mail server achieves end-to-end transport encryption that is resistant to downgrade attacks, certificate forgery, and man-in-the-middle interception. This is the standard that every production mail server should meet.