What TLS Actually Does for Email

TLS — Transport Layer Security — encrypts the network connection between two mail servers during an SMTP transaction. When a sending server connects to your mail server and both support TLS, the conversation is wrapped in an encrypted tunnel. Anyone sniffing packets on the network between those two servers sees only encrypted noise, not the message content, headers, or envelope data.

This protection is genuinely valuable. Without TLS, a network observer on the same ISP backbone, a compromised router, or a man-in-the-middle at a peering point could read every email in transit. With TLS, that attack becomes impractical. The content of the email — including the body, attachments, and To/From headers — is protected from passive eavesdropping while it is moving between servers.

TLS also provides some assurance of server identity through certificate validation. When Spam Killer connects to your upstream mail server over TLS and the certificate checks out, you have reasonable confidence you are talking to the right server rather than an impostor on the same network path.

What TLS Does Not Do

This is the part that trips up many administrators. TLS secures the wire — and nothing else. It provides no protection against any of the following threats:

TLS does not verify the sender's identity. A spammer running their own SMTP server can establish a valid TLS connection to your mail server just as easily as a legitimate sender. TLS certificates are issued for domains and IP addresses, not for individual senders or companies. The presence of TLS says nothing about whether the From address in the email is real or forged.

TLS does not filter content. An email that is perfectly encrypted in transit can contain a phishing link, a malware attachment, or a business email compromise attempt. TLS does not inspect what it carries — it simply encrypts it. A spam email delivered over TLS is still spam when it arrives in the inbox.

TLS does not protect you from a compromised sending server. If a legitimate company's mail server is compromised and begins sending malicious emails, those emails will still arrive over TLS with a valid certificate. TLS cannot distinguish between a legitimate server behaving normally and a compromised server being used as a spam relay.

TLS protection ends at the server. Once the email is delivered to your mail server, TLS has done its job. The message is now stored on disk in plaintext (or under whatever at-rest encryption you have configured). TLS says nothing about how the message is stored, who can read it on the receiving server, or what happens to it after delivery.

Transport Security vs. Content Security

The confusion around TLS and spam usually comes from conflating two separate security concerns. Transport security answers the question: is this message safe to travel across the network? Content security answers the question: is this message safe to deliver to a user's inbox?

These are independent problems that require independent solutions. You can have excellent transport security (all connections use TLS, certificates are valid, certificates are verified) while having terrible content security (spam rate 40%, phishing emails delivered daily). And you can have good content filtering on a server that does not use TLS, which protects users from spam while leaving the wire unencrypted.

The right approach is to address both layers. TLS for transit protection, and SPF/DKIM/content filtering for message-level protection. Neither substitutes for the other.

The Role of SPF and DKIM

Where TLS authenticates the server connection, SPF and DKIM authenticate the message itself.

SPF (Sender Policy Framework) lets domain owners publish a list of IP addresses that are authorized to send email on behalf of their domain. When a message arrives claiming to be from company.com, the receiving server checks the SPF record in DNS: was this message sent from an IP that company.com has authorized? SPF failures are a strong signal that the sender is lying about the From domain.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing messages. The private signing key lives on the sending server; the public verification key is published in DNS. When a message arrives with a DKIM signature, the receiving server fetches the public key and verifies the signature. This proves that the message body and headers have not been tampered with since they left the signing server, and that the signing server is authorized by the domain's DNS owner.

Neither SPF nor DKIM says anything about message content — a spammer can set up valid SPF and DKIM for their own domain and send garbage from it. But they prevent domain spoofing, which is the vector for most phishing and business email compromise attacks.

STARTTLS vs. SMTPS: What Is the Difference?

There are two common ways to establish a TLS-encrypted SMTP connection, and they work differently.

STARTTLS starts as a plaintext SMTP connection on port 25 (or 587 for submission), then upgrades to TLS mid-session using the STARTTLS command. The initial greeting and capability exchange happen in the clear, then both sides agree to upgrade. The risk is that a downgrade attack is theoretically possible if neither side requires the upgrade — a man-in-the-middle could strip the STARTTLS command and leave the connection unencrypted. MTA-STS (SMTP MTA Strict Transport Security) was developed specifically to prevent this by letting domain owners publish a policy requiring TLS for all inbound connections.

SMTPS (also called Implicit TLS) connects on port 465 and establishes TLS immediately, before any SMTP commands are exchanged. There is no plaintext phase and no opportunity for a downgrade attack. For mail submission from email clients, port 465 with implicit TLS is increasingly preferred.

For inbound MX connections (server-to-server), STARTTLS on port 25 with required TLS is the standard approach.

Practical: Should You Require TLS?

For connections between Spam Killer and your upstream mail server, yes — require TLS. This prevents anyone on your internal network or hosting provider from reading mail in transit between the proxy and your server. In your Spam Killer configuration:

upstream:
  host: "mail.yourserver.com"
  port: 25
  use_tls: true
  verify_cert: true

Setting verify_cert: true ensures the upstream server's certificate is valid and matches the hostname — without this, TLS provides encryption but not authentication of the server identity.

For inbound connections from the internet, Spam Killer accepts both TLS and non-TLS connections by default, because some legitimate sending servers on the internet do not support TLS. If you want to require TLS from all inbound senders, you can set require_tls: true in the listener configuration — but be prepared to accept that some legitimate mail will be rejected if the sending server is old or misconfigured.

The practical recommendation for most organizations: require TLS to your upstream server, accept but do not require TLS from the internet, and layer SPF enforcement, DKIM verification, greylisting, and content heuristics on top to handle the messages that TLS cannot filter by design.