What is STARTTLS?
STARTTLS is the command that lets two mail servers agree, in the middle of a conversation that started in the clear, to switch to exchanging messages encrypted. It is why most email travels protected today, and also the source of an expensive misunderstanding: the protection is opportunistic, it happens when both sides manage it, and an attacker in the middle takes it all down by deleting a single line of the conversation. Standardized in 1999 and defined today by RFC 3207, from 2002.
How STARTTLS works
Mail delivery between servers runs over SMTP and always starts in plain text. STARTTLS is an invitation made inside that open conversation, and so it depends on the invitation actually arriving.
The server announces that it accepts
Once the connection is open, the sender introduces itself and the destination server replies listing what it can do. If it can encrypt, that list includes the line 250 STARTTLS.
The sender asks to switch channels
Seeing the announcement, the sending server replies asking for the change. If the announcement is not there, it does not ask, and the conversation stays open.
The two negotiate the protection
Server and client agree on the version and cipher they will use, and the channel becomes encrypted from that point on.
The message travels protected on that leg
Only then is the content sent. The protection covers that hop between two servers, not the whole route and not the message sitting in the mailbox.
Source: RFC 3207, the official STARTTLS specification in force, published by the IETF in 2002, which defines the SMTP extension for using TLS (Transport Layer Security) and warns, in its Security Considerations, about the announcement-stripping attack.
The blind spot the standard itself calls out
- The protection is optional by nature. STARTTLS only kicks in if the destination announces it can and the sender decides to ask. Nothing in the standard flow compels either of them.
- Deleting one line takes the encryption down. The standard is explicit: a man-in-the-middle attack can be launched by removing the server's 250 STARTTLS response, which makes the sender simply not try to protect the conversation.
- The failure is silent. When the invitation disappears, nothing errors and nobody is told: the message is delivered normally, in plain text, and both sides carry on believing all is well.
- Encrypting is not identifying. The standard itself says that whether to believe the other party's authenticity is a local matter for each server, and in opportunistic use the sender usually accepts whatever certificate shows up, so the channel gets closed without anyone having proven who is on the other end.
The three possible states of a delivery
- No encryption at all One of the sides could not or would not. The message crosses the internet readable at any point it passes through. It still happens every day, at volume.
- Opportunistic encryption The most common case. It works well when nobody interferes, and it is exactly what the stripping attack dismantles, because the sender accepts falling back to plain text without complaint.
- Required encryption The sender refuses to deliver if the channel cannot be protected and validated. The standard itself provides for this configuration, and it is what closes the hole. What was missing was a way for the recipient to announce that requirement, and that came later, with MTA-STS.
What is at stake while the protection stays optional
The bill for this design never shows up as an incident, it shows up as the absence of one. When encryption is taken down by stripping the announcement, nothing breaks: the message arrives, the sender gets no error, the recipient gets no warning, and the content traveled readable wherever it went. It is the difference between a door forced open, which you notice, and a door that was never locked in the first place, which you do not. For a company that matters because server-to-server email carries precisely what nobody wants exposed: the proposal with pricing on it, customer records, the payroll attachment, the contract discussion, the password reset code. And the exposure does not depend on the size of the company, it depends on which stretch of the internet the message crossed on that hop.
How to move beyond optional encryption
STARTTLS solves half the problem and cannot solve the other half on its own. The path is to add requirement and measurement around it:
- Make sure your servers announce and accept itThis is the floor, and there are still environments that miss it. Without the announcement on your side, no sender in the world can protect the delivery to you.
- Keep the certificate valid and under the right nameAn expired certificate, or one issued for a different name, breaks validation. Since plenty of senders accept it anyway in opportunistic mode, the defect goes unnoticed until the day someone starts requiring.
- Publish a requirement for a protected channelThat is what MTA-STS does: it declares to the world that your inbound side only accepts an encrypted and validated conversation, taking the decision out of the heat of the moment.
- Turn on reporting before you require anythingTLS-RPT returns, every day, what worked and what failed on the way into your domain, and it is what lets you tighten without knocking out legitimate senders.
- Treat this as a transport layer, not a content oneProtecting the hop between servers does not protect the message once delivered, nor prove who wrote it. Sender authentication and mailbox protection are separate layers that work together.
In practice
STARTTLS is an invitation to talk in private, and a third party takes that invitation down merely by pretending it was never made. So the right question is never whether your email uses encryption, it is whether someone can make your email stop using it without anyone noticing. As long as the answer is yes, what you have is the possibility of protection, not protection.
How Zamak handles transport encryption
Zamak Technologies treats the email channel as something you measure rather than something you assume: it checks whether the destination announces and accepts the switch to a protected channel, whether the certificate is valid and under the right name, and turns on reporting before proposing any requirement, alongside the team that already administers the environment. In practice that means closing the hole on this page with the two pieces that follow it: MTA-STS, which publishes the protected-channel requirement, and TLS-RPT, which measures whether it is being met. The email spoofing check gives the first picture of what your domain declares today. Keeping that layer under continuous watch is part of Managed Email Security and of Managed Cybersecurity in the Zamak Method.