Skip to content
Postfix Insights

Check outbound TLS coverage from Postfix logs

When smtp_tls_loglevel is set to 1 or higher, Postfix logs a separate TLS status line for each outbound SMTP connection, independent of the delivery outcome. This line tells you whether the connection was encrypted, which TLS version was negotiated, and the cipher suite used. By correlating these TLS lines with delivery records, you can calculate outbound TLS coverage: the percentage of messages sent with encryption versus in the clear. This metric matters for deliverability, compliance, and security posture.

TLS 1.3 78% TLS 1.2 20% cleartext 2%
Outbound deliveries by negotiated TLS version. The cleartext share is the number to watch. Representative sample data.

How Postfix logs outbound TLS

Section titled “How Postfix logs outbound TLS”

When smtp_tls_loglevel >= 1, the SMTP client (postfix/smtp) logs a TLS line for each outbound connection. The line appears as a separate event in the mail log, not embedded in the delivery status line. For example:

postfix/smtp[1234]: Verified TLS connection established to mx.example.com[198.51.100.7]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)

and

postfix/smtp[5678]: Untrusted TLS connection established to mail.other.org[203.0.113.42]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)

These TLS lines describe the encryption negotiated with the remote MX server. They are logged once per SMTP connection and remain distinct from the separate delivery line that appears later:

postfix/smtp[1234]: 2ABC123: to=user@example.com, relay=mx.example.com[198.51.100.7], delay=0.4, status=sent

If a delivery goes in cleartext (no STARTTLS negotiation), there is no corresponding TLS line at all. Only the delivery status line appears.

The TLS line includes a verification status: “Verified”, “Trusted”, “Untrusted”, or “Anonymous”. These indicate whether Postfix was able to validate the remote server’s certificate against a trusted CA. “Untrusted” and “Anonymous” are still encrypted (the transport is secure); they simply mean the certificate chain could not be verified. Plaintext deliveries produce no TLS line.

TLS security levels and coverage

Section titled “TLS security levels and coverage”

Outbound TLS behavior is controlled by the smtp_tls_security_level parameter in /etc/postfix/main.cf. The common values are:

smtp_tls_security_level = none: TLS is disabled. No encryption is attempted. No TLS lines appear in the log.

smtp_tls_security_level = may (opportunistic TLS): The SMTP client attempts STARTTLS with every outbound connection. If the remote server supports STARTTLS, the connection is encrypted. If the remote server does not support STARTTLS, the message is sent in clear. This is the most common setting for general mail servers. With this level, coverage is not 100 percent; some destinations will be cleartext and some will be encrypted, depending on the remote server’s TLS support.

smtp_tls_security_level = encrypt: TLS is mandatory. The SMTP client will not send a message unless a TLS connection is established with the remote server. Messages to servers that do not support STARTTLS will defer or bounce. Coverage is 100 percent for any message that gets delivered.

smtp_tls_security_level = dane: Mandatory TLS if a TLSA DNS record is present; otherwise falls back to opportunistic TLS. Provides stronger guarantees when DNSSEC validation is available.

With opportunistic TLS (may), “coverage” is a real, measurable statistic: of the messages sent, what fraction used encryption, and at which TLS version (1.3 versus 1.2 versus none)? This is exactly the kind of correlation that is tedious to perform by hand: you must link each TLS log line to the corresponding delivery line by correlating the SMTP process ID and connection details. Postfix Insights automates this correlation.

Why TLS coverage matters

Section titled “Why TLS coverage matters”

Deliverability and security standards increasingly expect SMTP connections to use TLS. The industry consensus, reflected in RFC 8314 (“Cleartext Considered Obsolete”), is that cleartext SMTP delivery should be phased out in favor of TLS-secured transport. RFC 3207 specifies STARTTLS, the mechanism by which an SMTP client upgrades a plaintext connection to TLS encryption. RFC 5246 documents TLS 1.2, and RFC 8446 documents TLS 1.3, the current encryption standard.

Tracking the plaintext delivery rate serves multiple purposes:

  • Compliance: Many regulatory frameworks (HIPAA, PCI-DSS, financial industry standards) expect mail to be sent over encrypted channels. Measuring the plaintext fraction tells you how many messages are at risk.
  • Deliverability: Some domains now penalize or refuse cleartext SMTP. Knowing your plaintext delivery rate to each recipient domain helps you anticipate delivery problems and coordinate with remote administrators.
  • Incident response: If a domain’s TLS coverage suddenly drops (for example, if their MX server loses TLS support or has a certificate issue), a TLS coverage report will flag it immediately.
  • Security posture: Plaintext SMTP is vulnerable to eavesdropping, message interception, and MiTM attacks. Reducing plaintext delivery improves your security stance.

How Postfix Insights helps

Section titled “How Postfix Insights helps”

Correlating TLS log lines to delivery records is tedious and error-prone by hand. You must:

  1. Extract all TLS lines for a date range.
  2. Extract all delivery lines.
  3. Group them by SMTP process ID and connection.
  4. Calculate the ratio of TLS-encrypted deliveries to all deliveries.
  5. Break the result down by TLS version, cipher, or remote domain.

Postfix Insights automates this correlation. It surfaces outbound TLS coverage as a dashboard metric, showing you:

  • The fraction of outbound deliveries that used TLS versus plaintext.
  • The distribution across TLS versions (1.3, 1.2, 1.0, none).
  • Which remote domains are sending plaintext (if any).
  • Whether a domain’s TLS support has degraded or failed.

The /stats dashboard displays this data as a simple percentage and trend chart, so you can see at a glance whether your opportunistic TLS is working as expected.

To enable outbound TLS logging:

  1. Ensure smtp_tls_loglevel is set to 1 or higher in /etc/postfix/main.cf.
  2. Reload Postfix: postfix reload.
  3. Send a test message to verify a TLS log line appears.
  4. Point Postfix Insights to your mail log.

See the Quick start guide to install Postfix Insights, and refer to the Configuration page to point it to your log files.

For a deeper understanding of why correlating Postfix logs by hand is difficult, see Why Postfix log correlation is hard.

References

Section titled “References”