Dears

We received an NDR message from an external contact when trying to send him an email (at the moment the issue is present only for this external recipient):

server************.com has rejected your message to the following email addresses:
mail*******@********.com)
The message could not be sent and no valid advanced status code was issued by the remote mail system to determine the exact cause, status: '530 #5.7.0 Must issue a STARTTLS command first'.
server**********.com returned this error:

5.7.0 Must issue a STARTTLS command first**

Does this error mean that we are NOT currently sending messages with forced TLS and therefore this particular recipient has configured their server to receive mail ONLY from servers that ALWAYS use TLS?
Eventually what would it entail to always use TLS for outbound messages?

Thank you

The send connector is already using opportunistic TLS, so there is no need to force TLS unless you have a requirement to do so with a partner org
You send connector is set to use opportunistic TLS already:

IgnoreSTARTTLS: False

Exchange 2016 uses opportunistic TLS to send messages by default.
Unless you have disabled that, TLS isnt an issue on your side.
If this is happening with just one domain, I suspect its something on their side

You can always enable SMTP protocol logging on the send connector, send a message and then see what it shows in the log

https://learn.microsoft.com/en-us/exchange/mail-flow/connectors/configure-protocol-logging?view=exchserver-2019#use-the-eac-to-enable-or-disable-protocol-logging-on-a-connector

Dear @Andy David - MVP

Thanks for your response.

This is the result of my email test to the problematic domain:

2022-08-17T12:34:13.100Z,internet,***************,1,,212.2*2.*6.1**:25,*,,attempting to connect
2022-08-17T12:34:13.100Z,internet,***************,2,192.168.1.11:25347,212.2*2.*6.1**:25,+,,
2022-08-17T12:34:13.201Z,internet,***************,3,192.168.1.11:25347,212.2*2.*6.1**:25,<,220 SERVER_recipient*****.com ESMTP,
2022-08-17T12:34:13.201Z,internet,***************,4,192.168.1.11:25347,212.2*2.*6.1**:25,>,EHLO SERVER_SENDER*******.com,
2022-08-17T12:34:13.222Z,internet,***************,5,192.168.1.11:25347,212.2*2.*6.1**:25,<,250 SERVER_recipient*****.com 8BITMIME SIZE 31457280 OK,
2022-08-17T12:34:13.222Z,internet,***************,6,192.168.1.11:25347,212.2*2.*6.1**:25,*,,sending message with RecordId 0asdbbf26be8sdadf7asa03b388 and InternetMessageId <0abbf26be8sdadf703b388@Testta *******.com>
2022-08-17T12:34:13.222Z,internet,***************,7,192.168.1.11:25347,212.2*2.*6.1**:25,>,MAIL FROM:<SERVER_SENDER*******.com> SIZE=406094,
2022-08-17T12:34:13.246Z,internet,***************,8,192.168.1.11:25347,212.2*2.*6.1**:25,<,530 #5.7.0 Must issue a STARTTLS command first,
2022-08-17T12:34:13.250Z,internet,***************,9,192.168.1.11:25347,212.2*2.*6.1**:25,>,QUIT,
2022-08-17T12:34:13.270Z,internet,***************,10,192.168.1.11:25347,212.2*2.*6.1**:25,<,221 SERVER_recipient*****.com,
2022-08-17T12:34:13.270Z,internet,***************,11,192.168.1.11:25347,212.2*2.*6.1**:25,-,,Local
2022-08-17T12:38:50.940Z,internet,08DA35EDDEA09865,0,,104.4*.*.6:25,,SendRoutingHeaders,Set Session Permissions
2022-08-17T12:38:50.940Z,internet,08DA35EDDEA09865,1,,104.4*.*.6:25,,,attempting to connect

(Please forgive me about fake names)

Thank you

Is that the ONLY recipient domain throwing that error?

,530 #5.7.0 Must issue a STARTTLS command first

Do the other messages you send go through?

Yes, at the moment, as far as we know, yes.
Is there any way to understand if other users are having the same issues (without noticing to IT)?
I would like to avoid looking through all outbound logs if possible.
Thanks again!

In addition to what I wrote, I've already noticed that when I send an email to a gmail account, the received message has an alert:
"mydomain.com did not encrypt the message"
Is it safe to force outbound mail encryption without the risk of being not able to send email to "no TLS" mail servers? Can you tell me how to check why we're not sending encrypted mail when possible?
This is our send connector config:

AddressSpaces: {SMTP:*;1}
AuthenticationCredential:
CloudServicesMailEnabled : False
Comment:
ConnectedDomains : {}
ConnectionInactivityTimeOut : 00:10:00
ConnectorType : Default
DNSRoutingEnabled: True
DomainSecureEnabled: False
Enabled: True
ErrorPolicies: Default
ForceHELO: False
Fqdn: mail.mydomain.com
FrontendProxyEnabled: False
HomeMTA: Microsoft MTA
HomeMtaServerId: Server1
Identity: internet
IgnoreSTARTTLS: False
IsScopedConnector: False
IsSmtpConnector: True
MaxMessageSize: Unlimited
Name: internet
Port: 25
ProtocolLoggingLevel: Verbose
Region: NotSpecified
RequireOorg: False
RequireTLS: False
SmartHostAuthMechanism : None
SmartHosts: {}
SmartHostsString:
SmtpMaxMessagesPerConnection : 20
SourceIPAddress: 0.0.0.0
SourceRoutingGroup: Exchange Routing Group (...)
SourceTransportServers: {Server1, Server2}
TlsAuthLevel:
TlsCertificateName:
TlsDomain:
UseExternalDNSServersEnabled : False

Thank you

Dears

Just a follow up on the case to give a conclusion to the argument.
After some searching I found that the initial issue was caused by our firewall not having starttls enabled.
Exchange was correctly configured as @Andy David - MVP confirmed, after enabling STARTTLS on our firewall our emails has started flowing outwards securely (no more alert of unsecure message on gmail ;-) )!
Hope it could be useful for others...

Regards