Forced TLS and encrypted connections explained
What is forced TLS?
TLS (Transport Layer Security) is the security standard that encrypts a connection, the same technology that makes the padlock in your browser possible. With email, TLS protects the connection between mail servers and between your device and your mail server, so the content isn't readable in transit to anyone tapping the connection.
Normally TLS is "opportunistic": if encryption succeeds, great; if it doesn't, the message sometimes still goes through unencrypted. Forced TLS removes that back door: if there's no valid encrypted connection, the mail isn't delivered. Certainty over convenience, then. Read more about encryption in a broader sense in encrypted email: what is and isn't possible.
Why an encrypted connection matters
Email travels by default over multiple servers and networks. Without encryption that's like a postcard: anyone who gets their hands on the card in transit can read along. That's not a theoretical risk on public or shared networks, where traffic is relatively easy to tap. TLS puts that postcard in a sealed envelope for the part of the journey between the servers.
For anyone working with personal data, that's no detail. The GDPR asks for appropriate technical measures when processing personal data, and an encrypted connection is part of the basics of that. On the community security.nl someone summed it up aptly: with forced TLS, email is perfectly usable for basic personal data. That holds as a rule of thumb, provided you understand what TLS does and doesn't protect. For the question of what exactly you may send by email, see personal data by email and the GDPR. Consult a specialist if in doubt.
How it works
TLS protects the connection, not the stored message. Here's how it goes in practice.
- Your sending server connects to the receiving server and proposes using TLS.
- Both servers exchange certificates and set up an encrypted tunnel.
- The message travels through that tunnel: unreadable in transit to anyone watching.
- On arrival it's decrypted again and stored on the recipient's server.
With forced TLS a hard requirement is added: if step 2 fails, your server refuses to send the message instead of forwarding it unprotected. So you trade a small risk of delay for the certainty that nothing leaves unencrypted.
Note that the message is simply stored in readable form on the end server. TLS protects only the journey, not the destination. Anyone with access to the mailbox itself sees the content; other measures take care of that, such as a strong password and two-factor authentication. Transport encryption and access security are therefore two different layers that you both need.
Important to grasp: this is transport encryption, not end-to-end encryption. TLS protects the message while it's in transit between servers. On the servers themselves the mail lies stored in readable form, and the receiving side must also support TLS. If you want only the end recipient to be able to read along, you need a separate layer of encryption; that difference is explained in encrypted email.
The distinction between "opportunistic" and "forced" is the most important one in practice. Opportunistic TLS tries to encrypt, but on a problem quietly falls back to unencrypted traffic, without you noticing. That very fallback is what an attacker can provoke. Forced TLS closes off that exit: no valid secure connection means no delivery. So you get certainty instead of "usually fine".
What to watch out for
- TLS ≠ end-to-end. It protects the journey between servers, not the storage afterwards. For truly confidential documents, additional encryption may be needed.
- Both sides have to take part. If the receiving server doesn't support TLS, forced TLS blocks delivery. That's safe, but can delay delivery.
- It doesn't govern access. Encryption in transit says nothing about who may enter the mailbox. So combine it with strong access security such as 2FA.
- Certificates must be valid. An expired or incorrect certificate breaks the encrypted connection.
- It's largely provider work. As a user you rarely set up TLS yourself; it's part of a well-configured mail environment.
A practical trade-off is between security and certainty of delivery. Strict forced TLS protects to the maximum, but can block mail to recipients without TLS. For most business correspondence that's no problem, because serious parties support TLS. If you work with sensitive data, the protection weighs more heavily than the rare inconvenience. It's exactly the kind of choice you can leave to a provider who configures the environment to modern standards.
And with Mailflux
With Mailflux your email runs on infrastructure configured to modern standards, with encrypted connections (TLS) between your device and our servers and in the transport of messages. That way your mail stays protected in transit without you having to tinker with it yourself.
You get professional email on your own domain, hosted in Europe and GDPR-compliant, with machine-learning filtering against spam, phishing and malware, standard antivirus, antispam and antimalware, automatic backups and optional two-factor authentication. One clear price per mailbox, billed annually, with the security basics neatly taken care of.
FAQ
Frequently asked questions
Is forced TLS the same as end-to-end encryption?
No. Forced TLS encrypts the connection over which your mail travels, so no one can read along in transit. End-to-end encryption encrypts the content itself, so only the end recipient can read it, even on the server. TLS is transport security; for the most sensitive content an extra layer is needed.
Is email with forced TLS secure enough for personal data?
For basic personal data, an encrypted connection is an important baseline measure. The GDPR asks for appropriate security, and that depends on the sensitivity of the data. For special categories, such as health data, more may be needed. Consult a specialist if in doubt.
Do I have to set up forced TLS myself?
Usually not as a user. TLS and its enforcement are part of a well-configured mail environment and are managed by your provider. In practice you notice little of it, except that your messages are only sent and received over secure connections.