Is Unencrypted SMTP a Real Security Risk for Exchange?

Yes. Unencrypted SMTP is a real security vulnerability - but the severity depends heavily on your threat model and where the unencrypted traffic actually flows.

That answer will frustrate people who want a simple yes or no. Here is why it is the honest one.

What unencrypted SMTP actually means

SMTP was designed in 1982. It transmitted everything in plain text, including the email contents, the sender, and the recipient. Over time, STARTTLS was added as an opportunistic upgrade - a way for two mail servers to negotiate encryption after connecting, without breaking compatibility with servers that do not support it.

The critical word is opportunistic. If one server does not advertise STARTTLS support, the other server will deliver the message anyway, in plain text. There is no authentication, no integrity check, no confidentiality. Anyone who can see the network traffic can read the message.

Port 25 - the default port for mail relay - is the most exposed. It is the port that mail servers use to talk to each other across the internet. If your Exchange server is accepting connections on port 25 without requiring TLS, those sessions transmit everything in the clear.

The three real attack scenarios

Man-in-the-middle on the open internet. If your Exchange server accepts unencrypted connections on port 25, any network observer between your server and the destination can read, modify, or inject email content. This includes ISP equipment, IXP infrastructure, compromised routers, or anyone with access to an upstream link. On a shared hosting network, this is not theoretical.

Credential theft on shared infrastructure. SMTP authentication (the username and password used to submit outgoing mail) is transmitted in plain text unless TLS is active. On a shared or virtualized network segment, another tenant or an attacker who has compromised the shared environment can capture those credentials trivially.

Email tampering without detection. Without TLS integrity checking, there is no guarantee that what you sent is what arrived. A sophisticated attacker who can intercept an unencrypted SMTP session can modify the message body, attachments, or headers without either end noticing.

Why internal email still gets overlooked

Most security teams focus on external SMTP. Internal email between your Exchange server and internal users is often assumed to be safe because it never leaves your network.

That assumption breaks in three common scenarios.

First, internal segment changes. If your Exchange server uses internal SMTP for hub transport and that traffic crosses a shared virtual network segment, VLAN, or a cloud interconnect link, it is no longer safe by default.

Second, hybrid environments. In a Microsoft 365 hybrid deployment, internal mail flows between your on-prem Exchange and Exchange Online through internal connectors. Those connectors may not require TLS if they are assumed to be on a trusted network. That assumption is worth auditing.

Third, internal relay servers. Many organizations have application servers that relay mail through Exchange using SMTP. If those relay paths are unauthenticated and unencrypted, they are an open door.

How to check your Exchange SMTP security posture right now

Open the Exchange Management Shell and run this command to list all receive connectors and their TLS enforcement settings:

powershell
Get-ReceiveConnector | Format-List Identity,AuthMechanism,TLSSecurityLevel,RemoteIPRanges

Look for any connector where TLSSecurityLevel is set to None or Allows - those connectors will accept plain-text sessions. A value of RequiresAndAccept means TLS is required.

For send connectors, run:

powershell
Get-SendConnector | Format-List Identity, STARTTLS, DomainSecureEnabled

If STARTTLS is False or DomainSecureEnabled is False for a connector that handles sensitive traffic, that traffic can be transmitted unencrypted.

How to enforce TLS on Exchange Server

For receive connectors that accept external mail, the most important setting is TLSSecurityLevel. To require TLS on a specific connector:

powershell
Set-ReceiveConnector -Identity "Default Frontend SERVERNAME" -TLSSecurityLevel RequiresAndAccept

Setting TLSSecurityLevel to RequiresAndAccept means Exchange will only accept encrypted sessions on that connector. Plain-text connections will be rejected.

For send connectors that deliver to external domains, Exchange uses STARTTLS opportunistically by default - it will encrypt when the destination supports it, and deliver unencrypted when it does not. If you want to enforce TLS for specific high-risk destinations, you can create a scoped send connector or use a transport rule to require TLS for messages going to specific domains.

The practical constraint: you cannot force STARTTLS on a destination server that does not support it. That is a limitation of the protocol, not Exchange. What you can do is ensure your own server never falls back to plain text when encryption is available.

When unencrypted SMTP is acceptable

There is one legitimate scenario: authenticated internal relay on a fully controlled, air-gapped network segment with no virtualized or shared infrastructure.

If your application server and your Exchange server are on the same isolated VLAN with no cross-VLAN traffic, no cloud interconnect, and no virtual machine sharing, and the relay is authenticated with a service account, the risk from unencrypted SMTP on that specific path is genuinely low.

Every other scenario - external-facing connectors, hybrid links, any traffic that crosses shared infrastructure - should require TLS.

How to confirm your TLS posture is holding

Once you have tightened your Exchange TLS settings, the next question is whether they are actually working as configured. That is where monitoring authentication results matters.

When TLS enforcement is working correctly, your mail server presents a valid certificate and encrypted sessions are established for every supported destination. If something is misconfigured - a connector that reverted to plain text, a smart host that does not advertise STARTTLS, a fallback that should not be happening - it shows up as an anomaly in your SPF, DKIM, and DMARC data. DMARCFlow tracks those anomalies. It gives you a way to confirm your TLS configuration changes are actually holding and to alert you when an outbound path falls back to an unencrypted session without your knowledge.

FAQ

Is STARTTLS the same as requiring TLS?

No. STARTTLS is an opportunistic upgrade. It encrypts the session only if both servers agree. If the destination does not support it, mail is delivered in plain text anyway. Requiring TLS means the session does not happen at all unless encryption is active.

Does enforcing TLS break mail flow with older mail servers?

It can. A small percentage of mail servers on the internet still do not support STARTTLS. If you require TLS, messages to those servers will fail to deliver rather than degrade to plain text. For most organizations, this is the correct behavior - you should not be sending confidential content to servers that refuse to protect it.

What certificate does Exchange need for TLS?

Any valid certificate from a trusted CA will work. The certificate's common name or subject alternative name should match the domain your Exchange server uses for SMTP. Self-signed certificates will encrypt the session but will not authenticate the remote server, which defeats the purpose of requiring TLS on receive connectors.

Does this apply to Exchange Online?

No. This post covers on-prem Exchange Server. Exchange Online handles transport encryption by default and does not allow unencrypted SMTP sessions. The equivalent audit for Exchange Online is checking your hybrid connector configuration and your mail flow rules.