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
This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
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:
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
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
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